--- "Knoke, Jim (US SSA)" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
