Complex security mechanism is unsecure

Masataka Ohta mohta at necom830.cc.titech.ac.jp
Thu Dec 13 17:56:37 AEST 1990


In article <4627 at pkmab.se>
	ske at 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 at rpp386.cactus.org>
	jfh at 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



More information about the Comp.unix.internals mailing list