POSIX Permissions

Overview

The purpose of this exercise is to introduce you to filesystem and network access control schemes and the "principle of least privilege" through the use of POSIX filesystem permissions.

After this exercise, you will:

1. understand the POSIX permissions structure including SUID and SGID bits
2. understand the essence of the sudo utility and how to configure and use it securely.
3. be able to apply that knowledge to configure permissions in multiple scenarios, such as:
   1. shared system directories
   2. user home directories and private directories
   3. privileged system directories
   4. unprivileged temporary directories
   5. editing important configuration files
   6. restarting system processes
   7. potential privilege escalation problems

Required Reading

POSIX Permissions

The Portable Operating System Interface, or POSIX, is IEEE standards family IEEE 1003.1 and represents an attempt to formalize the API for variants of the Unix operating system. POSIX specifies standards for the kernel APIs (including many internal functions like permissions, threads, networking, and interprocess communication), commands, required utilities and user-level APIs (including many utilities and scripting tools like awk, echo, ed, sh, vi, basic I/O, and more), and a conformance test that can be run on many platforms. POSIX is very widely disseminated and has been in use for almost 20 years, but is a closed standard (i.e. proprietary). As a result, it is expensive to be certified; this has resulted in many free operating systems such as FreeBSD and Linux being substantially compliant but not officially able to use the moniker "POSIX Compliant". An alternative to POSIX is the Single UNIX Specification, developed by the Austin Group. Unfortunately, it is also proprietary and expensive.

The expense has not been prohibitive for motivated commercial vendors however, and POSIX has been extremely influential in coalescing and standardizing those elements that are characteristically UNIX-like. Furthermore, POSIX is a standard that influences software design and operating system implementations in seemingly unlikely places -- for example, Windows NT and its derivatives (2000, XP, and beyond) can be "POSIX compliant" with the addition of software packages and the enabling of certain features. This broad influence -- existing before the public explosion of the Internet -- has helped to make software and systems similar in fundamental ways. This, in turn, simplifies many portability and interoperability problems.

One of the enduring legacies of Bell Labs UNIX and the POSIX standard are traditional Unix file system permissions, which are a simple system of permissions stored in the file system and and kernel and evaluated to mediate access to system resources. Additionally, since devices are files in Unix, file system permissions also mediate control over many aspects of the operating system.

In most Unix and Unix-like operating systems, the permission system is extremely simple. Each file has read, write, and execute permissions set for each of three groups of users called "access classes". The three classes are user (owner), group, and other; each access class represents one or more users in the following way:

• Users each have unique user identifiers (userids or UIDs, listed in /etc/passwd) that only they control.

• Groups are arbitrary collections of users. Each group has its own group identifier (groupid or GID, defined in /etc/group). Often, every user on the system has a personal group used for sharing data with a limited set of other users.

  • Example: the group class cdrom usually contains a list of all users granted permission to access the system's CD-rom drive.

  • Example: the user sonny has a group sonny by default; the user cher can be added as a member of group sonny so that they can share resources between themselves but no one else.

• Finally, the membership of the other class for each file is dependent on the user and members of the group class -- the other class does not represent "all users!" Specifically, the other class represents "everyone that is not the user (owner) of the file and or a member of the file's group class." This fact allows us to express more meaningful permissions by strictly dividing all system users into three non-overlapping sets.

  • A more precise way of stating this is to say that other represents the the list of all users on the system, minus the union of the user and group classes.

  • Example: There are three users on a system: sonny, cher, and donovan. sonny owns a file whose group access class is set to the group sonny, which contains the user cher. The other class consists only of donovan, because he is not the owner nor in the group sonny.

Each access class is encoded by 3 bits. Each bit present grants an additional permission from the set read, write, and execute. When you list files in long form (with the option -l), you will see the permissions written out in the leftmost column as a bitstring with the letters r, w, and x in the order user, group, and other:

Here's what it looks like "in the wild":

$ ls -alh
-rw-r--r--   1 pahp console  18K May 16  2006 gpl.txt
drwx------   5 pahp console  512 May 21  2006 john-1.7.2/
lrwxrwxrwx   1 pahp console   25 Sep 13 20:45 labs -> /proj/some/link/
-rwxr--r--   1 pahp console  171 Sep  9 09:18 loadimage.sh*
drwxrwxrwx   1 pahp console  512 Sep 13 20:45 worldwriteable/
^ ^  ^  ^--- other permissions
| |  '------- group permissions
| '---------- user permissions
'------------ file type: d=directory, l=symbolic link, - means regular file

