> I was wondering if anyone has seen any papers comparing & contrasting
> type enforcement vs. a chroot() setuid() environment. I have done a bit of
> research, and I have found the following.
While I cannot comment on type enforcement, SecureWare has a product
called the Secure Web Platform that is built on a traditional B1
operating system that includes mandatory access control (we call
it information separation for the militarily challenged), least
privilege, and an authorization mechanism. We also use chroot
to limit an application such as a web server to a section of the
file system tree.
The problem with "discretionary" mechanisms such as UNIX permission
bits and ACLs are that programs can change them. Although I totally
agree with Marcus Ranum that you can build a secure system using
existing mechanisms combined with some well-placed kernel tweaks,
the fact is that some of the applications that you are going to be
running may not be trusted (e.g., your web server) and you may not
have source to them. Simply stated, some people are going to run
this way. And they need the extra protection of a "mandatory" system
that will protect them even if the application sets its umask wrong.
In addition, individual hacks to the kernel assume that the developer
knows all holes that need to be plugged. MAC and type enforcement
offer advantages in that (if properly implemented) they protect
against all attacks, even those not thought of yet. One can also
use automatic testing to assure correctness of the OS mechanism.
Our system separates the "secure" web server, that supports an SSL
or S-HTTP protocol, from the application that services the forms-based
requests, usually by accessing an internal database over the corporate
network. The web server runs at one sensitivity level, with only
the privilege that allows it to open the SSL privileged port, and
the application runs at a different sensitivity level. There is
a privileged gateway program that sets up the plumbing between the
two and mediates requests and responses.
> 1) type enforcement provides multiple domains that allow for seperation of duty.
This can work on a traditional B1 system with B2 least privilege.
> 2) type enforcement allows for the removal of system calls from any given
> domain.
A privilege mechanism can restrict access to the "difficult" system calls.
If the privilege mechanism is granular and privileges can be assigned to
different programs, you get the separation of power that you want.
> 3) type enforcement requires a configuration of who can touch what. This can
> be useful for triggering alarms & potentially strong audit data.
This is indeed the hard part. People are used to a type of system, and
you can't make it so different that they will make configuration mistakes
that will make the mechanisms of the system inoperable or unsafe. Our
approach has been to hide the configuration behind simple administration
interfaces that themselves are accessed by authorized users.
> The one thing that I see as a potential downfall to the integrity of type
> enforcement is configuration. It appears to me that it could be cumbersome &
> very detailed. I myself feel the KISS approach is always best, and type
> enforcement seems to break this rule.
The mechanism of type enforcement, as well as traditional MAC/least
privilege, are appropriate protection mechanisms, and enhance the
security of a perimeter system such as a firewall or web/SQL gateway.
Either the product supplier has to provide tools that allow simple
administration, or the system has to be put together by a security-
knowledgeable integrator, where security has to be considered along
the entire deployment path of the application. As we all know, this
type of knowledge is still in very short supply in our industry.
> I would be very interested to hear comments, and extremly interested to see a
> paper on the subject.
Check out our web page, http://www.secureware.com, and look at the
white paper on the Secure Web Platform. The first application of
this technology is the first Internet bank, Security First Network
Bank. They have a high level description of the security archictecture
of the bank at http://www.sfnb.com.
> Jeromie Jackson
> Garrison Associates
> jeromie @
garrison .
com
David Arnovitz
SecureWare, Inc.
|
|
