Notes for Week 6

There are two principle means of enforcing security in server environments:

Linux can use both means, but the former is much more widespread; Windows uses predominantly the latter. Both methods are made somewhat easier to administer by grouping users and enforcing security based on group membership.

  1. Three files are used for user and group security:

    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.
    4. Both before and after the next 2 steps, do the following: ls -l /bin/ping. Note the changes after each command.

    5. 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
    6. 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 tr w xr w xr w x
    setuid setgid sticky ownergroupanyone else
    read write executeread write executeread 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 tr w xr w xr w x
    0 0 01 1 11 0 10 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.
    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:

    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:

  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/ (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:
    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.