Low Watermark MAC (LOMAC) implementation for Linux

[Andreas Gruenbacher]

Robert Watson wrote:
> 
> On Thu, 14 Oct 1999, Ilmar S. Habibulin wrote:
> 
> > On Thu, 14 Oct 1999, Casey Schaufler wrote:
> >
[snip]
> 
> I'm also interested in how the Solaris folk fit ACLs (and presumably other
> things) into their FFS.  One of the things that I think is important is to
> give ACL/other security-relevant tags the same atomic update properties
> that attribute information in traditional inode structures has--i.e., in
> the event of an untimely power loss, it's not possible to end up with the
> inode but not the associated ACL or MAC data.  Fitting the data into the
> inode directly might be one way to do this, but it's probably desirable to
> have a general extension mechanism (such as XFS-style attributes,
> possibly?) so we don't have to keep modifying the file system.  This can
> result in painful upgrade procedures, divergences in mainstream and secure
> code, etc.

Here's something about the `Solaris way':
<http://www.sunworld.com/swol-06-1998/swol-06-insidesolaris.html>

> 
> I'm out of town this weekend, but I think the next step in BSD support for
> ACLs/MAC support in the FS is to add support in the VFS/vnode layer for
> requesting and modifying these attributes.  How that interface looks
> depends a bit on whether we have a general-purpose extension mechanism or
> not.  Given the proliferation of various file systems at this point, it
> might make sense to add kernel-level VFS interfaces such as getacl,
> setacl, getmaclabel, setmaclabel, and let the file system decide how to
> store this data.  This might allow the hiding of AFS or Coda ACLs behind a
> POSIX.1e ACL interface, which would probably be quite desirable, if
> feasible.  There are downsides to this, of course, including that the
> vnode/vfs layer is now aware of a particular kind of ACL interface or MAC
> interface--of course, it already knows about permissions, and in a sense
> it's just passing back and forth binary blobs most of the time for ACLs as
> the FS layer itself enforces the limits, I believe.

What I did for Linux ACLs is the following. Maybe it helps. (Note that
the current version on the Web does things more little stupidly.
I'm describing the code that I've got in pre-pre-Alpha):

- Two syscalls acl() and facl() much like the Solaris sycalls.
- Each inode has a set of inode operations. I added a new inode
  operation acl(). VFS simply looks up the right indoe and forwards
  the call. That way, different types of ACLs can be supported by
  different filesystems.
- For Posix ACLs, there is a set of routines that the filesystem
  functions use.

Site: <http://major.rithus.co.at/acl/>


Cheers,
Andreas

------------------------------------------------------------------------
 Andreas Gruenbacher, Vienna University of Technology
 a.gruenbacher at infosys.tuwien.ac.at
 Contact information: http://www.infosys.tuwien.ac.at/~agruenba
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message