Networking / Beginners

---

Controlling users

In addition to contolling processes, it is necessary to have controls over the users of the UNIX workstation. This consists of controlling the user's access to files and their ability to run processes. The UNIX file permission scheme determines what access a user will have to any given file. Controlling a user's access to processes mostly concerns controlling root access.

File permissions

UNIX design expects individual users to log in to workstations with their own user IDs and passwords. The file permissions method used is predicated on classifying the user into one of three categories. Each file in UNIX is then flagged with certain permissions based on the category of the user. The individual login is required to properly place a user in the categories. A user will belong to each of these categories:

• World-Every user is a member of this category. Permissions granted to the world would be granted to any user on the UNIX workstation.
• Group-Every user should be a member of at least one group. Permissions granted to the group are granted to all the individual users in that group.
• Owner-Every user will own (create) some files. The permissions granted to the owner apply to the user who is the file creator. File ownership can also be changed after creation.

Passwords and user information are stored in the /etc/passwd file. If shadow passwords are used, the passwords are stored in the /etc/shadow file. Group membership is stored in /etc/group. A user may be in more than one group. Only the administrator can create new groups or add and delete group members.

A sample listing of assigned file permissions.

Field 1:   a set of ten permission flags.
Field 2:   link count (don't worry about this)
Field 3:   owner of the file
Field 4:   associated group for the file
Field 5:   size in bytes
Field 6-8: date of last modification (format varies, but always 3 fields)
Field 9:   name of file (possibly with path, depending on how Is was called)

Now that the users are categorized as World, Group, and Owner, you need to put flags on each file to correspond to the user category. The flags may also be used for more than just permissions. The permission flags are read left to right, as shown in Table-1.

Table-1: File Permission Flags

Position 	Permission or Type
1 		Not a permission, the first flag is the file type, d if a directory, - if a
		normal file, c or b for special devices
2,3,4 		Read, write, execute permission for Owner of the file
5,6,7 		Read, write, execute permission for members of the Group assigned
		to the file
8,9,10 		Read, write, execute permission for the World (any user)

A dash (-) in any position means that a flag is not set. The flags of r, w, and x are shorthands for read, write, and executable. When an s is in place of an x, it means the User ID (UID) bit is on. When a t is in place of an x the sticky bit is set. The sticky bit is used to protect the renaming or removal of files in a directory. If the owner of a directory sets its sticky bit, the only people who can rename or remove any file in that directory are the file's owner, the directory's owner, and the superuser.

If a world or group user can execute the file while the UID bit is on, the execution will run as though the owner is running the file. Any permissions or access granted to the owner is thus applied to that execution. There are some security concerns when creating an executable or script that has the UID bit set. All the normal access permissions that UNIX provides to limit a user might be circumvented if the user can execute a file owned by root with the UID bit set.

For a directory, the setgid flag means that all files created inside that directory will inherit the directory's group. Without this flag, a file assumes the primary group of the user creating the file. This property is important to people trying to maintain a directory as group accessible. The subdirectories also inherit the set-groupID property.

The sticky bit is used to ensure that users do not overwrite each other's files. When the sticky bit t is set for a directory, users can only remove or rename files that they own.

To read a file, you need execute access to the directory it is in and read access to the file itself. To write a file, you need execute access to the directory and write access to the file. To create new files or delete files, you need write access to the directory. You also need execute access to all parent directories back to the root. Group access will break if a parent directory is made completely private.

When a new file or directory is created, the file permissions will be set to the umask that is set in the user's environment. Because this is a mask, use XOR to determine the file permissions to be set. Typically, the default configuration is equivalent to typing umask 22, which produces permissions of -rw-r--r-- for regular files, or drwxr-xr-x for directories. This can lead to giving read access to files such as saved e-mail in your home directory, which is generally not desireable.

Care must be taken when assigning a group or changing the group access on a file or directory. The /etc/group file should be checked to ensure that only the intended users are given access. Consider, also, that the administrator may change the group membership at a later date, giving more persons access to files assigned to a group.

Set UID

Normally, when a user executes a program, it is run with the user or group ID (U/GID) and the program has the same privileges and access as the user or group. The program can access the same resources permitted to the user or group. Any files created by the process are owned by the user.

However, there are times when the processes executed on the user's behalf need to have root privileges, not user privileges. A typical example is the mount process, which calls the kernel to mount file systems.

A process or program has the privileges of the owner of the program (as opposed to the user) when the set UID (SUID) flag is set on the program's file permissions. As a security measure, only root is permitted to set the UID flag.

The following series of commands demonstrates the setting of the Set UID flag on an executable. First, you see from the long listing of the file that the permissions are set to rwx r-x r-x and no set UID flag is set.

# ls -l fake_exe
-rwxr-xr-x 1 root root 0 Jun 13 12:25 fake_exe

Now the mode is changed to set the UID flag. You then see from another long listing that the chmod command has set the UID flag and the file permissions are now rws r-s r-x.

# chmod +s fake_exe

# ls -l fake_exe
-rwsr-sr-x 1 root root 0 Jun 13 12:25 fake_exe

The ability of a user to run a process with root powers is a definite security concern. System administrators should keep track of all applications with the UID flag set. Programs that set the UID to root are a potential avenue for users or attackers to gain root access. Table-2 shows a search of all files on a UNIX workstation that has the UID, GID, and sticky bit set.

Table-2: UID, GID, and Sticky Bits

Files with UID Flag Set 	Files with GID Flag Set 	Files with Sticky Bit Set
# find / -perm +4000 		# find / -perm +2000 		# find / -perm +1000
/usr/bin/chage 			/tmp/app 			Read, write, execute
/usr/bin/gpasswd 		/usr/bin/wall 			permission for Owner of
/usr/bin/chfn 			/usr/bin/write 			the file/dev/shm
/usr/bin/chsh 			/usr/bin/lockfile 		/var/lib/texmf
/usr/bin/newgrp 		/usr/bin/slocate 		/var/tmp
/usr/bin/passwd 		/usr/bin/kdesud 		/var/run/vmware
/usr/bin/at 			/usr/sbin/lockdev 		/var/spool/vbox
/usr/bin/rcp 			/usr/sbin/sendmail.sendmail 	/var/spool/samba
/usr/bin/rlogin 		/usr/sbin/utempter 		/var/spool/cups/tmp
/usr/bin/rsh 			/usr/sbin/gnome-pty-helper
/usr/bin/sudo 			/usr/sbin/postdrop
/usr/bin/crontab 		/usr/sbin/postqueue
/usr/bin/lppasswd 		/sbin/netreport
/usr/bin/desktop-create-kmenu
/usr/bin/kcheckpass
/usr/lib/news/bin/inndstart
/usr/lib/news/bin/rnews
/usr/lib/news/bin/startinnfeed
/usr/libexec/openssh/ssh-keysign
/usr/sbin/ping6
/usr/sbin/traceroute6
/usr/sbin/usernetctl
/usr/sbin/userhelper
/usr/sbin/userisdnctl
/usr/sbin/traceroute
/usr/sbin/suexec
/usr/X11R6/bin/XFree86
/bin/ping
/bin/mount
/bin/umount
/bin/su
/sbin/pam_timestamp_check
/sbin/pwdb_chkpwd
/sbin/unix_chkpwd

To minimize the risk of a program with the UID flag set, the system administrator should decide if non-root users need to run the program. For example, a case can be made that normal users do not need to test network connects using applications such as ping and traceroute.