Notes for Week 6

• restricting access to files

  granting permission to read or write a file, to view a directory or to execute a program to only those users allowed to do so; for instance, access to a payroll database is restricted by only allowing users in the Payroll Department to access the database files, and the ability to ping on the network is controlled by allowing only Networking Department personnel to execute the ping program

• policy enforcement

  a policy is established for each action, defining who can perform it; ie., it should not be possible via telnet to login as root (since telnet does not know how to encrypt passwords)

1. Three files are used for user and group security:
   • /etc/group - a list of the groups and the users in them;
   • /etc/passwd - a list of the users, their initial groups, home directories and shells; and
   • /etc/shadow - like /etc/passwd, but containing encrypted passwords as well; /etc/passwd must be readable by any user, since it is used to translate numeric user ids into names, but shadow is only readable by root.

   passwd and group files can be maintained in a consistent fashion across multiple servers using NIS (the Network Information Service). This is analogous to the Windows notion of a Primary Domain Controller. Both are outside the scope of this class.
2. Suppose that a system administrator wants to allow only his network support people to be able to use ping. (S)He might proceed as follows:

   Both before and after the next 3 steps, do the following: cat /etc/passwd ; cat /etc/group ; cat /etc/shadow. Note which files change after each command, and what the changes entail.

   1. Use useradd (and passwd!) to create user accounts (if they do not already exist) for the network support people:

      useradd -m john ; passwd john

   2. Use groupadd to create a group called networking:

      groupadd networking

      Note that some predefined groups are there to control access to hardware capabilities. For instance, you must be a member of the group audio to access the sound card.
   3. Use usermod to put the users in the networking group (note that the -G option requires that ALL groups of which the user is a member be listed, and that the -G option precedes the user name):

      usermod -G networking,john john

      Note that at this point, the stage has been set, but no enforcement will take place because no permissions have been specified.

      In case you make any mistakes, it might be useful to know the following: to delete a user, use the userdel command; likewise, to delete a group, use the groupdel command.

   Both before and after the next 2 steps, do the following: ls -l /bin/ping. Note the changes after each command.

   4. In our distribution, the root filesystem is normally read-only. In order to execute the next two commands, it is necessary to

      mount -wo remount /

      Use chgrp on the ping program to specify that it belongs to the networking group:

      chgrp networking /bin/ping

   5. Use chmod to specify that only users belonging to the group may execute the program:

      chmod 4550 /bin/ping

      Now make the root filesystem read-only once again by

      mount -ro remount /

   In most instances, a system administrator will not enforce security on a file by file basis. Instead, all of the files needed by a specific group (but to be protected from users outside the group) will be placed in a single directory, and access will be controlled via directory permissions.

   The implementation and maintenance of a user and group structure is a design problem whose scope can only be appreciated by someone who has inherited a server which has a tangled mess of users and groups and does not adequately control security of system resources. It cannot be stressed strongly enough that the design of a useful and flexible group structure requires careful forethought and more than a little luck, and

   when ad hoc changes are made for the sake of convenience, security will be compromised quickly and effectively.

   Most systems administrators will keep all of the commands needed to set up their user and group structure in one or more scripts, to facilitate rebuilding the server, and to make it easier to keep track of what is already in place when making changes.
3. The number 4550 in the example above is called a mode, or permission, which in general has the following format (in binary):

   s g t	r w x	r w x	r w x
   setuid setgid sticky	owner	group	anyone else
   	read write execute	read write execute	read write execute

   The octal permission is a four "octit" (base 8 digit) number; missing high order numbers are assumed to be zero (as in base 10). Hence a 750 would really mean 0750; written in binary, 750 is

   s g t	r w x	r w x	r w x
   0 0 0	1 1 1	1 0 1	0 0 0

   and so we see that the owner (which is root) can read, write to and execute the file, the group members can read and execute the file, and anyone else can do nothing with the file.

   Never add s or g permissions to a file which does not already have them, as they can open potentially enormous security holes.

   • If the setuid bit is set, the program process runs as if the owner started it; in this case, ping would run as root.
   • If the setgid bit is set, the program process runs as if a group member started it; in this case, ping would run as a member of networking (which is no big deal; setgid is only useful if anyone can execute the program).
   • If the sticky bit is set on a file, nothing happens. If it is set on a directory (like /tmp), only the directory's owner can delete or rename files.

   The setuid bit is necessary in some cases; in fact, ping must be setuid so that an ordinary user can access the protocol stack. To find files which are setuid on the root partition, use find / -xdev -perm -4000 -ls.

   The permissions which are set when ping is installed are 4555. After the changes in the above example, an ls -l /bin/ping produces the following output:

   -r-sr-x---    1 root     networking    23436 Aug 27 12:10 /bin/ping
   

   This means that ping is:
   • owned by root,
   • belongs to the networking group,
   • can by read, written to (because root can do anything, even though the "w" bit is not set) and executed by root,
   • can be read and executed by anyone in the networking group,
   • cannot be read or written to or executed by anyone else, and
   • runs as root when someone from the networking group executes it.

   Note that root does not need r or w permission to read from or write to a file or directory. Also, root can execute any file which has execute permission, even it the file is not owned by root.

4. In Windows, you need to know what kind of filesystem a file or directory resides in, in order to know how to deal with it securely:
   • If it resides in a FAT filesystem, your only option is to make it read-only; FAT does not support users and groups, nor does it support more sophisiticated permissions. To set file attributes like read-only, use the ATTRIB command.
   • If it resides in an NTFS filesystem, you can associate it with a user and/or a group; in addition, you can specify one or more Access Control Entries (ACEs) in an Access Control List (ACL); we will discuss these issues further in week 13. To modify ACLs, use the CHACL command.
