Path: utzoo!attcan!uunet!cs.utexas.edu!execu!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: Complex security mechanism is unsecure
Summary: least privilege revisted.
Message-ID: <18808@rpp386.cactus.org>
Date: 12 Dec 90 13:46:05 GMT
References: <1990Dec6.005358.6336@dg-rtp.dg.com> <109958@convex.convex.com> <6874@titcce.cc.titech.ac.jp>
Organization: River Parishes Programming, Austin TX
Lines: 47

In article <6874@titcce.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
> In the latter case, you must be careful that no unauthorized person can
> have uucp nor root priviledge. If you have an executable owned by uucp
> in root's command serach path (like /usr/bin/tip), those who have uucp
> priviledge can easily set a trojan horse trap.
 
sure, and any program owned by "bin" which is in root's command search
path is also likely to be a trojan horse.  most of the programs in /bin
have that property.  this is why "bin" shouldn't have a password unless
you are willing to have the owners of "bin"'s password become "root"
someday.  and the same applies, of course, to "uucp" and "sys" and so on.

> >Unfortunately, if you have an application that
> >wants to change the ownership to the user, such as cu, you must now
> >make cu set-UID to "root".
> 
> But it is more secure.
 
not true - read on.

> So, don't make the security mechanism complex. The simpler, the more secure.

this part is true - the number of things which you must protect against
with "root" being the effective user ID is far greater than the number
of failure modes with a program set-UID to "uucp".  "uucp" has no
extra privileges, whereas "root" has all of them.

consider for just a moment the entire catagory of failures along the
lines of "illegal file access".  "root" does not require access permission
to change a file, but "uucp" does.  there still remains many other system
calls which have special behavior with euid == 0.  none of those apply
to euid == "uucp".  finally, as if we were adding insult to injury, the
common implementation of setuid() on System V does not include the ability
to toggle between euid == 0 and euid == ruid - the first visit from 0 to
ruid is permanent, which means that you either run as euid == 0 all day
long, or fork off other processes to change their id's and exit.  yet, if
euid != 0 and ruid != 0, you are free to alternate between euid and ruid
repeatedly (actually, between ruid and the saved set user ID).

so, the short form answer is that in general set-UID to root is far less
secure that set-UID to non-root, and this is borne out in various security
related documents and criteria.  you should =always= execute with the
least amount of privilege required to perform the task at hand.  set-UID
to root is a direct violation of this concept of least privilege.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org