Date: Tue, 14 Oct 1997 08:16:41 -0700 (PDT) From: Brian Beattie <beattie@stt3.com> To: Colman Reilly <careilly@monoid.cs.tcd.ie> Cc: Douglas Carmichael <dcarmich@mcs.com>, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? Message-ID: <Pine.GSO.3.95.971014074219.1809C-100000@durin> In-Reply-To: <199710131041.LAA08912@monoid.cs.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
I have worked on several "Orange Book" UNIX systems. Not everybody in the INFOSEC community will agree with me on all points. On Mon, 13 Oct 1997, Colman Reilly wrote: > [cc'ed to security, where it possibly really belongs. On the other hand > raises a few issues relevant to hackers. Sorry if you get it twice.] > > [Disclaimer: I haven't had any coffee yet. This could all be wrong.] > > 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 ACL's are not required at C2, not until B3 (maybe B2 it's been a while. Also I think I could make the case that UNIX already has ACL's, small ones but the spec does not, as I recall, say how big they need to be. Most of the people involved in INFOSEC are absolutely "head over heals" in love with ACL's, big ACL's. I am not convinced of their utility in the real world, especially with suplementary groups. If I were designing a B1 UNIX system I would not change the current access control design. > 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. The UNIX design as understood by most UNIX hackers meets C2 except for auditing. > > 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. > > I think it's mostly admin and verification work after that. And a LOT of documentation. > > 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. UNIX could be made to meet B1 and, running at a single level should not break existing software, unless it has intimate knowledge of the filesystem and/or kernel data structures. fsck, mkfs whould need work, ps might. > > 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.) > > 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. > > 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. > I just built the things, you don't expect me to use them do you? :-) I do think that as long as you run at a single level you will not notice it. With carefull design, it should still be useable running at multiple levels. > > >From a practical point of view I wonder how pleased developers would be to > have heavy security review requirements hanging over them? I suspect > not very. And the requirements for both C2 and B-Class would probably > impact performance. If one wanted to produce either a C2 or > B-Class system I think it would probably need to be done as a sort > of sub-project using a restricted driver set and a restricted ports > set and with a different distribution produced which would lag a > bit behind the released system. On the other hand any sort of work > towards that level of security would greatly increase both the > security of the base system and our confidence in it. To actually get a system evaluated you would need to specify, exactly what hardware it will run on, mother-board, peripherals, etc. Every option would add significant work, in documentation and evaluation. If somebody actually wanted to get a version of FreeBSD on the Evaluated Products List, they would need to find a sponser to convince NSA (or whoever the evaluating agency is these days) to do the evaluation. There would also need to be a full-time staff member to interface with the agency. It might be possible to find somebody in DoD who would be willing to sponser this and foot the bill, but I would not know where to look. > > On the other hand, wouldn't a free A1-class operating system just be so > funny? > "Mr Gates, please explain why your operating system can't make C2 > yet that pack of wasters manage to maintain a free system at A1 > certification" > > The problem with that is the money that the certifaction process would > require, of course. > > Colman > Just replacing A1 with B1 would be a real "kick in the head".
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.95.971014074219.1809C-100000>