[redhat-lspp] Getting rid of multilevel objects

[Knoke, Jim (US SSA)]

Can anyone explain why MLS systems tend to require objects to dominate
their containing directory? Is it just to simplify covert channel
analysis? 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 ".."?

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

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.

> -----Original Message-----
> From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-
> bounces at redhat.com] On Behalf Of Joe Nall
> Sent: Wednesday, July 05, 2006 4:42 PM
> To: Chad Hanson
> Cc: casey at schaufler-ca.com; lspp-list; Klaus Weidner
> Subject: Re: [redhat-lspp] Getting rid of multilevel objects
> 
> On the HP CMW, /dev/null has a WILDCARD label
> 
> cmw:joe> lslevel /dev/null
> /dev/null   WILDCARD
> 
> WILDCARD is really the absence of a label (literally a null pointer
> in the API). This is equivalent to a SystemLow-SystemHigh range for
> most applications.
> 
> Directories are not ranged, but have to satisfy the constraint that
> the directory contents must dominate the directory. To create a file
> in a directory with a lower classification, the creating process must
> have the allowmacwrite privilege. Directory relabels are only
> possible if the directory is empty.
> 
> I could not find the mkupdir syscall in the online Trusted Solaris
> documentation.
> 
> joe
> 
> On Jul 5, 2006, at 2:51 PM, Chad Hanson wrote:
> 
> >
> > MLS Systems such as PitBull, HP CMW, and DIGITAL MLS+ supported
> > at least ranged directories where files of different SLs could be
> > written
> > into a single directory. These directories have a minimum and
maximum
> > SL which are used to arbitrate MLS write access. Many of these had
> > ranged devices as well to handle things such as the null device.
> >
> > -Chad
> >
> >> -----Original Message-----
> >> From: Casey Schaufler [mailto:casey at schaufler-ca.com]
> >> Sent: Monday, July 03, 2006 3:45 PM
> >> To: Klaus Weidner; lspp-list
> >> Subject: Re: [redhat-lspp] Getting rid of multilevel objects
> >>
> >>
> >>
> >>
> >> --- Klaus Weidner <klaus at atsec.com> wrote:
> >>
> >>> Hello,
> >>>
> >>> currently the MLS policy supports multilevel objects
> >>> (using a range where
> >>> the upper level is not equal to the lower level),
> >>> for example
> >>> directories, sockets, and character devices.
> >>
> >> Unix MLS systems address these cases thus:
> >>
> >> Directories: To modify a directory (e.g. create
> >> a directory entry) you must be at the same MLS
> >> label as the directory (which has only one label)
> >> and the new object gets the label of the process.
> >>
> >> Trusted Solaris adds a mkupdir(2)* syscall that
> >> takes a label as a parameter and sets the label
> >> of the new directory to that passed, assuming a
> >> set of conditions are met. These conditions
> >> include that the new label dominate the process
> >> label, and that the user is cleared for it.
> >>
> >> Trusted Irix allows a user to relabel an
> >> existing directory, again under constraints,
> >> including that the user is cleared for the
> >> new label, it dominates the old label, and
> >> that the directory is empty.
> >>
> >> Sockets: Sockets get the label of the process,
> >> period. Privilege may be used to modify a
> >> variety of the aspects of incoming and outgoing
> >> packet access. The TSIX api proved quite handy.
> >>
> >> Devices: Since /dev/tty, ptys, null, zero, all
> >> demonstrate quirky behaviors they are treated
> >> independently. Trusted Irix takes advantage of
> >> it's label type scheme to address these, while
> >> Trusted Solaris pretty much hard codes each as
> >> a special case.
> >>
> >> The Orange Book talks about label ranges on
> >> file systems, not individual objects, and on
> >> devices in the context of the labels they may
> >> have, but only one at a time. I would be
> >> interested to see how they would be argued to
> >> satisfy the B&L sensitivity requirements.
> >>
> >> -----
> >> * I think that's the name. It's been a while.
> >>
> >> Casey Schaufler
> >> casey at schaufler-ca.com
> >>
> >> --
> >> redhat-lspp mailing list
> >> redhat-lspp at redhat.com
> >> https://www.redhat.com/mailman/listinfo/redhat-lspp
> >>
> >
> > --
> > redhat-lspp mailing list
> > redhat-lspp at redhat.com
> > https://www.redhat.com/mailman/listinfo/redhat-lspp
> 
> --
> redhat-lspp mailing list
> redhat-lspp at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-lspp