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: [EMAIL PROTECTED] [mailto:redhat-lspp- > [EMAIL PROTECTED] On Behalf Of Joe Nall > Sent: Wednesday, July 05, 2006 4:42 PM > To: Chad Hanson > Cc: [EMAIL PROTECTED]; 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:[EMAIL PROTECTED] > >> Sent: Monday, July 03, 2006 3:45 PM > >> To: Klaus Weidner; lspp-list > >> Subject: Re: [redhat-lspp] Getting rid of multilevel objects > >> > >> > >> > >> > >> --- Klaus Weidner <[EMAIL PROTECTED]> 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 > >> [EMAIL PROTECTED] > >> > >> -- > >> redhat-lspp mailing list > >> [email protected] > >> https://www.redhat.com/mailman/listinfo/redhat-lspp > >> > > > > -- > > redhat-lspp mailing list > > [email protected] > > https://www.redhat.com/mailman/listinfo/redhat-lspp > > -- > redhat-lspp mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/redhat-lspp -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
