Conference smurf::dec_mls_plus

476.0. "MLS+ file system policy rules and invariants" by SMURF::BAT (Segui la tua beatitudine) Tue Apr 15 1997 22:09

         <<< SMURF::DISK$NOTES:[NOTES$LIBRARY]ULTRIX_MLS_PLUS.NOTE;1 >>>
                         -< CMW Ultrix MLS+ notesfile >-
================================================================================
Note 727.0   MLS file system policy and invariants (156 in eft_mls)   No replies
SMURF::BAT "Segui la tua beatitudine"                64 lines  19-JAN-1995 15:56
--------------------------------------------------------------------------------
Some MLS File System Security Policy and "Invariants":

There are two basic policy "rules" in MLS file systems:

1.	You can't change the IL to more than the SL (and
	the converse, i.e., you can't change the SL to less
	than the IL).  This is CMW security policy.

2.	You can't change the SL of a file to less than the
	SL of the parent directory.  There is no "priv" to 
	override this.  It's a 'physical' impossibility...
	This is how MLS file systems work.

The third and forth rules are about filename SL/ILs:

3.	The name SL has to dominate the name IL (same as 
	rule number 1, but for name labels).

4.	There is no rule about the relationship between
	name SL or IL and file SL or IL.  The name label can be more,
	equal or less than the file's label.  "They can even be
	incomparable, though who knows why anyone would want them
	to be."  And I quote the author.

The fifth and sixth rules are about dominance checks:

5.	You cannot change the label on a non-empty directory.
	This is a rather arbitrary rule, the only apparent reason 
	for it is that it avoids having to do dominance checks all down
	the tree, which would have to be done because of rule #2.
	A simple way to get around it is to rename the directory, make 
	a new directory, chlabel it, and then move everything back.

6.	You cannot delete a directory and its contents unless your
	process dominates that of the directory, even if you have
	the ALLOWMACACCESS privilege.  The way to execute the rm 
	command with an SL of syshi:
    
    	/tcb/bin/setlevel -s syshi rm -r /tmp/*

An underlying difficulty to understanding which rule you are
violating when you attempt any of the above operations is that
SecureWare did not add any new error messages to the errno table
that specifically cover security-related errors. They just used
(inconsistently it seems sometimes) already existing errno values,
e.g., EIO, EINVAL, EOWNER, EACCESS, to express an error that has to
do with security policy (MAC, IL, ACL, privilege) violations. To
further complicate the matter, when we added the MLS file system
"invariants", we did not distinguish those with unique error
messages either.

For example, you will receive an "Invalid argument" error meaning it
is a MLS file system invariant because you tried to set the file SL
lower than the parent's SL.  You did not get "Not owner" or
"Privilege violation" because there is no privilege you can have
(i.e., you can even be root and it will fail). 

But, if you try and set the SL lower than the IL, you get "Not
owner" which you would think implies that there is some privilege
that you could have that would enable you to do it, but there is no
privilege you can have that will override this policy -- it is just
the inconsistency in assigning already extant Unix system error messages
(see man errno).