Here's an example bitstring split into components:

   d     rwx     rwx    rwx
type    user    group  other

In the above example, the owner of the file gpl.txt has read and write permission because the owner part of the bitstring is set to rw-. The owner (pahp) cannot execute this file, but that doesn't matter because it's just a text file. The group class console can read the file, as can the members of the other class -- everyone else.

The directory john-1.7.2 is only accessible by the owner and nobody else. Notice the d in the first place; this means that the file is a directory.

The file labs is a "symbolic link" (sometimes called "soft link") to the directory /proj/some/link/. Symbolic links are a special kind of file that is a pointer to a disk location (a "pathname" which may or may not exist). Permissions on symbolic links do not work as their lrwxrwxrwx permissions might lead you believe.

In addition to the 9 bits required to store the user, group, and other permissions of a file, there are three kinds of "additional permissions" that are rarely used but are extremely important to understand. The additional permissions are known as the setuid bit, setgid bit, and sticky bit. Each special bit has a different function depending on where it is used:

When the the special bits are used on regular files:

• The setuid bit on an executable file means that the file will run as the userid of the file's owner as opposed to the userid of the user executing the file. This is done to allow users to perform tasks that temporarily require the user to be someone else, such as changing passwords or restarting a service. Any program with the UID bit set must be carefully written so as to block all misuse. Innumerable vulnerabilities have stemmed from setuid root programs with security holes that allowed users to execute other commands as root.

• The setgid bit on an executable file is like the setuid bit, except that the process gains the effective user of the file's group, not its owner or the user executing the file.

• The "sticky bit" was used in the olden days to tell the kernel to keep an executable's image in memory so that it would not have to be reloaded from disk. This was commonly done with programs such as editors that were used regularly but had a significant load time. Modern systems use the "sticky bit" for other uses.

When the special bits are used on directories, they have different meanings altogether. Search online to discover what those meanings are on Linux systems.

Every file has permissions of some kind set for the each of the three classes, using the three types of basic permissions: read, write, and execute (and the three special bits). These permissions have a default value (based on the system umask) when the file is created. Permissions can be changed with command line utilities such as chmod and chown, which are discussed later in this document.

These permissions are fairly self explanatory when applied to files, but when applied to directories their meanings are not always intuitive. In particular, permissions set on a directory do not always apply to that directory's contents, and the concepts of "read", "write", and "execute" as they pertain to directories is not obvious. (It helps to think of a directory as a file which contains links to other files, rather than as a nested series of containers -- experiment on SPHERE to determine how they really interact!)

Furthermore, while the special bits are commonly overlooked, they have important meanings with incredible significance in terms of security. You are encouraged to play with these permissions and read other materials in order to fully understand how they are interpreted.

Criticisms

Traditional Unix permissions date back to the early 1970s. While simple and inexpensive to implement and evaluate, they have long been criticized for being out of date and woefully inexpressive compared to the power of other access control systems. Other systems (such as Microsoft Windows and other ACL models for Unix) have more than three access groups, nested groups, explicit deny lists, the ability to specify write permissions for changing, creating, and deleting (with Unix permissions they are largely the same), the ability to consider arbitrary state in evaluating the ACLs (such as time of day, network address, etc.), the ability to make files invisible to unprivileged users, and many other features that traditional Unix permissions lack.

Another important and oft-criticized fact is that Unix permissions do not exactly reflect the current state of the permissions configuration on the system. For example, while Unix checks the file permissions at the moment a file is opened, it only checks those permissions once for each open system call. This means that the permissions are only tested when you first open the file for reading, writing, or executing, not each time you access or modify the file's contents via an open file descriptor. If a user opens a file, and immediately thereafter all permissions on that file for that user are removed, the user with the open file descriptor will still have access to the resource according to the permissions set when the file was opened, even if the current permissions deny reading, writing, or execution.

Furthermore, the traditional Unix permissions and authentication system assigns group membership and other credentials at login time and never checks them again -- this means that system password, login permission, group membership details in /etc/group and other details changed after you log in are not reflected in your processes until you log out and log back in or the process with those credentials is restarted. For example, this means that any change to a user group is fully applied only when all affected processes have been restarted. Another example is that if an attacker steals a password and logs in to a system before that account is disabled or the password is changed, the attacker will still have that level of authentication until he or she logs out.

