All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: Ros: Re: enhanced security for Linux, from Stephen Smalley
@ 2001-01-10 15:58 Badger, Lee
  2001-01-10 17:52 ` Casey Schaufler
  0 siblings, 1 reply; 5+ messages in thread
From: Badger, Lee @ 2001-01-10 15:58 UTC (permalink / raw)
  To: 'open-source@csl.sri.com',
	'selinux@tycho.nsa.gov'

Casey,

I have to strongly disagree.

> Unfortunately, I see no way that the industry can take
> advantage of it. We've been pushing B1 (now LSPP) as the
> ultimate COTS security solution since the late 1980's
> and we're not going to drop that investment any time

As one of the creators of Domain and Type Enforcement (DTE), I have to
tell you that type enforcement is pretty different from MLS.  It is
highly configurable.  It allows us to trust but still confine programs
that must generate high-integrity data, or that must write "down" in
the sensitivity lattice.  It allows us to sandbox critical processes
in highly restrictive access control environments while leaving most
of the other processes unaffected.  It can support Biba, and
Clark/Wilson style integrity policies.  It can support notions such as
controlled execution.  It can of course support assured pipelines.
These are all capabilities that are natural for Security-Enhanced
Linux (SELinux), and that are very important for commercial
applications, but which are difficult, at best, with B1-like systems.
The confidentiality lattice just wasn't designed with these things in
mind.

I see many ways that industry can use these capabilities.  Just
consider any web farm.  Any 24x7 server.  Any organization that uses
servers that could be penetrated externally (e.g., the buffer overflow
attacks documented by CERT).  SELinux can and should also be applied
within organizations.  Firewall perimeters are getting weaker, and
there is an increased need to harden all host systems.  The label
lattice of the orange book doesn't help much there, but a system like
SELinux provides a very appropriate set of tools for applying access
controls so as to appropriately harden interior systems.  This makes
lots of sense for servers, today.  Client workstations are harder to
configure, but, ultimately, this approach may help there as well.

> throw that away, even for a vastly superior technology
> (Hey! I *AM* Dilbert's Boss!) which DE does not appear
> to be.

I would not claim superiority for SELinux in the area of
confidentiality or in the area of general assurance.  But for
integrity and flexibility and the ability to support confinement
policies of interest to commercial customers (i.e., like confining
those CGI scripts), SELinux provides a _much_ more useful set of tools
than Orange Book systems.  For these kinds of problems, SELinux
deserves a close look.  It has different goals from those of the
Orange Book, and is not an equivalent to B1.

Lee

Lee Badger
Chief Scientist
NAI Labs, Network Associates
443.259.2382 voice
301.854.4731 fax
lbadger@nai.com


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2001-01-16 19:51 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-01-10 15:58 Ros: Re: enhanced security for Linux, from Stephen Smalley Badger, Lee
2001-01-10 17:52 ` Casey Schaufler
2001-01-13  1:18   ` Nelson Rush
2001-01-16 17:16     ` Casey Schaufler
2001-01-16 19:51       ` Nelson Rush

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.