Moldy MAC labels under TRIX, VFS layering issues with MAC.

Robert Watson rwatson at FreeBSD.org
Wed Aug 23 23:53:04 GMT 2000


I was glancing through the MAC implementation on the oss.sgi.com site this
evening, and keep coming across the term "moldy", and was wondering what
that referred to :-).

I also observed that the MAC checks in TRIX seem to occur at the syscall
layer, rather than in the VFS itself.  I've been thinking a bit about
interactions between a VFS and new MAC checks -- in BSD, the access checks
for vnode operations generally occur within the file system
implementation, rather than above the VFS in the syscall implementation.
I'm of mixed opinions about VFS interactions with both capabilities and
MAC labels.  My ACL implementation defines only the syntax for ACLs and
available calls above and at VFS, and leaves the semantics to the
individual file system.  As with permissions and file flags, different
file systems can have different interpretations of the discretionary
rights on files -- AFS, for example, emulates or ignores permissions,
relying on its own DAC mechanisms.

For capabilities, the file systems implement the capability semantics such
as DAC override, but storage of capabilities on files is currently managed
at the syscall/service layer, relying on extended attributes provided by
the file system for capability storage (and the reserved $posix1e.cap
label). 

Ideally, I suppose these would permeate the system, allowing sources of
capability/MAC information to be processed in the VFS, permitting
alternative file systems to implement MAC differently based on their
context (presumably largely through common check routines, but without
visibility above the VFS). 

Any thoughts on this issue would be appreciated.

  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



More information about the posix1e mailing list