These design decisions were made to limit the space occupied by and CPU cycles spent evaluating system permissions. As long as the semantics of the system (including the above criticisms) are fully understood, it can be an effective, acceptably secure solution for many purposes. In fact, in some ways, its simplicity and even naivete make it more transparent and easily understandable when compared to more complex systems. For these and many other reasons, the traditional Unix file permissions are still in wide use, over 40 years after their initial deployment.

sudo and Alternatives

Some applications simply require stronger guarantees, finer granularity, or other features that the traditional permissions cannot express. For those applications, users have many alternatives. sudo is one simple extension to traditional Unix permissions that has become very popular.

sudo is a setuid root application with its own ACL (stored in /etc/sudoers) that specifies, with fine granularity, tasks that users and groups can perform as root. For example, sudo could be used to allow a user to act as root in order to kill processes with a specific name. The user would otherwise have no additional privileges. This is an example of a perfect use for setuid root programs -- granting strongly-constrained privileges to unprivileged users.

However, sudo is a double edged sword. On the one hand, it greatly enhances the expressiveness of Unix permissions without actually changing the permissions system. On the other hand, if improperly configured, it offers easy access to root. For more information on sudo and the sudoers ACL format, please see the manpages for sudo and sudoers (the configuration file), or other sudo-related material online (in particular regarding sudo exploits).

