CAPs, MACs, ACLs, FreeBSD implementation

[Robert Watson]

On Fri, 1 Oct 1999, Ilmar S. Habibulin wrote:

> Here is some ideas of the implementation all of the posix features under
> freebsd. The main difficulty for me in it is the placing of all posix
> security attributes in file inodes and process descriptors. While process
> descriptors can theoretically grow up in size (sizeof(struct proc)), inode
> can't (on-disk inode i mean). So we have to create new fs - that's no a
> good solution, imho. I offer the following approach - in the inode
> structire we have 2*sizeof(int32_t) bytes, that we can use as a pointer to
> some disk block containing MAC labels, Capabilities, ACLs, Information
> Labels and so on. The same thing i think we should do with the proc
> structure. Include a pointer to some structure, containg process related
> posix security attributes (like p_cred).
> 
> The main problem is in my curve hands. :( If you approve this approach
> could someone help me in coding this pointers/structures. Especially
> filesystem one?

Ilmar,

I posted a summary of some of the FS supporting options for ACLs to the
FreeBSD list yesterday evening--I'll forward a copy here also.  It
basically came down to the fact that the infrastructure for easy file
system modification isn't there.  Your best bet may be to build the
process infrastructure and syscalls, and for the time being avoid the disk
state issue.  As mentioned previously, the Linux people have the same
problem with finding a place to store their state.  With both ACLs and
Capabilities, you can still address some of the architectural
issues--presumably the VFS needs to updated with some additional calls
against vnodes, which for the time being will not be implemented by the
standard file systems.

A good candidate for testing file systems is MFS--your changes don't get
preserved and you don't have to fix fsck to deal with the mess you make.
However, I believe MFS shares a lot of data structures with FFS--this will
need to be fixed first.

I'll forward in my email, recognizing that it is a little FreeBSD-specific
because it addresses the avenues offered by the FreeBSD kernel for
expanding file system support.

Probably the easiest way to get support in there is to write a userland
layer based on one of the several available userfs implementations.  Both
Coda and Arla provide (fairly heavy-duty) userfs support.  There's also
portalfs as an example, and some people have used local NFS (i.e.,
sharity, etc).  None of these are really ideal, but Arla's kernel module
is fairly clean and supports parallelism.

  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