Date: Mon, 13 Oct 1997 11:41:09 +0100 From: Colman Reilly <careilly@monoid.cs.tcd.ie> To: Douglas Carmichael <dcarmich@mcs.com> Cc: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: C2 Trusted FreeBSD? Message-ID: <199710131041.LAA08912@monoid.cs.tcd.ie> In-Reply-To: Message from Douglas Carmichael dated Sunday at 20:25.
next in thread | raw e-mail | index | archive | help
[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
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.
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.
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.)
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.
What's my interest? Well, some of you may remember me asking about a
security model for FreeBSD a while back. I'm currently working on a
mathematical model of the security aspects of the current system, which I'm
intending to match against both the implementation of the system and the C2
requirements in order to identify mismatches in either direction. (This,
some testing and some documentation would probably take us to something daft
like (F-C2,E4), which is equivalent to C2 with rather stronger assurance.)
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.
>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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710131041.LAA08912>