Trusted Code Base in a UNIX environment

[Mike Owen]

<<<<<<<<
This is still not very precise, so I guess I'd like to consider this
from a number of perspectives: first, how does the concept of a TCB play
out in the Orange Book requirements.  Second, if a well-defined TCB is
required (whether for Orange Book reasons, or because it's just a good
idea), what procedure should be used for determining which system
components should be part of the TCB?  Third, what protection is
required for elements of the TCB, and how does this map into the various
access control ingredients we can assume will be present (existing uid,
gid protections, kernel/securelevel protection, as well as enhancements
such as mandatory access control, capabilities, ACLs, et al). Fourth,
what implications does this have from the perspective of further code
implementation, auditing, and design? 

>>>>>>>>>>

 From what I understand, it's generally accepted that a TCB is as small
as you can possibly make it. While I don't know the specifics of all
evaluation systems, you can generally expect that more code means higher
cost, and if TBSD were to be evaluated at any time (and I don't even
know if this is a consideration - is it?) you can expect that all of the
TCB code would have to be inspected by the organisation doing the
certification. As a result of this, the TCB would need to be precisely
defined. Even if this weren't a requirement, it's a very good idea. I've
only participated in one evaluation, but we had to identify every line
of trusted code in our product, and write justifications for any
sections which we argued didn't need to be trusted.

I think a standard model (for doing this from the ground up) would be to
implement a trusted microkernel that everything else could sit on top
of. Obviously this isn't an option, so we should consider what Sun did
with Trusted Solaris. Does anyone actually know how Sun went about this?

What I'm guessing is that the TCB for an already implemented OS would be
any part of the system which controls access to the devices, files, and
memory, but which sits on top of the standard OS. If you could set up
the controls in a comprehensive manner, (ie: set up the controls as a
sort of interface everything (users, processes, everything!) has to pass
through to get to the devices, files, and memory), then the TCB would be
this control system. In sections where this control system was part of
the kernel, you would probably have to be able to establish that other
sections would not be able to interfere with the control sections. 

While I don't know for certain, I'm guessing that this is what Axent (I
think it was Axent) did with Pitbull - it's a ITSEC E3-FB1 certified
layer that sits on top of normal Solaris, and does what I just
described. So they obviously either had help from Sun, or managed to
establish that they didn't need to trust the underlying OS.

Thoughts, anyone? I should point out, if it isn't obvious already, that
I'm very, very new to FreeBSD, and to OS architectures in general. I've
read some theory on secure operating systems, but not much else. So if I
say something that makes no sense, tell me..

cheers,
Michael
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message