Reference monitor concept implementation

[Ilmar S. Habibulin]

On Thu, 2 Dec 1999, Robert Watson wrote:

> On Thu, 2 Dec 1999, Ilmar S. Habibulin wrote:
> 
> > I do not know where is better to address this, maybe to -arch?
> > While reading the description of WinNT security subsystem i noticed that
> > something called Security Reference Monitor, which handles all access
> > requests and grands or denys them. That is the thing Orange Book is
> > talking about.
> 
> I've run into this sort of problem in numerous places/contexts/etc.  There
> are problems with both localized and centralized security implementations. 
> Sticking the calls in the syscall code means they can't easily or
> accidentally be bypassed, but denies your code access to the semantics of
> the underlying storage structure (i.e., different file systems may offer
> different services).  Implementing in the fs itself means local fs
Right now ALL local freebsd fs use 9bit DAC scheme. And there is no much
difference in their process in different fs drivers.

> semantics are allowed (witness different file semantics in various
> distributed file systems), but leads to other problems.  My answer with
> ACLs was to expose the syntax of ACLs in the VFS, provide a default
> implementation of the access control checks for file systems to use, but
> allow file systems to locally overide.  This means FFS w/ACLs will use the
> generic POSIX.1e ACL behavior, but AFS can overide to get AFS ACL
> semantics.  The only bug with this right now is a sorting optimization for
> submitting ACLs, and I have, and I'm working on that now.
I think that you should implement posix acl in the library. And work out
some unique and complete ACLs for fs, which will include not only rwx, but
something like add, delete, admin, etc. Just look at other ACLs and
compare them. So these new bsd fs acls would some sort of generic data,
which must be suplied by the drivers and kernel would know how to process
such data.

> I'd be tempted to go the same route for MAC--expose the MAC syntax/etc in
> the VFS, provide a default checking implementation that you hook existing
> file systems to use, but allow a file system to use its own implementation
> if it knows better (i.e., is also aware of global distributed MAC issues
> on top of local ones).  This swells the vnops a bit, but might work
> better.  You do lose the centralization of implementation a little,
> although you can keep it where desired.
I just do not understand how to do such a thing - centralized and
decentralized control. Local and remote filesystems - it is another issue.
It was somehow addressed by tsix, (c)ipso.

> The nice thing about having fs access control checking implemented in the
> fs itself is awareness of local semantics -- the syscall code can't know
> everything it needs to know about the filestore semantics.  On the other
> hand, I greatly appreciate the desire to have a reference monitor as one
> central place to audit :-).
There would be much more easy to audit the code itself.

> There was some discussion of doing capabilities in the style of the Java
> 1.2 permissions -- i.e., a central access control mechanism with localized
> definitions of capabilities.  Might want to take a look into that.
Where can i take a look at that - in jdk?

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