Path: utzoo!utgpu!news-server.csri.toronto.edu!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 Message-ID: <18826@rpp386.cactus.org> Date: 16 Dec 90 16:10:59 GMT References: <4627@pkmab.se> <18808@rpp386.cactus.org> <6886@titcce.cc.titech.ac.jp> <4645@pkmab.se> Reply-To: jfh@rpp386.cactus.org (John F Haugh II) Organization: Lone Star Cafe and BBS Service Lines: 52 X-Clever-Slogan: Recycle or Die. In article <4645@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes: >In article <6886@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >>A careless administrator may even think that it is safe to give some >>half-trusted user "uucp" privilege. > >Make the administrator do all work in assembler, and maybe he won't dare >do anything at all, and we will get a very "secure" system... Ohta-san makes a valid complaint, except that any administrator worth their salt knows that giving "bin" or "uucp" (or any other administrative user ID) access to an untrustable user =is= equivalent to giving away root access. This isn't news. Basically, the *-closure of the files executed by root, or which control the function of a subject with root privilege must be protected. That means that every program directly executed by root, and the programs that those programs execute, and the files that those programs use, and the tools that generate the files that those programs use, and so on, must be kept under root control or there is a chance that root may be violated. That's a pretty big collection of files, but making the owner "root" does not make the collection smaller. >No, I think this argument is of no significance. To prevent carelessnes, you >want to remove a useful security feature? My judgement is that root would >become more vulnerable to simple mistakes, rather than less. In reality root is subject to more severe errors since any error gives is likely to give direct access to the root account. With layered security, a flaw in one program may stop there. For example, a hole in a set-GID mail program may make it so that you can read someone elses mail, while a hole in a set-UID root program may make it so that you can read any file on the entire system. This is all grossly overgeneralized and oversimplified, but you should begin to see the difference, and why least privilege is simply more secure. The only privilege you have ("uucp" access) is that exact privilege you need. >>"uucp" has large capability over files owned by "uucp" and referenced by >>"root". That is the reality. > >When does root need to reference uucp files? Quite often. Don't dismiss the arguments he makes. It's just that this is not new news. Giving away a "uucp" login is certainly giving away access to everyone elses accounts, and probably the same as giving away access to "root" as well. If you don't know this, you have a serious problem already. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "While you are here, your wives and girlfriends are dating handsome American movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."