5. The chmod command also supports symbolic permissions, but in general you should not use them: the octal permissions correspond to the information that is actually stored in the file inode, and to how Linux uses them, and anytime you can use the system on its own terms, you understand it better.

   The only time that it makes sense to use the symbolic permissions is if you need to add or remove a permission on multiple files, not all of which have the same permissions. For instance, if you needed to add write permission for the file's owner to all of the files in a directory, some of which were executable and some of which were not, the command chmod u+w * is very useful. You must be very careful, however, since it is easy to mistakenly use "o" for owner instead of "u" for user, and "o" does NOT mean owner, it means all of the other users who are not the owner or in the file group!

6. Execute permission on a directory is necessary if the user is to be able to examine it or cd to it. Read permission is also necessary in order to examine the directory.
7. root can change the ownership of a file using the chown command in the same fashion as chgrp is used above. This would commonly be used if root created a file for a user and then wanted the user to own it.

   For instance, suppose root creates a directory containing multiple files and sub-directories, and wishes to copy the directory and its contents to a user's home directory, who should then own them. A simple way to accomplish this would be:

   cp -a directory /home/user/
   chown user:user /home/user/directory -R

   The "-a" on the cp command causes it to copy the directory and everything it contains (without the "-a", cp will refuse to copy directories). The "user:user" causes chown to change both the user (before the colon) and group (after the colon) associated with the directory, and the "-R" will cause chown to do that recursively, to the contents of the entire directory sub-tree starting with /home/user/directory.
8. Some system administrators set their users up so that multiple users start out in the same group. In order to prevent any user from accessing anyone's files in such an environment, file permissions for the group and other users should be 00.

   This can be accomplished by setting umask to 077 in /etc/profile.d/umask.sh (it is currently set to 007, which means that the owner and group members have full access, but others do not). umask is an internal bash command which affects all files created by the shell or any of its children. The effect is to AND the mode specified at file creation with NOT the umask value; the resulting value is stored in the file inode. So umask specifies which bits MUST be zero in the permissions.

   Note that the profile scripts are run only for a login shell (the one started by login). Therefore, changes made to any of them will only affect subsequent logins. Specifically, the changes will not affect current or new xterm shells unless you first logout.

9. If a user is a member of more than one group, the shell which is started at login is considered a member of all of them.
10. If a user needs to run under a different user account, the su command can be used (provided the user knows the password of the account that they are "su-ing to"!); for instance:

    su

    with no parameters means that you want to become root, while

    su user

    means you want to become that user.

    su spawns (or forks) a new shell process which is stacked on top of the previous one, and which runs under the new user. When the new shell is exited, the old one resumes under the old identification. The id command can be used to find which user and group the current shell process is running under.

11. When a new user is created, information from /etc/default/useradd provides the default settings for the useradd options. If useradd -m is used, the files in /etc/skel are copied into the new user's home directory. In our Linux distribution, /etc/skel contains profile information for bash, emacs, mplayer (the media player) and X-Windows.

    If you want to add files and directories to /etc/skel so that all of your users will have a predetermined environment in which to work, be sure to refer to home directories using the environment variable $HOME (or ~/); any references to /root will obviously be a problem!

    If any of the files are used by programs which do not interpret environment variables, the user can execute the following command to manually change "$HOME" to the name of the user's home directory:

    sed -i~ -e "s%\$HOME%$HOME%g" filename

    The "-i~" means we are doing an "inline" edit, and a backup copy of the file will be saved as filename~. The double quotes on the expression are necessary so that the shell will change the second "$HOME" to the user's home directory, and the backward slash prevents the shell from do that to the first "$HOME". The g option tells sed to make the change on every occurrence of $HOME on every line it occurs in.

    To see how the shell interprets that command, if it were executed by the user ken, it would be interpreted as

    sed -i~ -e s%$HOME%/home/ken%g filename

    We used "%" as the delimiter for the sed s command because the second $HOME will have "/"s in it when the variable is expanded by bash.

    Be aware that when you use useradd -m, the permissions on the new directory are 755 (this is because root's umask value is 022; root often installs software that ordinary users will use, so that is the most useful value for root). When all users are a member of the same initial group (and umask is set to 077), you will probably want to chmod 700 the new home directory. If every user has their own group (as in our distribution), 770 would be acceptable.
12. Two important aspects of system administration which we will not go into detail about, but which you should be familiar with, are accounting and quota control.

    Accounting allows the system administrator to keep track of how much each user is using various system resources, such as cpu time, memory and i/o. It can also keep track of which programs are used by each user, and resource usage by program. While in the past this information was typically used to charge users for computer resources, its primary use now is to allow the administrator to track usage (and misusage) of the system.

    The system also allows the administrator to set and enforce maximums for disk space utilization by filesystem and user, via quota control.

---

13. EXERCISES for Week 6:
    1. Create users tom, dick and harry. Put them in the payroll group. Create a directory in /srv called "payroll" and make sure that only tom, dick and harry can access it or its contents.
    2. Create users jack and jill. Put them in the networking group. Make sure that only jack and jill can use the nc, ping and traceroute (called TRACERT in Windows) programs.
    3. Change the permissions on all directories in /home so that no one can access each directory except its owner.
    4. Create a script called usersetup.txt which contains all of the commands you used to set up the above users and groups. Create another script called permsetup.txt which contains all the commands used to specify the file permissions in the exercises above. E-mail both scripts to the instructor.

©2014, Kenneth R. Koehler. All Rights Reserved. This document may be freely reproduced provided that this copyright notice is included.

Please send comments or suggestions to the author.