[772] in linux-security and linux-alert archive
Re: [linux-security] standard users,groups,perms?
daemon@ATHENA.MIT.EDU (Tom Briggs)
Tue Jun 11 11:48:43 1996
Date: Tue, 11 Jun 1996 09:49:05 -0400 (EDT)
From: Tom Briggs <tbriggs@cutter.ship.edu>
To: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <199606072156.RAA23939@cais2.cais.com>
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.
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.
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.
This is a proper arrangement for a system that costs millions of dollars,
has 5+ administrators, and is mission critical to a multi-million dollar
enterprise, and would probably not be running on PC class machines.
Linux' security, while good, is not fool proof, and the argument about
where root's home directory is, is trivial in comparision to some of the
other large scale holes in the system. Having used some large System V
machines, and some suns, and DECs, and MIPS, and some AIX machines, I must
say, Sun's decision to lump everything into "/" is probably one of the
stupidest decisions I've ever heard of.
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.
The comment about having /root on the root partition is also wrong. My
theory on this is as follows: if the system absolutely needs a binary to
startup, then it should be in /sbin, or /etc, or wherever the other
required binaries are, not /root. How easy is it for a human being ( yes,
human beings are system administrators, and thus, make mistakes), to
remove a file without *really* thinking about what that file is. I don't
think I've ever really purged anything in /sbin before, I know I've
housecleaned /root, and I've deleted things I wish I hadn't, but nothing
that affects system stability.
----------------------------
Tom Briggs,
Library Automated Systems Manager, Ezra Lehman Memorial Library,
Shippensburg University
