On Fri, 25 Aug 2006 14:44:30 -0700, "Garrett D'Amore"
<garrett_damore@tadpole.com> wrote:

> Steven M. Bellovin wrote:
> > On Fri, 25 Aug 2006 23:13:40 +0200, Elad Efrat <elad@NetBSD.org> wrote:
> >
> >
> >   
> >> MLS (Multi-Level Security) is a rather vague (and big!) term. :)
> >>
> >>     
> >
> > Big, yes; vague, no.  (Btw, Biba uses the same sort of primitives to
> > address integrity rather than confidentiality.  I could explain, but it
> > would be a vast digression for this list.)
> >
> > I do think, though, that MLS solves a problem that no one has anymore.
> > That is, it's a security mechanism designed (a) for mainframes, (b) with
> > timesharing terminals if necessary, (c) mostly without networks, and (d)
> > useful at most for the Defense Department, and generally not even for
> > them.  It's quite useless for almost any other security situation, and
> > doesn't even work for DoD in a world of PCs, all-seeing/all-dancing word
> > processors (be they Microsoft Word or Emacs), and Web browsers..
> >
> > 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
> >   
> 
> I don't agree with this.  There are applications where MLS is very
> useful.  I've been involved with solutions involving them.  For example,
> hypothetical scenario:
> 
>     Shipboard networks.  Each network is labeled.
> 
>     With MLS systems, you can have a single system at a workstation.  (A
> single terminal.)
> 
>     With normal PCs, they have to deploy one workstation per level. 
> This is very, very inconvenient.
> 
> The Navy loves Sun Ray systems running with a Sun Ray server running
> TSOL.  They can deploy one thin client (end-to-end encryption, the
> client is mostly a "dumb" terminal as you indicated), and one MLS TSOL
> system.  Cuts down shipboard IT infrastructure considerably.  Plus, when
> one Sun Ray fails, they just replace it with another one, no need to
> load software or worry about destroying persistent storage, etc.
> 
Right -- dumb terminals "solve" a lot of problems...  If you're going to
run 1970s-style timesharing machines and you want strong isolation
between different classes of processes, MLS lets you do that.  If you want
some separation between different processes of the application, but still
want to allow them to talk, you have a much harder time doing that
properly with MLS.

Here's how to think about it.  Pretend that you're not constrained by
budget, in space, power, dollars/yen/euros/zorkmids, etc.  Put every
security level on its own machine, with a dedicated network connecting all
machines at that security level.  Now what?  

If your applications need to talk between levels -- that is, between
machines and networks -- you need some sort of trusted router.  How does
this router make decisions on what traffic it should pass?  I'm willing to
assume enhanced network protocols where every packet is labeled (in a
trustable fashion) with the uid, pid, program name, or whatever else you
want, except for the security label which is implicit in this structure.
How do such routers work?  

Let's think back to the credit card example.  We'll put the web server,
the log file, and the credit card number database in separate security
levels, and hence on different machines.  The web server needs to read
credit card numbers and write to the log file.  Our secure router will
rightly block requests from, say, the log file machine to read credit card
numbers, but will permit requests from the web server.  But this web
server is subverted, so it's reading numbers it shouldn't.  How can the
router know?  

Ah, but the router can block requests from the web server to read the log
file, you say.  True -- but so can user/group/other on today's Unix
systems, especially if we do the logging via a separate process.  So what
has MLS bought us?

I could go on and on in this vein.  I haven't even begun to address the
problems of, say, web browsers (exercise for the reader: how would MLS
prevent cross-site scripting attacks?), but I've said enough for now.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb