Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mailrus!uflorida!haven!umd5!adm!smoke!gwyn From: gwyn@smoke.ARPA (Doug Gwyn ) Newsgroups: comp.bugs.4bsd Subject: Re: bin owns stuff (was: Installing 4.3-Tahoe on a VAX) Message-ID: <8491@smoke.ARPA> Date: 14 Sep 88 09:30:26 GMT References: <26049@ucbvax.BERKELEY.EDU> <5416@zodiac.UUCP> <21791@sgi.SGI.COM> <8481@smoke.ARPA> <21879@sgi.SGI.COM> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 24 In article <21879@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes: >In article <8481@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: >> The basic idea is to avoid forcing the system administrator to act under >> UID 0 unless absolutely necessary. Files owned by "bin" can be updated >> by "bin" rather than "root". >Should anyone besides root be allowed to 'update' sh or crontab? Sure. I own the BRL Bourne shell on our systems, and crontab is often writable to system administrators. >Is there some <> with root owning things? If you read carefully you will see that that's not what I said. The risk lies in ACTING UNDER UID 0. All sorts of security problems can be opened up inadvertently and in many cases may remain undetected, since all permission checks are disabled for UID 0. A well set-up UNIX system should reserve UID 0 for set- UID programs, and only a few, carefully verified ones at that. If you find yourself "going su" to do routine things, you should give some thought to other ways of doing what is necessary. For example, BRL has long had a "priv" utility that runs set-UID 0 and gives appropriate privileges to specific executables when run by specific IDs. The idea is to limit the scope of UID 0 power in order to minimize damage.