On Fri, 25 Aug 2006, Steven M. Bellovin wrote:

> This example is precisely why I don't find MLS to be useful commercially. 
> (Even your solution is more like DTE, which is *not* the same as, say, 
> classic Bell-Lapadula.)
>
> For those who are just tuning in...  Bell-Lapadula has a label on every file 
> and every process.  The basic philosophy is "don't let anything be 
> declassified", which means that a process can't read a file with a higher 
> security label, nor can it write to a file with a lower security label. The 
> former is obvious; as for the latter, if it did that some later low-security 
> process could then read the file to which the sensitive data was written. 
> (I'm oversimplifying here; security labels actually form a lattice, not a 
> simple order relationship.)

In principle, DTE/TE provide the ability to decide what level of granularity 
in labeling is required, with DTE providing a shortcut for the labeling of a 
large number of objects.  [D]TE essentially allows you to do history-based 
access control in terms of the interactions of domains and types you define, 
with that history reduced to a state machine represented in a rule language. 
This all sounds good in theory, the problem is practice: that our systems are 
extraordinarily complex.  Is the problem TE, or our applications and 
programming environments and applications?

Maybe it's silly that daemons all like to write to the same /var/db directory 
-- this isn't just a problem for SELinux, where it results in extra rules, 
it's a problem if you use other mechanisms already available on UNIX to 
constrain applications, such as per-uid sandboxes.  Or that our programming 
systems don't export clean lists of facilities exercised by the application -- 
this is how you end up with things like SELinux and systraces adaptive policy 
writing, in which the policy mechanisms attempt to capture application right 
requirements -- typically poorly due to entirely missing exceptional cases.

Any security mechanism that is concerned with the fine-grained management of 
rights will suffer from the problem defining what rights to assign. 
Experience seems to suggest that system complexity increases lead directly to 
policy complexity increase, and that at least one challenge with fine-grained 
privilege management is trying to get the complexity of the privilege system 
to grow at most linearly with the complexity of the software system.  This 
relies on the independence of the components, which of course is immediately 
violated by the complex inter-relationships between software components that 
exist in the real world (tm).  And this is a simple problem compared to some 
of the harder problems associated tuning rights to the run-time requirements 
of a system vs. the compile-time requirements, which is what people currently 
aim for.  Fortunately, most BSD applications appear to be in relatively fixed 
configurations of relatively simple/well-defined software, such as embedded 
and server environments, and not desktop environments :-).

Robert N M Watson
Computer Laboratory
University of Cambridge