Working With Access Control Lists

The standard UNIX permissions model has some limitations that prevent it from allowing as much granular access control as a user may desire. For example, imagine a college English class with a teacher and students, and a workflow that allows each student to do certain things (like get homework assignments and submit them when they are finished) but does not allow anyone but the teacher to populate the "assignments" folder or be able to read each student's submitted assignment.

One way to solve this problem is to create a folder called ENG_101_Assign, owned by eng101teacher, who would have rwx privileges. A group could be created called eng101, which would contain all of the students in English 101 (and, optionally, also the teacher). The ENG_101_Assign folder could be assigned to the eng101 group, and Group privileges could be r-x (read only). Permission for Others would be "---" (no access), ensuring that only students registered in the class have access.

You would also put in a Drop Box for submission of homework assignments, owned by eng101teacher with rwx privileges, Group ownership by eng101 with -wx (write only) privileges, and Other privileges of "---". Students would use an enforced nomenclature for submitting their assignments (such as Eng101Assign5_studentinitials), and because of the time stamping of the UNIX file system, the teacher would know when the assignments were submitted.

This is one way to accomplish this task. It of course has its limitations and might not be as expandable and adaptable as one would like.

You might want to add some more granularity and features. First, you would like to allow not only the teacher to have "admin" access to the assignments (be able to put them into the ENG_101_Assign folder and view the contents of the Drop Box folder), but also allow a teacher's assistant to do the same. Also, you want to allow tutors to have specific access to certain student's assignments to assist them. You also want an automated school records system to have limited access to the ENG_101_Assign folder so the submissions and tracking can be done over the Internet. And, of course, the district superintendent wants to have visible access to everything. (But as a Mac OS X system admin, you are smart enough to not give out total access.)

How would you solve this problem? Given the limitations of the standard UNIX permissions system, you would have a very difficult time doing this by finagling folder ownership and group access, and you would have to basically "trick" the file structure to do what you want with potentially a multitude of folders and groups.

Thankfully, in Mac OS X 10.4, a system called access control lists (ACLs) was incorporated, which allows much more granular control of access to files and folders.

Understanding ACL Attributes

ACLs consist of individual access control entries (ACEs). These entries are specific to a file-system volume and are set on individual files or folders. Each ACE contains the user or group associated with the entry, and permission information to control granularity, some of which is applicable only for folders, some of which is applicable only for files, and some of which is applicable to both.

The attributes that apply to all file-system objects (folders and files) include the following:

• delete: Allow deletion.

• readattr: Allow reading of an object's basic attributes (implicitly granted if object can be looked up).

• writeattr: Allow writing of an object's basic attributes.

• chown: Allow changing the ownership of the object.

The attributes that apply only to folder objects include the following:

• list: Allow listing of the entry.

• search: Allow the folder to be looked up by name.

• add_file: Allow adding of files.

The attributes that apply only to nonfolder objects include the following:

• read: Allow read access (like an "r" permission).

• write: Allow write access (like a "w" permission).

• execute: Allow execute access (like an "x" permission).

• append: Allow write access, but only for appending to the file, not overwriting what already exists.

Folders also allow ACL inheritance, meaning that files within the folder, or subfolders, can inherit the rules that apply to their parent folder:

• file_inherit: Allow ACL inheritance to files within the folder.

• directory_inherit: Allow ACL inheritance to subfolders within the folder.

• only_inherit: ACL properties of the folder apply only to items within the folder (files and subfolders), but do not apply to the folder itself.

Creating ACLs Using the CLI

In Mac OS X, there is no GUI to create ACL entries. (Mac OS X Server does provide a very nice GUI interface via Workgroup Manager.) So, in order to create your ACL entries, you need to first enable ACLs for the volume (they are turned off by default) with the following command:

powerbook:~ local$ sudo /usr/sbin/fsaclctl -p / -e

This enables ACLs on the root volume / (this can be any mounted volume), and -e means "enable." (You could also give -d to "disable.")

Once ACLs are enabled on a volume, you can apply ACLs to any file or folder on that volume. In order to do this, use the same chmod command that controls standard UNIX permissions, but with the new ACL arguments, some of which you will now look at.

More Info

For more complete information on the new ACL arguments, including all of the available options for ACLs, please refer to the man page for chmod.

To view ACLs, add the argument -e to the ls l command:

powerbook:~ local$ ls -le -rw-r--r--+ 1 osxuser1 osxuser1 0 Apr 28 14:06 file1

Notice the + after the set of standard permissions, but you haven't added any ACE entries to this file, so there's nothing else to see yet. To change that to allow all members of the admin group to write to file1, execute the following command:

powerbook:~ local$ sudo chmod +a "admin allow write" file1

To view your handiwork, look again:

powerbook:~ local$ ls -le     -rw-r--r--+ 1 osxuser1 osxuser1 0 Apr 28 14:06 file1      owner: osxuser1      1: admin allow write

Notice the additional ACL information for the file, and the one ACE that allows members of the admin group to write to this file.

To deny read access to the guest group for file1:

powerbook:~ local$ sudo chmod +a "guest deny read" file1 powerbook:~ local$ ls -le -rw-r--r--+ 1 osxuser1 osxuser1 0 Apr 28 14:06 file1      owner: osxuser1      1: guest deny read      2: admin allow write

ACEs are numbered from 1 to n (for n ACEs in the ACL). The order of entries is importantlists are evaluated top to bottom (rule 1 to n), with new entries usually being added to the top of the list. (The exact explanation of this ordering is explained later in this section.)

