Getting rid of the root account

Thomas Truscott trt at rti.UUCP
Sun Jun 11 08:14:36 AEST 1989


There are number of ways to strengthen UNIX security
such as by auditing for unusual process activities,
adding the DOD-oriented MLS policies, and ACLs (I suppose),
I do not see how handing out a "piece of the root" enhances security.
It might possibly reduce the damage caused by a typical errant process
but a *malicious* process (user) will just take the privilege(s)
and turn them into full-blown superuser privilege.
Nothing is gained except complexity and a false illusion of security.

For example:

> Consider for a moment a `mount' program which only group `oper'
> may execute. ...
> And you must prove that EVERY operation performed by `mount'
> conforms to the security system you've implemented.

It was claimed that giving the `mount' program only the MOUNT
privilege improves security, since only the mount(2) system
call need be checked for security.
(In ordinary UNIX `mount' would have to be set-user-id root,
and everything it does would have to be checked for security.)

1) What kind of security are we trying to achieve?
Either variant of `mount' permits group `oper'
to mount a new /etc, complete with an oper-friendly /etc/passwd.

2) Everything in `mount' needs to be checked anyway
lest it be fooled into abusing its MOUNT privilege
(e.g. does `mount' call gets() :-)).

And, although irrelevant, I cannot resist throwing in:

3) In BSD 4.3 and SYS 5.3 the same effect can be achieved
by having `mount' do a set[re]uid(2) to a nobody uid
and be superuser only during the mount(2) system call,
and perhaps also when updating /etc/mtab (if you have one of those).
(Does MOUNT privilege give write permission on /etc/mtab?)

	Tom Truscott



More information about the Comp.unix.wizards mailing list