Date: Mon, 13 Oct 1997 13:46:02 -0400 (EDT) From: Brian Mitchell <brian@firehouse.net> To: Colman Reilly <careilly@monoid.cs.tcd.ie> Cc: Douglas Carmichael <dcarmich@mcs.com>, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? Message-ID: <Pine.BSI.3.95.971013133750.23319A-100000@shell.firehouse.net> In-Reply-To: <199710131041.LAA08912@monoid.cs.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
> Could FreeBSD be made to comply with B1 or C2 trusted system standards FOR > REAL (unlike NT that can only comply when not hooked up to a network)? > > Well, certainly it could achieve C2, though we would need to do a *lot* of > documentation and testing work, and we may need to include an ACL list based > filesystem, that depends on your reading of the Orange Book. I'm not > experienced enough to tell what the "normal" interpretation of the > requirement that access should be controllable down to the granularity of a > single user is. In principle one can deny access to an object by creating a > group with everyone except that user in it and set that to be the object's group > but I'm not sure a certification group would consider that adequate. I'm fairly certain acl is _not_ a requirement in the dcl segment of c2. acl is, after all, just another form of group control at its very base. > > Code to handle the C2 auditing requirements is being worked on by someone > whose name I don't have handy on this machine, (sorry). The main problem > after that is adding the appropriate code to all the syscalls and the > relevant programs. Yes, that would be me. And yes, adding the apropriate code to the syscalls is the main problem. > > I think it's mostly admin and verification work after that. > > As for B1: well, that is an interesting problem. Could we hack FreeBSD to > include labels? Yes. Can we do it without breaking existing software? I > don't know. > > The problem is that B1 is the first level at which Mandatory Access Control > is introduced, which requires that you associate with each object (process, > file, whatever) attributes, to include a sensitivity label (top secret, > confidential, etc.) and what is essentially a project label. Essentially, > information is only allowed to move from an object with a lower or equal > sensitivity to one of a higher or equal sensitivity label and not vice > versa. (Not exactly correct, but good enough for this discussion.) > Yup, this is one of the biggest problems. You cant write to an object unless it has a security level that is precisely the same. You can only read unless it is the same or lower. Most people don't come close to needing B level security; and it is arguable if it is useful for commercial systems at all. For those who want to learn more, the final evaluation reports for several trusted unixes are available online. Trusted Xenix being one of the more interesting ones (b2) - TIRIX is also online (b1) and NT (c2). > Now, if we introduce such things we get a somewhat different view of the > world than the traditional UNIX-like security model. I do not know if it > possible to maintain a good enough match to enable us to continue to easily > port UNIX based software to FreeBSD. > Most unix admins dont easily give up the whole idea of the superuser, which would probably be required for B level. > There are also some formal engineering requirements to be statisfied if I > remember rightly. (I don't have the Orange Book to hand, just the equivalent > European ITSEC document, which seperates assurance and security claims.) > > I know there are several UNIX-like B-Class OSes out there, but I'm not sure > whether they break the standard UNIX security semantics. Our more > experienced brethren would have a better idea and will no doubt express > their views in their normal reserved manner. They do, they do. Their level determines how much they break, but even b1 systems dont generally have superusers. Trusted Xenix is just ... bizarre. Sorry, that;s the best description I can come up of it, based on the final eval report. > After (if) I get that work done, I'd be intending to look at how extending > that model to a B-Class system would affect the semantics of the system and > how badly (or if) it would break the existing software. I don't think it > has to break any software unless it trys to directly handle security things > like password authentication. > > Now, this is a fairly ambitious project, and I'd be suprised to get past the > C2 aspect of it in time for my PhD, but we'll see what happens. > > The problem with that is the money that the certifaction process would > require, of course.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.971013133750.23319A-100000>