Trusted Code Base in a UNIX Environment

jont at jont at
Wed Apr 19 01:54:08 GMT 2000

Robert wrote asking about TCBs and monolithic BSD kernels ...

| how does the concept of a Trusted Computing Base [TCB]
| fit into a UNIX-style operating system?

He then quoted from the Orange Book ...

| For general-purpose systems, the TCB will include key elements
| of the operating system and may include all of the operating system.

| For embedded systems, the security policy may deal with objects
| in a way that is meaningful at the application level rather than
| at the operating system level.

I think there is an important choice here: if the target of TBSD is
e-commerce middleware then the important question is what features
do the middleware apps need to implement their policies, whereas if
TBSD is aimed at a more general purpose usage the OB is clearer on
what constitutes the TCB - everything.

Before he continued ...

| So a TCB is a very useful concept, but it's not immediately clear
| how various aspects of UNIX-style operating systems do or do not
| fit into the TCB.
| With a monolithic kernel design, it is clear that the kernel should
| be entirely within the TCB.  Given the presence of
| Figuring out where to draw this boundary is important from the
| perspective of understanding how the components fit together,
| and performing a comprehensive security design and analysis.

One first approximation is the contents of the root partition, but
not the contents of the usr partition,  assuming no X-server.

As someone on a micro-kernel project I agree with Mike Owen that the best
way is to build your OS on a microkernel.
But as someone on a microkernel I also know its not that simple, security
and performance tend to clash :-)

| 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.

There are two concepts:
  security kernel - the minimal code required to enforce reference monitor
  TCB - trusted computing base

The smaller the security kernel the easier it is to do everything else.
In a monolithic dynamically linked system like *BSD the difference may not
be much.
[ But for example dump/restore are clearly in the latter not the former. ]

| 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?

Lets take it that a TCB concept is required.
The only approach I can see is rational discussion and sometimes argument.
Some things are obvious (the kernel, loadable kernel modules, 'sh', ... )
and the discussion should be easy, others are harder (emacs ;-).
[ Don't laugh. Apparently a downgrader was once built on emacs ... ]

| 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).

It is my _expectation_ that it will be harder to obtain assurance relying
on a combination of many disparate mechanisms than a relying on a few
carefully chosen mechanisms.

So _if_ we need a kitchen sink of mechanisms
   _then_ I suspect we need to rethink things.

| Fourth, what implications does this have from the perspective of
| further code implementation, auditing, and design?
| One important step is to try and take advantage of work done in this
| how have other trusted operating system implementations solved this

All the anecdotal evidence says they had great problems and even greater
cost. So Im not sure we should literally follow them, though we should
learn from them.

A lot has been published, should we dig up more citations ?

| Is it as easy as determining that any code run by the root user is
| part of the TCB, or are least privileged techniques such as Capabilities
| used to restrict this further?

Two key principles will go along way:
 - least privilege
 - separation of duty

So an obvious design decision is to not run things as root.

| BSD provides securelevels as a limited form of system integrity MAC
| -- is this something we can build on, or should discard in favor of a
| stronger and more consistent mechanism such as a general MAC

As a mechanism it seems fairly strong and fairly consistent, but narrowly
For example perhaps it should be the deciding factor in enabling/disabling
ability to enable/disable extended attributes on filesystems ?

One problem with it however is that bringing a system down to do basic
is not good for the e-commerce uptime statistics.

| What mistakes have been made that we can improve on to
| come up with a cleaner (and more secure) design?

Are we really trying to find a new security design ?
For example should we follow the TRUSIX B3 ACL "silver" book ?
While B3 exceeds our requirements it may be easier to reuse than to invent
another.  Comments from the SGI folks ?

An obvious one is not knowing the customers and the requirements. :-)

Another is to try to bite off too much at once - 2nd system syndrome:
where everything including the kitchen sink is added to the second system,
whose absence is what allowed the first system to succeed.

- JonT

Jon Tidswell
Advanced OS Technology Group / Sawmill Linux Project
IBM TJ Watson Research Center 30 Saw Mill River Road, Hawthorne, N.Y. 10532

Email: jont at   Voice: +1 914 784 7550

To Unsubscribe: send mail to majordomo at
with "unsubscribe trustedbsd-discuss" in the body of the message

More information about the trustedbsd-discuss mailing list