[785] in linux-security and linux-alert archive
Re: [linux-security] standard users,groups,perms?
daemon@ATHENA.MIT.EDU (Alexander O. Yuriev)
Tue Jun 11 15:50:15 1996
To: linux-security@tarsier.cv.nrao.edu
Cc: Tom Briggs <tbriggs@cutter.ship.edu>
In-reply-to: Your message of "Tue, 11 Jun 1996 09:49:05 EDT."
<Pine.LNX.3.93.960611091415.22254D-100000@cutter.ship.edu>
Date: Tue, 11 Jun 1996 13:59:04 -0400
From: "Alexander O. Yuriev" <alex@bach.cis.temple.edu>
Your message dated: Tue, 11 Jun 1996 09:49:05 EDT
> The discussion regarding apropriate users, groups, file locations, etc, is
> really quite philosophical in nature. To suggest that the security setup
> for a UNIX system that handles thousands of users in a class C2 secure
> setup (or higher, SCO now supports B grade security) should be the same
> setup as a UNIX system that handles a hacker or two on their own home PC
> is ridiculous.
Last time I checked (May 17th 1996) SCO did not have certification for B
level. SCO claim to provide security level comparable to B ( DEC has the
same claim for new OSF security package)
> First off, for the higher grades of security, (B grade specifically), you
> cannot have a single all-powerful superuser, the superuser needs to have
> restrictions. That is the idea of the Wheel oligarchy introduced in
> System V Release 4. BSD-ish systems have been very sluggish to implement
> the enhanched suite of security SVR4 provides.
This is mostly incorrect statement. The difference between B and C levels of
security is presence of *compartments* on B levels, identification and
detection of the maximum bandwidth of covert channels for B1, their removal
for B2 and above. [Ref: Orange Book ; "UNIX System Security" Matt Bishop]
One of priviledges that superuser does have is a priviledge to set
priviledges which creates a perfect opportunity to compromise TCB and
compartment system. Consider: Root creates a new System Security Officer.
A new System Security Officer modifies compartment access for other system
security officers from "read-write-modify-create-delete" to "no-access",
modifies access for super user from "create-delete" to
"read-write-modify-create-delete". Now super user becomes SSO. SSO has
permission to set access for "sub-system managers".
>
> Under this arrangement, a well administered system has sub-system
> managers, for example, a mail manager, a system manager, a uucp manager,
> and network manager, and database manager, etc, etc, etc. These managers
> have the ability to work in their own file areas (example, the database
> manager has the ability to be "super-database user"), and they often have
> access to a select subset of files using the wheel super-group. (instead
> of su, sg). These subsystems have applications which, in a perfect world,
> may need to be setuid to root, but the applications themselves do what
> they need as root, and then set control back to their own proper
> subsytems.
> Sun's target is high end work stations, and some medium grade servers.
> They generally have one or two users as admins, and the need to split up
> security across many users is minimal (I don't think Solaris even counts
> as a B grade secure systems, does it even count as C2?) So, there will
> probably be one and only one user as admin, and then its apropriate to
> have a super-user "root." Since that admin will often use the "root"
> account, its also proper *not* to have that account in "/", since on a
> Sun, "/" is normally quite a small parition ( 3 different Sun reps
> suggested <20MB). Thats pitiful. Anyway, its rather quite aproprite to
> have /root somewhere where there is disk space.
None of the systems that has BSD-type /etc/passwd or BSD type 'r'-type
servers can be considered even C1 secure as one of the fundamential
requirements for C1 is *required* authentication.
Best wishes,
Alex
