Low Watermark MAC (LOMAC) implementation for Linux

[Robert Watson]

On Thu, 14 Oct 1999, Ilmar S. Habibulin wrote:

> On Thu, 14 Oct 1999, Casey Schaufler wrote:
> 
> > We've got a little bit of a dilemma here. On one hand, we'd
> > love to say that the extended attribuites of XFS are the way
> > to go. On the other hand, we recognize that XFS may never be the
> > default file system for Linux. For file systems other than XFS
> > another mechanism may be required.
> Can you point some url, describing this fs or somehow describe it by
> yourself?
> 
> > So, until XFS is available, a file system independent scheme may
> > be the most appropriate. I have attached (PostScript - sorry) a
> > description of what we did before we had XFS. It's not actually
> As i understand it is something like quotas in ffs, am i right? This
> approach was proposed by Robert. I don't understand why my thoughts were
> not supported? Is an idea of some improvements in ffs so terrible? ;-)

Well, the idea of updating FFS I think is a good one--perhaps to have some
generic attributes support of the type XFS appears to have.  Please
forgive my ignorance as to the design of XFS--I've mostly lived in Linux-,
Solaris-, and BSD-land in the past few years, so am not familiar with it's
particular quirks/features.  Anyone have a good reference for the
design/implementation of XFS online, or in a journal or the like?

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.

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.

For the MAC data, however, that's a different question,..

  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