RFC: Requirements for MAC policies and implementation

[Robert Watson]

On Thu, 28 Sep 2000, Jon Tidswell wrote:

> Somewhere I missed something.  A MIB like structure to me is a text
> based tagged hierarchical data structure, not something that will ever
> be evaluated quickly.  Unix fork/exec is slow enough without making it
> slower.  What have I missed ? 

In my BSDcon 2000 paper, I describe performance measurements on exec() 
time with capability support enabled.  In general, exec() was slower when
the extended attributes were not present in the cache, but once present,
performance was indistinguishable.  Our extended attribute implementation
is fairly non-optimal, in that it doesn't take advantage of disk locality,
etc.  For macro-benchmarks the cost of a label load per-exec() was
negligible.  Now that our ACL implementation is done (I'll post it
shortly), I'll re-run the macro-benchmarks with the label loading cost
per-file and see what kind of performance hit we see.  (Keeping in mind
that ACLs are substantially larger than MAC labels).

> I had a friendly Sun rep and actually got to play with trusted solaris a
> little - it was a real PAIN to install - different enough to be a problem,
> close enough that skimming the docs it seems the same (but wasnt).

Out of curiosity -- generally, trusted systems have been characterized as
harder to administer -- have you seen any trusted systems that are not
harder to administer?  Part of the cost of administration is the
difference from the traditional model--other parts have to do with
increased seperation of duty, labeling requirements, etc.  If we took
various aspects of that out of the picture, or improved tools, what would
you think of as the optimally administerable trusted system :-).

> Trusted Solaris (2.51) was slower than normal solaris (2.51).
> [ Whether this remains true for trusted solaris 8 we will have to wait
> and see, it'll probably be out the same time as solaris 10 :-]

Performace tests against initial ACL, MAC, Capability implementations here
seem to show that the addition of in-kernel label management and access
checks generally does not introduce any noticeable performance difference.
However, management of on-disk labels is noticeable, as additional disk
latencies are added in various situations.  Once in the cache, these costs
are not apparent, suggesting that optimizing the persistent label store
would be the largest single factor in improving performance in our
implementations.  These estimates exclude the cost of network packet
labeling, since we haven't done that, and the cost of revoking VM access
to pages/mappings/files that can have their labels changed, as we also
haven't done that.

> | Also, I would imagine doing the Biba or MLS schemas would be easier on a
> | higher level to manage than a jail()-like implementation over a system
> | wide standpoint.  Am I wrong to think this?
> 
> I know of one defense site that abandoned trusted solaris for normal solaris
> because the human effort/time overheads of managing the MLS based system
> outweighed the benefits.

That doesn't surprise me.  My guess would be that there are practical
benefits to integrity and partitioning models that make them useful in
many environments, but that models such as MLS offer diminishing returns
(in most environments) over simply buying more machines.  Only in the case
of a trusted gateway do people seem interested in MLS.  That said, since
it's an easy implement, we'll do it anyway, but it's worth keeping in mind
that this difficulty in administration is likely a property of the
policies that require labeling.  The nice thing about jail() environments
is that they don't require labeling. 

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services


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