RFC: Requirements for MAC policies and implementation

[Robert Watson]

On Tue, 10 Oct 2000, Jon Tidswell wrote:

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

Right now, I'm using a large compile -- relatively small working set for
binary executions, but large for data files.

> [ 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) ]

I'll probably attempt to gather a more representative set of
macro-benchmark loads of interest, and heavy-duty CGI-oriented web serving
would certainly be among them.

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

The MAC label I've started experimenting with contains three components:

 o MLS type and level (no non-hierarchal component yet)
 o Biba type and level (no non-hierarchal component yet)
 o Optimized system partition identifier

Right now they're substantially smaller than ACLs.  Generally, disk access
for file system objects is by far dominating label access, and given
improved locality code, I'd hope that it would continue to.  That said, I
think the label access is the most noticeable aspect right now, although
I'd guess per-packet labeling will also be expensive due to expanded
working set on the CPU cache.

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

Absolutely: I'm working on a reimplementation of jail() based on the
POSIX.1e capabilities model, where the privilege-bounding effect of jail()
is an inherited capability mask, rather hard-coded as a property of each
suser() call.  Jail() is clearly a hack that can and should disappear with
the advent of more general mandatory partitioning mechanisms and privilege
management functionality.

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

Yup.  However, jail() does attempt to cleanly address the namespace issue,
which pure labeling generally doesn't.  That is, shared namespaces for
partitioned or mutually incompatible label types.  This is necessary to
some extent in the file system code (although given application
modification, much less necessary), but also highly visible in the SysV
IPC mechanism.

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

I agree, and have never disagreed with this argument: jail() is poorly
written in most respects from a security perspective, as you point out, as
it scatters access control decisions all over in a hard-coded manner,
rather than centralizing policy decisions in a flexible manner.  That
said, I actually do disagree with the DTE implementation philosophy for
the root user, as I tend to think of privilege and mandatory policies
differently.  In my mind, privilege refers to the ability to override
mandatory and discretionary protections and violate the policies.  As
such, a mandatory TE scheme would not restrict privilege, although they
might limit access to mechanisms by which privilege is gained.  Instead,
you'd want to modify the mandatory system policies by expressing something
more general in TE and reduce the use of privilege.  A slightly different
philosophy.

The canonical example here might be <1024 port number limit.  The
mandatory system policy right now is "Don't allow any process to bind
<1024".  Privilege allows overriding of that policy.  The privilege to
override that policy simply overrides that check, and is therefore not
very find grained.  A better technique would be to change the mandatory
system policy to allow binding of ports based on a central policy, or
labels on the ports.  This emphasizes improvements in mandatory system
policy, as opposed to relying on privilege.  Both Jail and the DTE
"restricting root" model seem to take the wrong approach, attempting to
bound privilege as opposed to limiting the need for privilege and managing
privilege better.  This interpretation is probably something that could be
argued about, but I think that interpretation of privilege is reasonable. 

For a reimplemented jail(), my current first pass attempt will probably
look like the following:

1) Reduce the requirement for privilege whenever possible, falling back on
   labeled system objects with flexible mandatory policies.

2) Divide privilege into logical, where possible non-overlapping,
   privileges in the style of POSIX.1e.

3) Support an inherited bound on privilege preventing the acquisition of
   specific privileges inside a partition where those privileges could be
   used to violate the partitioning policy.

4) Improve mandatory policy support so as to more generally express legal
   interactions between processes, rather than a hard-coded jail
   identifier.

jail() would be emulated by providing a hard-coded capability bound that
essentially provides the same set of suser() restrictions, but jails could
also be manually constructed by an appropriately privileged process via
modification of MAC policies, namespace, and bounds on future privileges.

  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