Beyond sudo, two broader and more revolutionary alternatives for Linux permissions include SELinux and grsecurity, while other options exist including LDAP, Novell eDirectory, and other permissions systems for other operating systems. (We won't be using any of these.)

Software Tools

adduser, chfn, passwd: add users to a system

adduser is the tool available for adding users to the system. To create a new user, execute:

$ adduser username

adduser will copy files from the /etc/skel directory to become the new homedir of the new user in the /home/ directory. You can specify a different home directory or automatically add the new user to groups; those options can be found in the adduser manpage.

adduser does not set any finger information for the user (this is not strictly necessary anyway), but the tool chfn will do that:

$ sudo chfn jimbo
Changing finger information for jimbo.
Name []: ...

By default, the user is created with a "locked out" account with no password set. To set the password, use the command passwd:

$ sudo passwd jimbo
Changing password for user jimbo.
New Unix password:
Retype new Unix password:
passwd: all authentication tokens updated successfully.

passwd will complain if it doesn't like the password you enter, but will accept anything with enough prodding.

Once an account is created, you can log into it in a number of ways:

1. If logged in to the system where you created the account, you can execute ssh newuser@localhost to reconnect locally as the new user with the new password.

2. If local, you can also use the su command su newuser to change to that user. This does not always update all access credentials, however. This method can also be used to become root by entering sudo su -.

3. If logged in to your XDC, you can ssh to the node as the new user.

groupadd: add groups to a system

groupadd adds a new group to the system with a unique ID (by default). Example:

$ groupadd newgroup

See man groupadd for more information.

usermod: modify a user

usermod can be used to modify many details of a preexisting user account. For more information, see man usermod.

chown, chgrp: change ownership of a file

chown stands for change ownership and is (unsurprisingly) used to change the owner and group of a file.

The syntax is very simple. To change the owner of a file, execute:

$ chown newowner filename

To change the owner and group classes of a file, execute:

$ chown newowner:newgroup filename

chgrp stands for change group and works very similarly to chown. To change the group of a file, execute:

$ chgrp newgroup filename

Recursive and other options exist; see man chown or man chgrp for more information.

chmod: change the mode of a file

chmod stands for change mode and is used to change the permissions mode of a file. Earlier, we discussed how the POSIX ACL has three access classes. User (or owner), group, and other (or world). The permissions mode for each access class can be changed by the chmod command.

There are two ways to use chmod; one is an absolute numeric mode and the other is a symbolic mode.

chmod: absolute -- setting the permissions explicitly

In the absolute mode, chmod takes a file mode in 3 or 4 digits, each of which represents the absolute permission mode for one access class expressed in octal, where each number is a sum of the permission bits. Each permission has a unique value: read permission is 4, write permission is 2, and execute permission is 1. These values represent the position of the permission in a 3-bit value.

For example, the mode 777 means "full permissions" because all bits are set in each access class. Similarly, 000 means "no permissions" because all bits are unset in each access class.

The 3-digit mode 777 is the equivalent to the 4-digit mode 0777 where the leading 0 represents the "special" permission class of setuid, setgid, and sticky. Likewise, the modes 000 and 0000 are equivalent and represent the absence of permission. (The owner of the file and root still have the ability to change the file's mode by virtue of their ownership and superuser status.) Finally, if the 3-digit mode is used, chmod always assumes that the special access class is 0. Therefore, if you set an suid-root file to mode 777, chmod assumes that you meant mode 0777, which would take away the special permissions. This is consistent if you remember that octal modes represent absolute permissions and the special group class is assumed to be 0 if a 3-digit mode is provided.

The following is a table to help calculate permission modes:

For example, full access is 0777, which represents:

There are no special bits set, so the special octal digit is 0, while all three bits in each other class are set. Each set of bits totals 7 (4 + 2 + 1), so the mode is 0777.

Another example is mode 2755, which represents setgid (2), plus "full access" for user (4 + 2 + 1) and write and execute (4 + 1) access for both the group and other class.

Absolute modes are applied like this:

$ chmod 0755 somefile.sh

Absolute mode is great for setting things to be exactly what you want, or imposing a radically different order onto a file or directory, but it's not very good for adding the sticky bit to a file. For that kind of work (or if the octal modes just confuse you) the symbolic mode is well suited.

chmod: symbolic -- more user-friendly

The symbolic mode works pretty much the way you would expect. To add the execute bit to the user class, you would execute a command like this:

$ chmod u+x somefile.sh

Or to add execute to all three classes:

$ chmod ugo+x somefile.sh

To make a file setuid:

$ chmod u+s somefile.sh

To remove all permissions:

$ chmod ugo-rwxsgt somefile.sh

Some people are so put off by the absolute mode that they never learn it -- you'll find with experience that both methods of setting permissions can be expeditious depending on the situation. More information is available in the chmod manpage.

Regardless of how you set permissions, it is critical that you use the "principle of least privilege" and only grant the privileges that are necessary for proper operation.

Introduction

You are Wilbar Memboob, the Security Administrator of FrobozzCo ("You name it, we make it"). You are looking to hire a new system administrator to replace the guy you just fired -- unfortunately, even though his resume looked great on paper and he interviewed well, once you put him at a console he clearly had no idea what he was doing.

To him, proper permissions meant that the application worked; if it was secure then that was just icing on the cake. You should have done something when the other admins starting calling him "Triple-7" -- a.k.a. "wide open". But it was when he changed the company fileserver directory permissions to "ugo+rwx" and the projected budget was "released" early -- including a list of the employees being laid off -- that he signed his own pink slip.

To keep this from happening again, you've created a little test for your new applicants to take. Unfortunately, before you can grade the applicants, you need to create an answer key.

Assignment Instructions

In the assignment portion of this exercise, you're going to create an answer key for your "hiring exam." You'll need to swap in your nodes and complete the exercises below.

Setup

1. If you don't have an account, follow the instructions here.

2. Create an instance of this exercise by following the instructions here, using posix as Lab name. Your topology will look like below:

   .

3. After setting up the lab, access your posix node.

Changes to SPHERE nodes are lost when the nodes are swapped out. This means that you must manually save your work between working on nodes in order to keep it. However, this exercise includes experimental scripts to help you save and restore your work.

Saving your Work

After completing the POSIX exercises on the posix node, cd into the /root directory and execute the script /root/submit.sh; like this:

$ ./submit.sh

...it will make a tarball of all the relevant files and their permissions, including the /root/permissions-answers.txt file. You must copy or move the created tarball into your group directory, otherwise it will be lost upon swapout.

Restoring Your Work

The experimental script /root/restore.sh on the posix node, takes as input the path to a tarball created by submit.sh described above and restores the files to their proper locations on the system. This includes all the files you are asked to create or change in the first part.

To use the restore.sh, copy a tarball created by submit.sh into the /root/ directory and execute this command:

$ ./restore.sh username-permissions-123123123.tar.gz

You will be asked if you want to automatically overwrite files, and if you want to selectively restore some files and not others. The options are self-explanatory.

Finally, if you don't trust the scripts, you can always make your own backups into your group directory and restore them by hand if you prefer.

larry ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf

Submission Instructions

Submit a tarball created by submit.sh to your instructor. You must use a tarball created by this script so that it will correctly save the permissions of the directories.