[buug] ACLs implementations (was: Buug digest, Vol 1 #221 - 1 msg)

[Rick Moen]

begin Jennifer Tran quotation:
> I am interested in all info regarding to ACL on Unix.

I can tell you about ACL support on specifically _Linux_. 

Linux has third-party ACL support from multiple development projects,
with divergent approaches, all aiming to allow the administrator some
means of specifying what capabilities a process is to be allowed, and
other fine-grained permissions (including Mandatory Access Control
labels, Capabilities, and auditing information).  All require
modifications (third-party, unofficial kernel patches) to the Linux
kernel's filesystem and VFS code (umask and access-control
modifications), which sometimes take a while to catch up with new kernel
releases. The kernel maintainers have not endorsed any one approach.
Thus, implementing any of these approaches remains an advanced topic
using experimental code.

Further, there is not broad agreement on what filesystem it is best to
use with ACLs. The obvious choices are ext2 + extended-attributes
extensions, Steven Tweedie's ext3
(ftp://ftp.linux.org.uk/pub/linux/sct/fs/jfs/), the AFS implementations
from IBM/Transarc (http://www.transarc.com/Product/EFS/AFS/) or the Arla
Project (http://www.stacken.kth.se/projekt/arla/), GFS
(http://www.globalfilesystem.org/), or ReiserFS
(http://devlinux.com/projects/reiserfs/).

Adding further confusion is that the leading candidate for an ACL
standard, IEEE Std 1003.1e, was withdrawn by the IEEE/PASC/SEC working
group while it was still a draft, on Jan. 15, 1998, and thus was never
formally included in POSIX (http://www.guug.de/~winni/posix.1e/). It
nonetheless remains influential.

Generic "capabilities" support is included in 2.2 and greater kernels,
including a control in /proc called the "capabilities bounding set".
Many "capabilities" operations will also require libcap, a library for
getting and setting POSIX 1003.1e-type capabilities, which you can find
at ftp://ftp.de.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2 .
See also the Linux Kernel Capabilities FAQ:
ftp://ftp.de.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-0.2.txt

The VFS patches, filesystems extensions or other filesystem facilities
to store ACLs, patches for fsck utilities (preventing them from
"cleaning up" your extended attributes), patches for GNU fileutils,
patches for the quota tools, and administrative tools must be provided
by the various unofficial ACL-on-Linux projects, of which there are
several.

In addition to applying any applicable patches to your kernel, you will
have to enable three kernel-configuration options (all in the
"filesystems" section): "Extended filesystem attributes"
(CONFIG_FS_EXT_ATTR), "Access Control Lists" (CONFIG_FS_POSIX_ACL) and
"Extended attributes for ext2" (CONFIG_EXT2_FS_EXT_ATTR). In order to be
offered these configuration options, you must also select "Prompt for
development and/or incomplete code/drivers" (CONFIG_EXPERIMENTAL) in the
code-maturity level options, towards the beginning of kernel
configuration.

The AFS distributed storage system, originally developed at CMU,
generically has built-in support for ACLs. As such, it seems reasonable
to suspect that IBM/Transarc's leading AFS implementation on Linux, due
to have an open-source (GPLed) development fork on the near future,
would include ACL support. We have been unable to confirm that from
Transarc's documentation, thus far. This may change as Transarc
completes its open-source rollout. (Unfortunately, Transarc's
open-source fork will have a licence problem that will prevent it
shipping with Linux-based systems: It will be issued under the IBM
Public Licence, which, although open source, is not compatible with the
GNU General Public Licence the Linux kernel is issued under.)

The pre-existing Linux AFS project, the GPL-licenced Arla Project, has
reportedly been moving slowly. The quality of its ACL support is
likewise unknown.

The existing documentation for AFS on Linux, unfortunately, makes no
mention of ACLs or capabilities support:
http://www.rzuser.uni-heidelberg.de/~x42/linuxafs/linuxafs.html
http://web.urz.uni-heidelberg.de/Veranstaltungen/LUG/Vortraege/AFS/AFS-HOWTO.html

There have been two main attempts to implement POSIX ACLs on ext2 +
extensions. One was the LiVE Project, at
http://aerobee.informatik.uni-bremen.de/acl_eng.html . That effort
appears to be now defunct.

The other, and probably your best bet for ACLs on Linux today, is
Andreas Gruenbacher's Linux ACLs project, http://acl.bestbits.at / .
Gruenbacher has a well-developed ACL implementation with storage
extensions for ext2, linking the extended attributes to inodes, and with
ACLs among the data storable in those extended attributes. He
expects that porting his subsystem to ext3 will be easy.

The Samba Project now supports Gruenbacher's approach in Samba on Linux
(where it has been compiled into Linux kernels).

The Linux Trustees Project (http://acl.bestbits.at/) is a non-POSIX,
memory-based approach, loading all extended-attributes information from
a database at startup.

RSBAC (http://www.rsbac.de/) is another Linux project to implement
non-POSIX ACLs, along with a number of other security-architecture
goals.

Linux-Privs (http://sourceforge.net/projects/linux-privs /) is (was?) a
project to implement the entire POSIX draft on Linux, but may now be
defunct. These files appear to be related, and seem to be the work of
Linux kernel programmer Andrew G. Morgan (with some code by
Gruenbacher):
ftp://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2-fcap/

The ReiserFS and GFS maintainers are aware of the desirability of adding
extended-attribute support to their filesystems, but have not yet done
so. Hans Reiser is believed to favour a system implementing
Macintosh-style resource streams/forks of artbitrary length to store the
extended information, rather than extended-attribute storage within the
filesystem structure.

Andreas Dilger has spoken of the Intermezzo distributed file system
project (http://www.inter-mezzo.org /) in the near future implementing
extended attributes similar to Gruenbacher's, making future ACL support
on that filesystem (which is still in early beta) likely.

The LIDS Project (http://www.lids.org/) implements some "capabilities"
ideas, but not ACLs.

Last, Pavel Machek maintains an "ELF capabilities" kernel patch and
matching utilities, which allow the admin to strip specified
capabilities from binary executables at execution time. It does not
provide other ACL-type capabilities. The information on what
capabilities to drop for a given binary upon execution is stored inside
the ELF header, in a manner compatible with ordinary Linux operation.
The advantage to this approach is that it does not require
extended-attributes support in the underlying filesystem. Full details
are at http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html .

-- 
Cheers,           "I don't like country music, but I don't mean to denigrate
Rick Moen         those who do.  And, for the people who like country music,
rick at linuxmafia.com         denigrate means 'put down'."      -- Bob Newhart