Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!ccut!titcca!cc.titech.ac.jp!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.internals
Subject: Re: Complex security mechanism is unsecure
Message-ID: <6886@titcce.cc.titech.ac.jp>
Date: 13 Dec 90 06:56:37 GMT
References: <1990Dec6.005358.6336@dg-rtp.dg.com> <109958@convex.convex.com> <6874@titcce.cc.titech.ac.jp> <4627@pkmab.se> <18808@rpp386.cactus.org>
Sender: news@cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 63

In article <4627@pkmab.se>
	ske@pkmab.se (Kristoffer Eriksson) writes:

>>In general, making some application set-uid to root is more secure
>>than making it set-uid to, say, uucp.

>(If, in stead, you break into that account by using some bug in some
>set-uid program owned by that account, then it wouldn't exactly be more
>secure to have that program owned by root, so that is no way to avoid my
>argument.)

The complexity of the security mechanism is different.

>But that is fairly easy to prevent for a non-user account. Just make it
>impossible to login to that account.

Yes, it is fairly easy if you know what to do.

But, with a complex security mechanism, it is difficult for an average
system administrator to know what to do.

A careless administrator may even think that it is safe to give some
half-trusted user "uucp" privilege.

In article <18808@rpp386.cactus.org>
	jfh@rpp386.cactus.org (John F Haugh II) writes:

>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.

The proper solution is to remove "bin", which is done on BSD UNIX.

I am really astonished to know "bin" is still there on SystemV.

>> 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".

I don't think it is "far greater".

Many known (now closed) security holes to gain root privilege could
not have been closed by running related daemons with "uucp" nor by changing
the owner of related setuid programs to "uucp".

>"uucp" has no extra privileges, whereas "root" has all of them.

"uucp" has large capability over files owned by "uucp" and referenced by
"root". That is the reality.

>you should =always= execute with the
>least amount of privilege required to perform the task at hand.

"=always="? No, "unless the security mechanism become complex" is
the condition.

But, the relationships of management related files are already very
complex. So, don't bring extra complexity such as a non-root setuid
program.

						Masataka Ohta