Getting rid of the root account

[Al Donaldson]

In article <16662 at rpp386.Dallas.TX.US>, jfh at rpp386.Dallas.TX.US (John F. Haugh II) writes:
> Least privilege is a _requirement_ for trusted computing systems. 
> [then some quotes from the TCSEC].

Well, I don't classify myself as a Unix "wizard" (a root password does not
a wizard make), but I do know a bit about the Orangebook, and there are 
some oversights here that need to be corrected.  I held off a day since 
originally reading this article, waiting for others to make this point, 
but since they haven't, here goes.

First, the Orangebook (TCSEC or DoD 5200.28-STD) categorizes systems 
into a hierarchy of divisions (D, C, B, A) and classes (e.g., C1, C2) 
that can be used to identify levels of functionality and assurance in 
a vendor's product.  Whether a product meets these requirements is 
determined through an evaluation by the National Computer Security Center 
(NCSC).  Part of this process is a decision by the computer vendor 
(generally based on market or contract requirements) as to which level 
(C2, B1, B3, A1??) the vendor wants to shoot for.

Since John's quotations were from Section 3.2 of the Orangebook, I assume 
he has market or contractual requirements for building a B2 system.  
Within this framework, John is pretty much on target.

However, B2 goes quite a bit beyond what the bulk of the unwashed masses 
(myself included) use on a day to day basis.  As I remember, a recent 
Air Force acquisition for a large number of trusted Unix systems only 
anticipated that about ten percent of the systems would be B1, the rest
would be C2.  Its important to understand here that B-level systems are 
evaluated to label data with security labels (e.g., Unclassified, etc) 
and enforce security policy on accesses to that data, something that most 
of us in the commercial sector don't want to bother with.

In my estimation, what is far more important is bringing up the bulk
of Unix systems to the C2 level of assurance, by 

(1) providing an auditing capability that can be turned on or off,
(2) providing a usable means (other than having a zillion groups)
    of allowing the user to control access to his or her files, and
(3) having some way to identify WHO is logged on with the super-user 
    privilege.  This is specially needed on larger systems where more
    than one person may have the root password.

Breaking up superuser privilege into various sub-privileges might be nice 
for some sites, maybe, but it certainly is NOT required for C1-B1 level 
systems and it would be a royal pain on a smaller system such as mine.

Al Donaldson 
al at escom.com
(703) 620-4823

Man   - "What's he got that I haven't got?"
Woman - "Awareness."
Man   - "What's that?"