Xref: utzoo comp.unix.programmer:1308 alt.sources.d:1610
Path: utzoo!utgpu!cs.utexas.edu!bcm!convex!usenet
From: tchrist@convex.COM (Tom Christiansen)
Newsgroups: comp.unix.programmer,alt.sources.d
Subject: Re: C2 secure systems and the superuser
Message-ID: <1991Mar13.185609.21132@convex.com>
Date: 13 Mar 91 18:56:09 GMT
References: <19101@rpp386.cactus.org> <1991Mar13.042033.12450@convex.com> <19103@rpp386.cactus.org>
Sender: usenet@convex.com (news access account)
Reply-To: tchrist@convex.COM (Tom Christiansen)
Organization: CONVEX Software Development, Richardson, TX
Lines: 44
Nntp-Posting-Host: pixel.convex.com

From the keyboard of jfh@rpp386.cactus.org (John F Haugh II):
:In article <1991Mar13.042033.12450@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
:>I maintain that both "auth" and "sysadmin" give you indirect
:>root privileges.  With auth, you can create accounts or modify
:>existing ones.  With sysadmin, you can mount arbitrary things
:>at arbitrary points, do dumps and restores etc.  
:
:Consider, just as an example, that I could implement the
:"mount" system call in such a way that any privileged commands
:on that volume wouldn't be treated as privileged until a
:privileged system utility had verified that the volume was
:in an acceptable state.  So "sysadmin" lets you mount some
:disk - big deal.  Perhaps "sysadmin" also lets you crash
:the machine by unmounting critical volumes or over-mounting
:others.  A quick look at the audit logs will reveal what
:happened.

Audit logs can be altered once you are powerful enough.  And
it's important to stop it from happening in the first place.

:SecureWare, not being a formally evaluated product, probably
:has =many= little holes, and if this is one of them, point
:out how I can become "auth" with just access to "sysadmin"
:and then we can sit back and have a good laugh at SecureWare.

I'm not here to have a good laugh at anybody, including SecureWare.  I
just want to point out that the C2 security stuff I've seen applied to
UNIX has some fundamental problems in its approach.  Breaking up the
superuser into small compartments that each do a few very powerful things
isn't enough if you're not very very very very careful.  I haven't yet
seen any that are that careful.

Let's take a "sysadmin" user, who has the privs to do dumps, restores, and
mounts.  Each of these is quite powerful.  The dumps allow me to see any
data on the system.   The restores allow me to create or overwrite any
file on the system, including the whole TCB and authorization database.
Being able to run mount allows me to patch in my own version of /etc or
whatever I want.

If you work very very hard to patch up problems like this, you might be
able to convince me that "syadmin" is not as powerful as the old
superuser, but so far I haven't seen an implementation that did so.

--tom