Date: Thu, 2 Dec 1999 13:35:58 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: "Ilmar S. Habibulin" <ilmar@ints.ru> Cc: freebsd-security@freebsd.org, posix1e@cyrus.watson.org Subject: Re: Reference monitor concept implementation Message-ID: <Pine.BSF.3.96.991202132814.12358C-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.9912022106320.44880-100000@ws-ilmar.ints.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > If you'll look through the freebsd source, you can see that all fs drivers > handles access requests by themselves. At the same time the codes are > equal. I suggest to change fs drivers and kernel so that fs drivers will > suply kernel with security attributes of the files(directories and so > on) and kernel will make decision on granting or denying access. > There would be much more easy to implement different access control > mechanisms in such system. > > PS. My early Mandatory Access Control implementation was coded in the FFS > driver. While trying to spread MAC to other objects i understand my > mistake. Now MAC is in syscalls. > > So what people would you say? 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 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'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. 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 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. Robert N M Watson robert@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@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991202132814.12358C-100000>