In conjunction with file system enhancements like snapshots, FreeBSD offers the security of File System Access Control Lists (ACLs).
Access Control Lists extend the standard UNIX® permission model in a highly compatible (POSIX®.1e) way. This feature permits an administrator to make use of and take advantage of a more sophisticated security model.
To enable ACL support for UFS file systems, the following:
must be compiled into the kernel. If this option has not
been compiled in, a warning message will be displayed when
attempting to mount a file system supporting
ACLs. This option is included in the
GENERIC kernel. ACLs
rely on extended attributes being enabled on the file system.
Extended attributes are natively supported in the next
generation UNIX® file system, UFS2.
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 generally recommended in preference to UFS1 for use with access control lists.
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 file system 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 (mount(8) -u),
only by means of a complete umount(8) and fresh
mount(8). This means that ACLs
cannot be enabled on the root file system after boot. It
also means that you cannot change the disposition of a
file system once it is in use.
Setting the superblock flag will cause the file system
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 file system without
ACLs enabled, which can result in
ACLs being improperly enforced, and
hence security problems.
We may change the ACLs behavior to allow the flag to be enabled without a complete fresh mount(8), but we consider it desirable to discourage accidental mounting without ACLs enabled, because you can shoot your feet quite nastily if you enable ACLs, then disable them, then re-enable them without flushing the extended attributes. In general, once you have enabled ACLs on a file system, 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 other unpredictable behavior.
File systems with ACLs enabled will
show a + (plus) sign in their permission
settings when viewed. For example:
Here we see that the
directory1,
directory2, and
directory3 directories
are all taking advantage of ACLs. The
public_html directory
is not.
The file system ACLs can be viewed by
the getfacl(1) utility. For instance, to view the
ACL settings on the
test file, one would use the
command:
% getfacl test
#file:test
#owner:1001
#group:1001
user::rw-
group::r--
other::r--To change the ACL settings on this file, invoke the setfacl(1) utility. Observe:
% setfacl -k testThe -k flag will remove all of the
currently defined ACLs from a file or
file system. The more preferable method would be to use
-b as it leaves the basic fields required
for ACLs to work.
% setfacl -m u:trhodes:rwx,group:web:r--,o::--- testIn the aforementioned command, the -m
option was used to modify the default ACL
entries. Since there were no pre-defined entries, as they
were removed by the previous command, this will restore the
default options and assign the options listed. Take care to
notice that if you add a user or group which does not exist
on the system, an Invalid argument
error will be printed to
stdout.
This, and other documents, can be downloaded from ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
For questions about FreeBSD, read the
documentation before
contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.