Note that Allow and Deny matches work differently for ACLs. Allow matches are cumulative for all matches that apply to a user, whether from user or group ACE matches. Deny matches apply upon the first ACE match.

It is possible to specify which rule number you would like to use when adding your ACE. To override the default ordering when adding an ACE, use the +a# rulenum syntax:

powerbook:~ local$ sudo chmod +a# 2 "others deny read" file1 powerbook:~ local$ ls -le -rw-r--r--+ 1 osxuser1 osxuser1 0 Apr 28 14:06 file1      owner: osxuser1      1: guest deny read      2: others deny read      3: admin allow write

To rewrite a specific ACE, use the =a# rulenum syntax:

powerbook:~ local$ sudo chmod =a# 2 "others deny read,execute" file1 powerbook:~ local$ ls -le -rw-r--r--+ 1 osxuser1 osxuser1 0 Apr 28 14:06 file1      owner: osxuser1      1: guest deny read      2: others deny read,execute      3: admin allow write

To delete an ACE, use the -a# rulenum syntax:

powerbook:~ local$ sudo chmod -a# 2 file1 powerbook:~ local$ ls -le -rw-r--r--+ 1 osxuser1 osxuser1 0 Apr 28 14:06 file1      owner: osxuser1      1: guest deny read      2: admin allow write

To create an ACE inheritance rule, use the +ai or +ai# rulenum syntax:

powerbook:~ local$ sudo chmod +ai "others allow read" file1 powerbook:~ local$ ls -le -rw-r--r--+ 1 osxuser1 osxuser1 0 Apr 28 14:06 file1      owner: osxuser1      1: guest deny read      2: admin allow write      3: others inherited allow read

Notice that the just-added inheritance rule did not get placed at position 1, but was instead placed at the end. When new ACEs are added to an ACL, each entry is sorted into one of the following four categories:

• Local deny

• Local allow

• Inherited deny

• Inherited allow

Unless overridden with the +a# rulenum or +ai# rulenum syntax, new rules will be placed in the first position available within their category. In this case, you already had one local deny rule (category 1), one local allow rule (category 2), and no inherited deny (category 3) or inherited allow (category 4) rules, so the first inherited allow, a category 4 rule, gets placed after all category 1 through 3 rules.

More Info

See the man page for chmod to see a more complicated example that includes all ACE categories.

Note

In addition to directly navigating to a home folder using the Finder, a user may also obtain access to your home folder via AFP (enabled in the System Preferences Sharing pane by allowing Personal File Sharing), SMB (enabled in the System Preferences Sharing pane by allowing Windows Sharing), and FTP.

Understanding SUID/SGID

In addition to access permissions, there is another permission-related aspect for files (it does not apply to folders) known as set user ID on execution (SUID) or set group ID on execution (SGID). This is a powerful, but potentially dangerous, attribute for a file, so understanding its purpose is crucial, because only certain files should have this bit set (and you should flag those files that should not have it set).

By setting the SUID bit on an executable file, you are telling the file system that, no matter who launches the executable file, the file will execute as though it was launched by the assigned owner of the file. For instance, the command passwd allows any user to change his or her own password. However, this program needs to run with the privileges of root (so it can appropriately modify the Open Directory password), which a user probably does not have the ability to do otherwise. So, when any user runs /usr/bin/passwd, it needs to run as though it was executed by the root user, since you don't want to give admin or root access to all users.

The SUID bit is set for /usr/bin/passwd as follows:

powerbook:/ local$ ls -l /usr/bin/passwd -r-sr-xr-x 1 root wheel 35092 Mar 20 16:26/usr/bin/passwd

Instead of the user x bit being set, it is shown as s. Since SUID is set, whenever anyone runs /usr/bin/passwd, it will run as though it was run by root (since root owns the file). Note that an executable does not necessarily need to be owned by root, it could be another owner, but if the SUID bit is set, the file will execute as though launched by the owner of the file, not by the user who actually launched the file.

The same logic applies to SGID, except instead of the file executing as though it was launched by the owner of the file, it will execute as though the person who executed it belongs to the group associated with the file (even if he or she doesn't). For instance, the lsof command needs access to attributes of the UNIX system that require membership in the kmem group, so its SGID bit is set:

powerbook:/usr local$ ls -l ./sbin/lsof -rwxr-sr-x 1 root kmem 111356 Mar 26 14:04 ./sbin/lsof

Finding Files With SUID/SGID

As part of your regular security audit, it is important to identify files that have either the SUID or SGID bit set, because these could be potential security breaches if exploited. To find all of the files on your file system that have the SUID bit set, execute the following command:

sudo find / -perm +4000 -print

To identify all files with SGID, execute the following:

sudo find / -perm +2000 -print

To identify all files with both SUID and SGID, execute the following:

sudo find / -perm +6000 -print

As mentioned earlier, it is necessary for a healthy and happy UNIX that some files have either SUID or SGID. However, you need to proactively ensure that the files with these bits set are actually the correct versions of the executable, and not surreptitiously placed clones that give an attacker inappropriate access to your system.

One good way to ensure that your files are correct is to do a regular MD5 audit on the files you know have either SUID or SGID (as discovered with the find commands just listed). An MD5 checksum ensures that the files on your hard disk(s) have not been changedif the checksum is different, you have a potential replacement, and this could be an issue. (Or it could just be an updated version of the command, but you need to be proactive to decide which it is.)