15.11. Filesystem Access Control Lists (ACL)s

15.11. Filesystem Access Control Lists (ACL)s
Prev	Chapter 15. Security	Next

Contributed by Tom Rhodes.

Filesystem Access Control Lists (ACLs) extend the standard UNIX® permission model in a POSIX®.1e compatible way. This permits an administrator to make use of and take advantage of a more sophisticated security model.

The FreeBSD GENERIC kernel provides ACL support for UFS file systems. Users who prefer to compile a custom kernel must include the following option in their custom kernel configuration file:

options UFS_ACL

If this option is not compiled in, a warning message will be displayed when attempting to mount a filesystem supporting ACLs. ACLs rely on extended attributes being enabled on the filesystem. Extended attributes are natively supported in UFS2.

Note:

A higher level of administrative overhead is required to configure extended attributes on UFS1 than on UFS2. The performance of extended attributes on UFS2 is also substantially higher. As a result, UFS2 is recommended for use with ACLs.

ACLs are enabled by the mount-time administrative flag, acls, which may be added to /etc/fstab. The mount-time flag can also be automatically set in a persistent manner using tunefs(8) to modify a superblock ACLs flag in the filesystem header. In general, it is preferred to use the superblock flag for several reasons:

The mount-time ACLs flag cannot be changed by a remount using mount -u. It requires a complete umount(8) and fresh mount(8). This means that ACLs cannot be enabled on the root filesystem after boot. It also means that the disposition of a filesystem cannot be changed once it is in use.
Setting the superblock flag will cause the filesystem to always be mounted with ACLs enabled, even if there is not an fstab entry or if the devices re-order. This prevents accidental mounting of the filesystem without ACLs enabled, which can result in the security problem of ACLs being improperly enforced.

Note:

It is desirable to discourage accidental mounting without ACLs enabled, because nasty things can happen if ACLs are enabled, then disabled, then re-enabled without flushing the extended attributes. In general, once ACLs are enabled on a filesystem, they should not be disabled, as the resulting file protections may not be compatible with those intended by the users of the system, and re-enabling ACLs may re-attach the previous ACLs to files that have since had their permissions changed, resulting in unpredictable behavior.

Filesystems with ACLs enabled will show a + (plus) sign in their permission settings when viewed. For example:

drwx------ 2 robert robert 512 Dec 27 11:54 private drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1 drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2 drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3 drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html

In this example, directory1, directory2, and directory3 are all taking advantage of ACLs, whereas public_html is not.

15.11.1. Making Use of ACLs

Filesystem ACLs can be viewed using getfacl(1). For instance, to view the ACL settings on test:

% getfacl test #file:test #owner:1001 #group:1001 user::rw- group::r-- other::r--

To change the ACL settings on this file, use setfacl(1):

% setfacl -k test

To remove all of the currently defined ACLs from a file or filesystem, one can use -k. However, the preferred method is to use -b as it leaves the basic fields required for ACLs to work.

% setfacl -m u:trhodes:rwx,group:web:r--,o::--- test

In this example, -m is used to modify the default ACL entries. Since there were no pre-defined entries, as they were removed by the previous command, it restores the default options and assign the options listed. If a user or group is added which does not exist on the system, an Invalid argument error will be displayed.

Prev	Up	Next
15.10. OpenSSH	Home	15.12. Monitoring Third Party Security Issues