Complex security mechanism is unsecure (was Re: non-superuser chown(2)s considered harmful)

[henry strickland]

In article <4627 at pkmab.se> ske at pkmab.se (Kristoffer Eriksson) writes:
>In article <6874 at titcce.cc.titech.ac.jp> mohta at necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>>In general, making some application set-uid to root is more secure
>>than making it set-uid to, say, uucp.
>>
>>In the latter case, you must be careful that no unauthorized person can
>>have uucp nor root priviledge.
>
>But that is fairly easy to prevent for a non-user account. Just make it
>impossible to login to that account.

Nope.  In a great many NFS networks today it's not too hard to find one
workstation on which you can make yourself root.

In the normal NFS setup, making myself root on a workstation does not
give me root priveleges on the filesystem of a remote NFS server which
I can mount the partitions of.   But I can easily be any other user or
any group I want on that remote partition, including daemon, bin, uucp,
kmem, wheel, operator, audit, etc.    Since this is so easy, we have to
set our goals to being root on the server.  ;-)   Now if any of these
non-root users owns (or groups has w bits on) some file in the PATH of
root (or one of the directories or superdirectories in the PATH), the
trojan horse can ride.

So I appreciate the suggestion about it being better to set up your
priveleged binaries to run setuid root, if it's at all conceivable that
root might some day want to run them (lpr, uucp, tip, xterm, rogue).

That doesn't negate the advice to do the *minimum* necessary as root and
then setuid(non-root).  In the usual case that you *really* wanted to
execute with effective uid xyzzy, the first thing the binary should
do is setuid(xyzzy).   ( right? )

					strick		<strick at osc.com>