Jeromie Jackson writes:
>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.
I haven't seen any papers on type enforcement outside of
the arcana of computer security -- some of the folks from TIS who
are working with DTE have presented a number of papers on their DTE
implementation at the NSA Baltimore conference.
I'm going to make a few meta-observations about DTE that
will probably require correction/adjustment from the SCTC folks.
This is not intended as disparagment, and it's not an attack on
their product -- but I'd like people to consider the relationship
between theoretical constructs, implementations, and assurance,
as they relate to DTE.
DTE is a means of encoding permissions information and
evaluating it when someone tries to perform an operation on
an object that falls under the scope the permissions system.
I chose those words very carefully, because my understanding
of DTE is that it is an *APPROACH* not an implementation. My
somewhat simplified understanding of DTE is that you represent
the state of all possible permissions by encoding them in the
intersecting cells of a matrix, with the verticals and the
horizontals of the matrix listing the things that there are
to protect, and the uid/gids that may try to operate on them.
The argument is that it's very easy, once you have built this
domain/type and permissions matrix, to check it quickly for
permissions. This, to me, does not smack of Rocket Science.
My impression of DTE is that the "theoretical computer
security scientists"* love it because it's easier to do all
that formal proof and theorizing stuff that they do in orange-book
land, if you're using DTE. But all that theorizing has
nothing to do with whether it actually makes life any better
for security in the field. I can see that it's a simplified
representation, and that it's fast to check -- but -- barring
implementation details (which we will discuss next) it's not a
whole lot cooler than VMS' extended ACLs, or even UNIX file
permissions. For practical purposes, you can do anything you
are likely to ever need to do using VMS ACLs and can do just
about anything with UNIX' mode bits, uid, and gid.
DTE, however, has one major advantage over other means
of representing permissions: it's patented.
The big question with any attractive theoretical concept
is how it actually is implemented. I once had an amusing experience
with a "theoretical computer scientist**" who had derived some
mechanism for searching a database that had some theoretically
marginal edge over b+trees -- it turned out, of course, that a
finely tuned b+tree library (I have one) mopped the floor with
his version -- because he insisted on writing BASIC in C. :)
But I digress... For a permission system the interesting things
are:
a) is it coded right?
b) how easy is it to use?
c) WHAT does it exert control OVER?
To me, the innovative part of what the Sidewinder guys
are doing is that apparently they have made their permission
system exert control over more parts of the system than basic
UNIX permissions do. Basic UNIX permissions, you recall, don't
do much more than ownership of a process, or rwx of a directory
for uid/group. I gather that Sidewinder's *implementation* of
the DTE model allows control over parts of the system you would
normally not have under permission control with UNIX. That is
cool. How cool is it? I don't know. My experience is that Real
Unix Gurus*** can do the aforementioned "just about anything
you want to accomplish" with UNIX the way it is. Or with a
simple application-specific kernel hack. :)
DTE, as a kernel-based technology, can control all the
stuff that an application does via-a-vis the kernel, for the
points of the kernel that have DTE controls applied to them.
One important thing that means is that if the applications
on top don't do the right thing, or are misdesigned, then the
DTE doesn't help. I believe that SCTC has a lot of experience
in designing applications to do the right thing, and to design
them right in a security environment, and frankly, I'm inclined
to suspect they've gotten it right. But just adding DTE to the
kernel is not a magic silver bullet that solves all your problems.
I'm sure it helps, though.
What I think happens with Sidewinder is that a lot of
their technologies {DTE, assured pipes, "hardened kernel",
"A1-like technologies", etc.} are glommed together and many
folks get confused into thinking they're all part of the
same thing. I don't believe they are to any significant degree.
They've added an implementation of DTE based on work they
have done on A1 systems**** into a "hardened" version of BSDI.
"Hardened" means - who knows what. The traditional claim of
all vendors is "we fixed all the bugs" which in the case of
BSDI means next to no change was made. But a lot of vigorous
hand-and-patent-waving makes it sound like a lot of hefty
orange-book mumbo jumbo was done. None of this is to say I
think it's a bad product -- if you want to draw any conclusion
from the preceeding remark conclude that I am very cynical
about orange-book mumbo jumbo.
And then there's the implementation. "How easy it is
to use" and "how well it's written" are important. I'm willing
to assume it wasn't hard to get that stuff right and that SCTC
knows what they're doing. Of course, I *ALSO* believe that
working with normal UNIX permissions is not hard to get right
if you know what you're doing, and that the normal implementation
of UNIX permissions in the kernel is pretty solid by now.
I had one amusing experience with a cool security
permissions system someone had added to their kernel, which
was a whole lot cooler than normal UNIX security. The idea
was you could even be "root" on the box and still you could
not hurt the system. Very Cool. But I discovered that they
forgot to add the permissions check in the VFS layer for
the unlink() system call via NFS so you could be root and
still zap files by NFS mounting them to yourself. Oops.
The point is that getting it right is important. Someone
saying they've done something theoretically nifty with a
cool sounding name doesn't impress me any more than our
national leaders' attempts to balance the budget.
>1)
>type enforcement provides multiple domains that allow for seperation of duty.
Kinda like you can do with setuid, chroot, or VMS ACLs
if you know what you're doing.
>2)
>type enforcement allows for the removal of system calls from any given
> domain.
I don't recall if VMS extended ACLs do this, but this is
also a yawner. If you want to restrict who can do chmod(), it's
a one-line kernel patch to vfs_syscalls.c, at line 1462. Sure, a
more generic approach would be nice but this is for a firewall,
which is an embedded system. One-line kernel hacks are fine for
embedded systems.
>3)
>type enforcement requires a configuration of who can touch what. This can
> be useful for triggering alarms & potentially strong audit data.
Most audit trail systems provide this. If they don't, a
watchdog process that scans the audit trail does.
What people forget is that the O/S for an embedded system
like a firewall is just this big program that's pretty easy to
tweak as you see fit. Want guaranteed assurance that only processes
you trust will ever spawn subshells? Piece of cake. Just add some
code to kern/kern_exec.c at around line 96 so that only uid #0 can
use the exec system call, and make sure that all processes that are
not trusted run as non-0 uids. See how easy it is? You won't get
a patent on it; it's not that cool.
None of this is intended to criticize SCTC's product;
I really haven't had enough chance to look at one (and have
passed up the challenge) -- my point is that the DTE stuff is
cute in theory, but that the *interesting* parts of what DTE
can let you do are mere implementation details; how they are
implemented is not really very interesting and it's not too
hard to get that kind of thing right. Therefore DTE doesn't
excite me a huge amount.
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)
Follow-Ups:
-
A1 Systems?
From: Leonard Miyata <leonard @
geminisecure .
com>
|
|
