I'd like to flesh out a few things about type enforcement in general
and how it gets applied in Sidewinder. If you want more information
than is given here, send mail to sidewinder @
sctc .
com .
First of all, although type enforcement (TE) and related technologies
have a sound theoretical underpinnings, they also have practical
value. I view them as software engineering tools. It makes my life
as a developer easier because it provides a single, simple,
comprehensive mechanism for constraining processes. There are many
proxies and servers on the firewall. Hacking the kernel to enforce
least privilege for every single process would be unmanageable and
error prone. Adding a few entries to the TE databases is simpler,
easier to get right and easier to test.
For an analogy, consider finite automata. They may sound abstract and
useless when you first hear of them in an introductory computer
science course, but they are of immense practical value for writing
lexical scanners or tools like grep. They provide a simple mechanism
which helps the developer manage the complexity of the problem.
TE and related technologies provide a finer degree of control than
traditional unix persmissions. These controls are by TE Domains, not
user or group ID's. Permissions for signals, file accesses (read,
write, create, destroy, rename), networking sockets (create, read,
write) on a port-by-port basis, hardware access, setting login names,
rebooting, setting the clock, "rootness", ... all of these are
controlled by the TE databases.
What this means is that it is easy for me to create a server, give it
a new domain, and specify that it has only read-only access to its
configuration files, can only do networking on the ports it is
supposed to use and only on one side of the firewall.
A note about "rootness", since it seems to get talked about a lot. In
most domains uid 0 (root) has no special privileges. In some domains
root has some traditional privileges, but these are still contrained
by the domain. For example, the ftpadmin domain has "rootness" which
means that the root user in that domain can do things like kill
process running as other users, chmod/chown files, etc, but Only if
those files or processes have domains that are already accessible to
the ftpadmin domain. The ftpadmin domain has no permissions to the
web administration, server, or proxy domains. Even though a process
(or user) may be root within the ftpadmin domain, they cannot
circumvent the TE restrictions.
It's a cautious approach by which we don't trust anything. We work
hard to build secure servers and proxies. Then, we stick them in a
tightly constrained box so that if there is a vulnerability, it can't
be used to get through the firewall or compromise the information
provided by servers.
>
> mjr.
> (* kind of like theoretical computer scientists, only less useful,
> if you can imagine that)
> (** kind of like pet rocks, only less useful)
> (*** very useful individuals)
> (**** the aforementioned pet rocks)
>
With some cement and enough pet rocks, you can build a sturdy wall.
--
Ted Stockwell, stockwel @
sctc .
com, Sidewinder
|
|
