Storage of ACLs in file systems: platform overview (draft v1)

[Robert Watson]

So based on the emails that have gone around, and my initial readings of
various documents (could be incorrect), it looks like various OS's do ACL
storage in a number of ways.  I've described them here as I understand
them, with some commentary, but please send me suggestions!  This should
be considered draftish only.

Solaris: "Shadow Inodes"
	It looks like normal inodes can be linked to an additional inode
	that references a file describing the ACL.  The document I read
	referenced modifying the ACL in kernel via an attribute mechanism,
	so it was unclear to me whether ACLs are a hack using a second
	inode/file, or whether it is just that this file is used for
	their attribute mechanism, of which the ACL is just one part.  If
	there is an attribute mechanism, I assumed it is a named
	attribute?  Would love clarification here.

	For efficiency, these blocks are ref-counted to prevent multiple-
	storage.

	If this is a general attribute system, then this is scalable
	other types of security labels (MAC, etc).  If not, it isn't.

	It does not look like inode and ACL consistency are guaranteed.

IRIX: Attributes
	XFS supports extended attributes on file system objects, so
	ACLs are stored there.  It wasn't clear to me from the white-
	paper on XFS that I found how rights to modify attributes are
	handled--the document suggested storing icons in attributes,
	which suggests direct user modification?  If it's only the
	owner, that's fine of course, but...

	Because this is a general-purpose attribute system, it is
	scalable to the handling of other types of security attributes,
	including MAC labels.  Clearly the user-modification issue is
	relevant in this case however.

	Because I don't know much about attributes, I don't know about
	the efficiency concerns--because it sounds like it's user
	modifiable, it may be the case that one ACL is stored per
	file system object without checks for redundant storage.
	(clarification here would be great)

	Since XFS is journaled, inode and ACL consistency are
	guaranteed.

Linux: ACL Blocks
	An additional pointer appears in all file system object inodes,
	which may point to single file blocks containing ACLs.  This
	makes each ACL use one fs block, but redundancy is detected to
	improve efficiency, and a block isn't allocated for no ACL
	being used.

	Because this is sort of a hackish approach, it does not appear
	to be scalable to other security-relevant labels (such as MAC
	labels).  In theory you could add a type to the top of the
	block, but then you can't have more than one :-).  You could
	also add type/block data within the raw block, but then the
	space limitation is a problem.

	Consistency between inodes and their ACLs are not guaranteed.

*BSD: None
	No support currently available for security labels on objects.
	The suggested means include file system layers, per-fs in-fs
	storage repositories (a file in the root of the partition, in
	the style of quotas), the loose block mechanism, and a couple
	of others.  None provide much efficiency, and none guarantee
	consistency.


On all these, I'd love corrections/clarifications, or even additional
operating systems.  The major concerns in my mind are flexibility of the
labeling system (can we add new types of ACLs, security labels, etc),
efficiency of storage on disk and use in kernel (everyone sounded like
they had fairly efficient in-kernel mechanisms, but I should add that to
these), and the ability to maintain transaction-like consistency between
fs objects and the security labels on the objects--preferably also to the
rest of the meta-data layout.

This I think is important because it is easy for users of current systems
to cause denial of service attacks (power outgage, kernel crash, high
load, etc) meaning they might be able to induce a failure causing the
commital of only some of the security or meta-data on OS's that don't
support journaling.  When the system comes back up, if they are lucky or
smart, protections on objects could be weaker than they started out, or
just incorrect resulting in failures in the system that might be to the
advantage of the cracker.  For example, the disappearence of a MAC label
from an object might be bad--so might the removal of an ACL on a file (or
the use of an incorrect ACL).  Correct handling is a hard service to
provide, and presumably is best done through underlying FS support, as in
the case of IRIX.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message