On Fri, 25 Aug 2006 16:51:07 -0500, "Travis H." <solinym@gmail.com> wrote:

> On 8/25/06, Elad Efrat <elad@netbsd.org> wrote:
> > Is moving data between classification levels/networks a big problem for
> > the NetBSD userbase? or, for the majority of any other mainstream OS's
> > userbase?
> 
> Well, are any NetBSD systems used in e-commerce or ebanking?
> 
> If so, I would want them to protect my financial data the best they could.
> 
> Sadly, it seems somewhat common that they leave CC#s in an
> easily-readable log file.  All it takes is some buggy PHP code and
> poof, they're the apache user, and they've got read access to the
> data.  Sometimes they don't need a shell, just a way to read the file
> from within PHP.  I don't recall if SELinux has the capability of
> granting append-only access, but even if it doesn't you could write a
> little "log append" program and grant execute and change domain access
> to it and then the apache user ID could be denied direct access to the
> file (you can think of it like a small SUID application, except you'd
> be doing it with domains instead of UIDs).  I know this isn't a
> perfect example, in that you could do it with UIDs or maybe with
> append-only attributes on the logfile, so please don't focus on
> nitpicking the example; it's the best I could think of on short
> notice.
> 
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.)

Now let's look at your example.  Let's assume that some PHP script is
writing that logfile entry.  That implies that it had the right security
permissions to read the credit card number from some file, as well as the
permissions to write to the log file.  In other words, all of those
components have to have the same security label.  (Well, almost -- the
credit card number file could be at a *lower* security label and still be
read by that PHP process...)  But that means that if the script were
buggy, it could be subverted to read *all* credit card numbers from the
file and write them to the network -- the network, after all, has to have
a suitable security label, too.  We can divide things up differently and
have some trusted process be the only one able to read the credit card
numbers -- but it's still talking to the buggy PHP script.  We need
fine-grained separation; MLS systems are incapable of providing it.  (Note
that I've glossed over the horrible security in most PHP sites -- PHP is
generally running not just with the web server's permissions, but as part
of the web server *process*, with access to all its open files, memory,
etc.  That's not funny, that's sick -- but it "improves" performance.)

My own definition of a secure OS is "one that helps us write secure, real
world applications".  I've yet to see one.

 


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