Exploiting Permission Vulnerabilities

File permissions are the primary security problem on most systems. File permissions, even though a simple concept, are often misunderstood. The security of a file is based on both its permissions and the permissions of its parent directory. There are also variations in the implementation of special permission bits and in the implementation of access control lists.

Here are some common permission problems that cause security issues.

Some Interesting Examples

In the following examples the columns in the listing are permissions, user , group , size , time, and file name . The two-line listing indicates the permissions of the directory, indicated by "." and a file in that directory, named file n. This listings could be made by using the command

ls -ld . file?

These examples illustrate the interaction between the permissions on a directory and the files it contains.

• Example 1

  Bob thinks he is allowing the users in his group to read his file, but not allowing them to modify it in any manner.

  drwxrwxr-x 2 bob software 512 . 
  -rw-r----- 1 bob software 200 file1
  

  The group permissions on the file allow all the users in the "software" group to read the files but not write to them. However, the permissions on the directory will allow anyone in the software group to rename or delete the file. The world permissions on the directory allow anyone to list the names of the files in the directory, but without access rights to the file.

  Bob did the right thing on the file permissions. It is the directory permissions that are too lax. To allow anyone to list the files, and to allow only Bob to change the files in his directory, the directory permissions should look like this:

  drwxr-xr-x 2 bob software 512 .
  

• Example 2

  Barb thinks that she has allowed the users in the "admin" group to list the files in her directory and has restricted them from access to her files by removing the write permission to the directory.

  drwxr-x--- 2 barb admin 512 . 
  -rw-rw---- 1 barb admin 128 file2
  

  The users in the "admin" group cannot rename or delete the file. However, since the file is writable by the "admin" group, anyone in the "admin" group can modify the file, including deleting all the information out of the file, leaving an empty file.

  In this case, Barb set the permissions on the directory correctly. However, the file permissions are too lax. The permissions that she should use are

  -rw-r----- 1 barb admin 128 file2
  

• Example 3

  Bill thinks that he has protected his files by removing the read and write permissions from the directory.

  drwx--x--x 2 bill dbase  512 . 
  -rw-rw-r-- 1 bill dbase 1024 file3
  

  All the users in the world have access, "x," permission to the directory, but they cannot list the contents of the directory. However, if they know the name of the file, anyone can read it and the users in the "dbase" group can modify the file.

  The removal of the read and write permissions from the directory has made it so that no one other than Bill can list the files in his directory or add, delete, or rename any of his files. The directory permissions should not include access permissions unless you want to grant that right. The directory permissions should be

  drwx------ 2 bill dbase  512 .
  

Access Control Lists

Access control lists, ACLs, are lists that indicate which users have what access rights to the information. ACLs were developed to meet the requirement where many selective users and groups need different types of access to files. ACLs provide a mechanism by which file access privileges can be defined for selected users and groups.

ACLs are an extension to the UNIX mode bits, required for "B3" security rating, allowing for more granularity of access control by allowing specific permissions to be applied to specified users. ACLs are defined as triples with the first element being a user identifier, the second, a group, and the third, permissions. ACLs are available on some UNIX systems. However, currently there are no standards on how ACLs are implemented.

Many implementations regard them as an addition to the mode bits so that if a user does not get access with the UNIX permission bits, the ACLs are checked to see if the user can be granted permission. Some implementations may test the ACLs before the UNIX mode bits. The ACLs may grant permissions on the basis of the first ACL that the user matches, therefore making them order-dependent, or they may define a "best match" for the user and grant those permissions. Some implementations add the ACLs as an additional lock so that you must successfully pass both the UNIX mode bits and the ACLs.

Posix ACLs

Posix ACLs were defined in the IEEE 1003.1 POSIX standards for discretionary access controls. ACLs did not gain broad acceptance with UNIX vendors . However, recently more systems are becoming available with ACLs, many of which do not comply with this standard. There are a number of projects in the Linux arena which are involved with implementing ACLs for a Linux file system.

The VERITAS File System ^¢ (VxFS ), which is also known as the Journaled File System, or JFS, implements POSIX ACLs. HP JFS 3.3 is included with HP-UX 11i.

ACLs are supported as a superset of the UNIX operating system discretionary access control (DAC) mechanism for files, but not for other objects such as inter-process communication (IPC) objects. ACLs allow the file owner or superuser to permit or deny access to a list of users and groups other than the file owner and owning group, which is available through permission bits. An access control list (ACL) consists of a set of one-line entries associated with a file that specifies permissions. Each entry specifies for one user-ID or group-ID a set of access permissions, including read, write, and execute/search.

• ACL Notation ” The user and group ID fields, uid and gid, can contain either numeric user or group IDs, or their corresponding character representations. The perm field indicates access permission either in symbolic form, as a combination of r, w, x, and -, or in numeric form, as an octal value of 0 through 7 representing the sum of 4 for read permission, 2 for write permission, and 1 for execute permission.

  Supported commands that manage JFS ACLs recognize the following symbolic representation:

  [d[efault]: ]u[ser]: [uid]:perm 
  [d[efault]: ]g[roup]: [gid]:perm 
  [d[efault]: ]c[lass]:perm 
  [d[efault]: ]o[ther]:perm
  

  An ACL entry prefixed with d: or default: can occur only in a directory's ACL, and it indicates that the remainder of the entry is not to be used in determining the access rights to the directory, but is instead to be applied to any files or subdirectories created in the directory.

• Base ACL Entries ” When a file is created, four base access control list entries are mapped from the file's access permission bits to match a file's owner and group and its traditional permission bits.

  u::perm   Base ACL entry for the file's owner 
  g::perm   Base ACL entry for the file's group 
  c::perm   Base ACL entry for the file's group class 
  o::perm   Base ACL entry for others
  

• Optional ACL Entries ” Optional access control list entries contain additional access control information, which the user can set to further allow or deny file access. Up to thirteen optional ACL entries can be specified. For example, the following optional access control list entries can be associated with our file:

  u:mary:rwx       Grant read, write, and execute access to user "mary". 
  user:george:---  Deny any access to user "george". 
  g:writers:rw-    Grant read and write access to members of group writers.
  

• Class Entries ” In an ACL that contains more than one user entry and/or more than one group entry, the class entry specifies the maximum permissions that can be granted by any of the additional user and group entries. If a particular permission is not granted in the class entry, then it cannot be granted by any ACL entries, except for the owner entry. Any permission can be denied to a particular user or group. The class entry acts as an upper bound for file permissions.

• ACL Uniqueness ” Entries are unique in each ACL. There can be only one of each type of base entry, and one entry for any given user or group ID. Likewise, there can be only one of each type of default base entry, and one default entry for any given user or group ID.

• ACL Inheritance ” When a directory's ACL contains default entries, those entries are not used in determining access to the directory itself. Instead, every time a file is created in the directory, the directory's default ACL entries are added as nondefault ACL entries to the new file.

HP-UX HFS ACLs

ACLs were first implemented on HP-UX on the HFS file system. These ACLs are not Posix-compliant. However, they offer the same basic capabilities to limit access to files by specific users and groups. With HSF ACLs, an additional 13 sets of file access permissions can be defined above the standard three sets of permissions (owner, group, world) that are provided with standard UNIX operating systems.

The notation used with ACLs to define file access is: (user.group, permissions) where the following symbols can be used in the user.group fields:

%Any user or any group

@The current file owner or current file group

* Used for ACL pattern matching, includes % and @

Some standard UNIX commands have additional parameters, such as the "-acl" option to the find command, or new commands which perform the same function on files with ACLs have been created, such as the lsacl command which performs a ls displaying ACLs. Not using the appropriate command or command option may lead to the accidental deletion of the ACLs.

Changing the ACLs on a file is done with the chacl command. The chacl command allows file permissions to be granted or restricted to specific users or groups. The following example shows two ACLs being added for myfile :

chacl "(%.bio,r--)" myfile 
chacl "(alex.%,r--)" myfile

The chacl command can also be used to delete an existing ACL:

chacl d "(%.bio,r--)" myfile

Use the following syntax to replace all existing ACLs on a file with a new set of ACLs:

chacl -r "(%.users,r-x)" myfile

It is also possible to copy ACLs from one file to another:

chacl -f myfile myfile2

Finally, if a file's ACLs are no longer needed, they may be zapped with the following:

chacl -z myfile

Mandatory Access Controls

Mandatory access controls, MAC, are a layer of security on top of discretionary access controls. Mandatory access controls cannot be changed by the users; the system enforces MAC consistently. Each access control method must grant access before access is given. If any of the methods denies access, then access is denied.

Even though most UNIX vendors have a secure UNIX operating system that has mandatory access control for government accounts, few bring these security features into their business UNIX offerings for commercial accounts.

Hewlett-Packard offers a couple of operating system options which provide MAC controls.

• Virtual Vault is a commercialized version of its military grade HP-UX operating system. This operating system, VVOS, offers a number of added security features designed to provide extra security for the e-business environment. VVOS uses a modified Bell-LaPadula model where every file and process contain a tag, which is composed of a compartment and a classification. A process can write to a file only when the process's tag is equal to the tag of the file. However, the process can read the file if the process's tag dominates the file's tag.

• Secure Linux is a compartmentalized version of Red Hat Linux. In general, this means that every process on the system is assigned a compartment label and can access only other processes with the same label.

  Secure Linux implements mandatory access controls through the use of compartments. It disallows any access from outside the compartment without special permission, and uses a file control table to identify the type of authorizations (read, write, append) that a process which is within the compartment has with respect to the file.