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. 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:
   1. Use useradd (and passwd!) to create user accounts (if they do not already exist) for the network support people:

      useradd john ; passwd john

   2. Use groupadd to create a group called networking:

      groupadd networking

   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,users john

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

   4. 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

   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.

2. The number 4550 in the example above is called an "octal permission", which in general has the following format (in binary):

   u g t	r w x	r w x	r w x
   setuid setgid text	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

   u 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.

   The first octit should be used sparingly, as it 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 text bit is set, the text of the file is kept in the swap partition (emacs uses this to speed up program startup for multiple copies of the editor). 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, use "find / -perm -4000 -ls".

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

   -r-sr-x---    1 root     networki    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 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.
3. 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!

4. 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.
5. root can change the ownership of a file using chown in the same fashion as the 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.
6. In our Linux distribution, new users belong to the group "users". In order to prevent any user from accessing anyone's files, 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 022, which means that no one but the owner may write to a file). 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.

7. 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.
8. 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"!). su spawns 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.
9. 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.
10. 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, endeavour2, mozilla, ncftp, WindowMaker and X.

    Be aware that when you use "useradd -m", the permissions on the new directory are 755. 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.

11. 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.

---

12. EXERCISES for Week 6:
    1. Modify umask as specified above, and fix the permissions on the directories in /home.
    2. 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.
    3. 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 programs.
    4. Make sure that the new users all have 0700 permissions on their home directories.
    5. Create a script called usersetup which contains all of the commands you used to set up the above users and groups. Create another script called permsetup which contains all the commands used to specify the file permissions in the exercises above. E-mail both scripts to the instructor.

©2005, 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.