RFC: Requirements for MAC policies and implementation

Tue Oct 10 02:07:56 GMT 2000

[ With some snipping. ]

On Sat, Sep 30, 2000 at 12:05:10PM -0400, Robert Watson wrote:
| 
| For macro-benchmarks the cost of a label load per-exec() was
| negligible.

Getting the _right_ macro benchmarks is crucial.
What are your macro benchmarks ?
[ I would suggest that a web sever making heavy use of CGI would be a
realistic and desirable macro benchmark - lots of requests, and for security
its desirable that the web server itself is not all powerful (as required
by builtin script interpreters and loadable modules) ]

| 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 would hope that BLP labels (I don't like calling MLS MAC, as it implies
its the only form of MAC) to be smaller than a disk block, but I would also
expect most ACLs to be smaller than a disk block.  So I would expect
disk access times to dominate (non-cached) security checks.  Though the
large size of ACLs may cause a change in optimal caching strategies ...

| 
| On Thu, 28 Sep 2000, Jon Tidswell wrote:
|
| > 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?

I havent seen enough to provide first hand evidence, however Ive talked to
people who have seen a few, and Ive never heard of one that is not harder.
However this has to be tempered with the fact that you get more, so perhaps
they are not proportially harder.  [ Think about all the admin tasks, if you
now add a new task _security_management_ then the work load will go up,
but you should get an _additional_ result - a more secure system. ]

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

Im sorry Ive lost my crystal ball so the following is wild speculation. :-)
I suspect that it will be no harder than current systems for operations, but
that deployment will always be harder.  A properly secure system will have a
good system configuration facility and remote management/authentication tools,
so that some of the current tasks will get easier.  I also imagine a system
which with separation of duty and greater use of least privilege allows
increased delegation of some tasks to people in more appropriate places than
the back office.  For example, addition and removal of users accoutns and
privileges should really be done by human resources (aka personnel),
but this is hard if you cannot isolate that activity from other "trusted"
activities and you cannot also stop people from editing their own privileges.
However if user accoutn management is taken out of sys admins hands, then
they have more time for things like system wide security modelling and 
source code auditing, etc.

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

Until we all have large amount of flash ram (or equivalent) we are going
to have to deal with on-disk security information ...

| 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 what happens to network file systems - where the extra accesses actually
generate netowrk packets ...

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

The bad thing about jail() environments is that theya re all setup in code
so there is no easy centralsied configuration to see that they are correct,
including no easy way to translate security policy into jail() model
configuration into actual system configuration.

I think this is why you originally suggested that Biba/MLS may be easier to
administer on a higher level than jail() - because it is easy to abstract
the security model (its a set of labels and access rules) but its not easy
to abstract multiple jail() configurations - they are buried in the code.

One of the reasons I like TE based models is that they have centralised
configurations that can be checked.  I wonder if we had a central
configuration for a jail() like facility how like DTE it would end up like.
As an analogy, you have just abstracted some VFS access control into VADMIN,
in order to stop scattering access control checks around - jail is still
scattering the access control model around.

- JonT

-- 
Jonathon E Tidswell                                          <jont at zip.com.au>
Geek on the loose.
Postgrad student, programmer, Internet aficionado, and would be security guru.
Disclaimer: I think my thoughts are my own, and I believe my writings are too.
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message