Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Slightly Skeptical View
 on Unix Access Control Lists (ACLs)

Operating systems employ various filesystem models. ACL were traditionally used in Netware and NT as the major access control mechanism. Commercial Unixes supported ACLs for years and are the only one in which usage of this feature is recommended. The most mature is Solaris implementation.

Access Control Lists (ACLs, pronounced “ackkls”) are an attempt to add to Unix method of access control that traditionally was used in Netware and Windows NT. The main advantage of ACLs is that they can provide more fine grain control over permissions. Classic UNIX file protection provides read, write, and execute permissions for three user classes: owner, group, and world (everybody).  In this model group cannot contain other groups and there is only a single owner of the file. An ACL enabling you to add permission for a particular user that overwrite traditional model. It also enables you to define default permissions for user and group categories.

For example, you might have two groups that need permission to access a file, one to read it and one to write to it. Alternatively, you might have a file that you wanted everyone in a group to be able to read, so you would give group read permissions on that file. Suppose that you want only two people in the group to be able to write to that file. With standard UNIX permissions, you cannot give write permission to only two members of a group. You can, however, set up an ACL for that file to grant only two people in the group write permissions on that file.

Free Unixes (Linus starting with kernel 2.6 but not with kernel 2.4, FreeBSD starting from 5.1 UFS2 filesystem)  also support them on kernel level, but not on the utilities level. For example, GNU tar won't back up or restore ACLs, and NFS in FreeBSD ignores them too.  As such presence of ACLs represent huge security risk in free Unixes.

Even in commercial Unixes things are far from being perfect: Access Control Lists (ACLs) were added to the Unix as a afterthought and are weakly integrated with major utilities as well as difficult to understand.

The ACL information is stored and associated with each file individually, but is essence they provide not file-based, but user based access control: each user can be assigned a unique set of files. And each file can have unique access attributes independently of the fact if he is owner of the file on not.

If we still want to operate in "file" paradigm, then we can thing about ACLs as an extension of the owner field and group fields in traditional Unix permissions. ACLs  permit specifying multiple owners (and group ACLs permit specifying multiple groups). What is important, ACLs solve one very significant Unix limitation: group cannot contain other groups.

Not all Unix filesystems support ACLs. Solaris UFS and NFS have one of the best support of ACL in industry.

Despite existence of standard, ACL are not very portable: transfer of files with ACLs between different flavors of Unix is an exercise for brave even if both filesystems support them. 

Does ACL make sense, and, if yes, where ?

In practice, the complex functionality of many modern filesystems, including ACL functionality, is wasted because users cannot understand how to secure their files and give up trying.

There several  typical cases when ACLs make some sense:

1. To provide an access to the file for a user who is neither the owner not a member of the primary group for this file
2. To provide access to the file for a group other than the specified for this file group (owner-group)
3. To specifically exclude particular users who are a member of the owner-group from accessing the file or directory.

In many cases those cases can be solved by creating a new group with a particular membership. But in general proliferation of groups make them difficult to understand and maintain. Also most Unixes have limitation on the number of groups a user can be member of.

Also, unless a strict discipline is imposed, maintaining ACL permissions is harder and thus there is the problem that the system might become insecure because of the inconsistency of ACL (few sysadmin fully understand this mechanism)  as well as difficulty of maintaining ACL for existing files in typical operations like backup/restore, copying, etc.

One such useful discipline is that only roles, not regular accounts can have ACLs assigned.  So extended access is granted only to roles not regular users. This essentially pams user space isto two distinct categories of which only one can have ACL and greatly simplify checking the correctness of ACL assignment (any ACL present for a regular user simply becomes a security violation) as well as simplify maintaining ACL (as ACL associated with a role their description and structure becomes art of role documentation).

Supplement

NT model (NTFS)

The NTFS filesystem the whole access model is based on ACLs. Each file is owned by a specific user. Each user may belong to any number of groups. Each file has an ACL in which access can be granted or denied to any named list of users and/or groups (i.e. we can either code a rule or an exception to a rule). The access rights of each group or user are taken from the set:

• Read

• Write

• Execute

• Delete

• Change permission

• Change ownership

Note that some of the permissions restrict functionality (execute permission), others restrict access.  The means that read permissions to a certain extent overwrite the execute permission: the execute permission protection is limited to a particular copy of a file. Any new copy created due to availability of read permissions can have execute permissions for the domain associated with the current owner.  In other words protection against execution presuppose absence of read attribute.

Windows ACLs are closer to the original Multix implementation. Windows 2000 and later provides 14 ACL attributes (In the table below, the # character means this flag is selected only when the Full Control flag is set.):

A

Last modified: July 01, 2008