[redhat-lspp] Getting rid of multilevel objects

[Casey Schaufler]

--- "Knoke, Jim (US SSA)" <jim.knoke at baesystems.com>
wrote:

> Can anyone explain why MLS systems tend to require
> objects to dominate
> their containing directory?

Creating an object in a directory requires
both read and write access to that directory.
Only processes with the same MLS label as the
directory (ignoring "blind write up") meet
this requirement. Since the process is not
allowed to create objects at a lower MLS
label than it has, and it can't downgrade
an existing object (sans privilege) all
objects will have the same label as the
directory containing them, or higher if a
facility is available for upgrading, which
can be acceptable under the rules of MLS.

> Is it just to simplify covert channel
> analysis?

Nope. It's inherent in the B&L policy.

> Is it just a usability issue in that a
> user may get confused
> if s/he can set a working directory, but then
> potentially not be able to
> read ".."?

Nah, MLS systems put all of their usability
issues into polyinstantiated /tmp.

> Are regrades of non-empty directories typically
> disallowed just because
> of the complexity of locking all the contained
> objects during the
> regrade operation?

If Fred has /a/b/c open and Wilma upgrades /a/b
beyond what Fred is cleared for it is difficult
to argue tranquility. Not, I think, impossible,
but you need to trivialize the role of path
resolution to do so, and that opens an expired
can of worms.

> On the one hand I understand how multi-level objects
> can complicate
> analysis, but if we are to allow directories to
> contain upgraded objects
> and devices to have ranges, it sort of sounds more
> consistent to allow a
> range on any kind of object.

If I put a range of Unclass to TopSecret on a file
and write TopSecret information to it an
Unclass user can read it. This fails the MLS
requirement.



Casey Schaufler
casey at schaufler-ca.com