vjs@rhyolite.SGI.COM (Vernon Schryver) (09/13/88)
In article <5416@zodiac.UUCP>, jordan@zooks.ads.com (Jordan Hayes) writes: - Keith Bostic <bostic@BERKELEY.EDU> writes: - Since you can't log in as "bin" (it has no password) this - shouldn't be an issue. - - Yes, but root equivalence is governed by /.rhosts, but "bin" equiv. is - governed by /etc/hosts.equiv ... and we all know that "rsh csh -i" is - as good as "rlogin" for most tasks ... Yes. Why change? Some people, outside BSD, have long thot everything should be owned by 'bin' and not uid=0. This belief seems common in System V land. Someone long gone from SGI brought it to IRIS's. I have had occassion while working in SGI's internal network to exploit variations of this hole--the usual case where someone is absent but their machine is doing terrible things to the net, not receiving mail, or whatever. Having bin own things is a Bad Idea if you want to keep people out. Is there some risk with making root own everything? Vernon Schryver Silicon Graphics vjs@sgi.com
amos@taux02.UUCP (Amos Shapir) (09/13/88)
The bugs that men do live on after them... When I did the first BSD4.2 for the tahoe at CCI (back in 1984), I did everything as bin, since most of the work was cross-compiling on a VAX, and I didn't want to have its /bin overwritten by mistake. The Berkeley guys seem to have picked up the habit. (NFS did not exist yet then). -- Amos Shapir amos@nsc.com National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 TWX: 33691, fax: +972-52-558322 34 48 E / 32 10 N (My other cpu is a NS32532)
gwyn@smoke.ARPA (Doug Gwyn ) (09/13/88)
In article <21791@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes: >Is there some risk with making root own everything? 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".
henry@utzoo.uucp (Henry Spencer) (09/14/88)
In article <21791@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes: >Some people, outside BSD, have long thot everything should be owned by >'bin' and not uid=0. This belief seems common in System V land. Not to mention other places and people. Ken Thompson and Dennis Ritchie, for example. Why do you think the "bin" uid **EXISTS**??? Its purpose is to own most of the system files. For one thing, this makes it possible to do most system work without the dangers involved in working as root. The problem is not with bin ownership; the problem is with ridiculously insecure networking schemes which are crudely patched to protect root (but nobody else) from some of their defects. Fix the problem, not the symptoms! -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
vjs@rhyolite.SGI.COM (Vernon Schryver) (09/14/88)
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? It occurs to me that I'm slow on the uptake--Is this a joke? (intending no offense if it's not.) Is there some <<risk>> with root owning things? Other than the hassle of having to su when you install something? again: I have used bin-ownership in obvious ways to become root when the root password was not handy. No doubt most of us could at need. (I was doing nothing illegal or even wrong, of course.) Vernon Schryver vjs@sgi.com
haynes@ucscc.UCSC.EDU (99700000) (09/14/88)
In article <8481@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <21791@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes: >>Is there some risk with making root own everything? > >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". Well as I said when I started the whole thing (and I'm enjoying the activity level of the subsequent discussion) it is really a philosophical question rather than a right-or-wrong matter. I prefer to have root own everything so I only have to defend one UID against the world instead of several. But I can readily appreciate that other system administrators might prefer to be able to work on the commands without needing root privileges to do it. Maybe the goal to shoot for is having the owner of everything be a define in the top level Makefile so the installer can do it either way without having to find and edit all those individual Makefiles. Now a second related issue is why have all those binaries mode 755 or worse instead of 711, with 755 to be used only where needed? Somebody suggested the umask should be taken into account for installs; but I'm not sure that is a good idea because you still need 755 for shell scripts and a few binaries. But making everything 755 allows a user to make himself a complete binary-only copy of the system without getting a license. Not that I particularly worry about that; I'm more concerned with trying to make it as hard as possible for the crackers to find out what's wrong with the programs before I do. haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes
gwyn@smoke.ARPA (Doug Gwyn ) (09/14/88)
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 <<risk>> 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.
chris@mimsy.UUCP (Chris Torek) (09/14/88)
>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". In article <21879@sgi.SGI.COM> vjs@rhyolite.SGI.COM (Vernon Schryver) writes: >Should anyone besides root be allowed to 'update' sh or crontab? Probably not; bin and root are (effectively) the same user. (That NFS does not make this so is not directly relevant, as 4.3BSD and 4.3BSD-Tahoe do not come with NFS---not from Berkeley, at any rate. That the .rhosts mechanism does, is.) >Is there some <<risk>> with root owning things? Yes. It is relatively small, but it is there. The problem is that a typographic error as root can have much more far-reaching consequences than one as bin. (Besides, I think it is more aesthetic :-) ) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
david@ms.uky.edu (David Herron -- One of the vertebrae) (09/15/88)
My reason for wanting binaries owned by bin (except when necessary)
(besides the convenience reasons mentioned above of not having to live
as root) is so that I can do something like 'quota bin' and find out
how much disk space is taken up by system programs. Or I could split
them over a couple of different user-id's, one for each type. Like
'local-bin', 'usg-bin', and 'ucb-bin'.
That's just one reason, the underlying reason is esthetics. If you
define 'bin' to be the owner of the binaries they 'he' should own the
binaries. Defining 'bin' this way gives more flexibility (after all,
flexibility is one of the traditions of Unix) than defining 'root'
as the owner of everything but user stuff.
--
<---- David Herron -- One of the MMDF guys <david@ms.uky.edu>
<---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<---- What does the phrase "Don't work too hard"
<---- have to do with the decline of the american 'work ethic'?jordan@zooks.ads.com (Jordan Hayes) (09/15/88)
Jim Haynes <haynes@ucscc.UCSC.EDU> writes:
But making everything 755 allows a user to make himself a
complete binary-only copy of the system without getting a
license.
Also, strings(1)ing a binary is a good way to tell if a certain bug
is still around or not. Making binaries unreadable might also have
stopped a lot of the nonsense with ptrace ...
/jordandrew@geac.UUCP (Drew Sullivan) (09/15/88)
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? Yes, the system owner. I for one run a different copy of sh then the stock one. Sh is owned by local (its my box, I can changed sh if I want to). In this way I can tell 6 months down the road what are local updated versions of files vs the stock (bin) distibuted files. Xenix has this habbit of new releases that aren't quit there yet. Getty is another program I had to replace because I wanted different getty programs than the normal /etc/getty. So I wrote a getty dispatcher that would invoke uugetty or the normal getty based on its arguements. Lastly with Xenix's 10 consoles, I can have myself loggin on 5 times, uucp admin, lp admin, and local admin (owner of /etc/passwd, /u (users)). I have found that the need to go super user is slowing disappearing. -- -- Drew Sullivan <drew@lethe.uucp> +1 416 225-1592 Toronto, Ontario, Canada
henry@utzoo.uucp (Henry Spencer) (09/16/88)
In article <4828@saturn.ucsc.edu> haynes@ucscc.UCSC.EDU (Jim Haynes) writes: >Now a second related issue is why have all those binaries mode 755 or >worse instead of 711, with 755 to be used only where needed? ... Well, for one thing, it's awfully hard to run a debugger on a misbehaving program when you can't read the binary. 711 can be done, but the headaches outweigh the advantages for sites that aren't desperately concerned about security. (And surely you don't think that trying to keep the crackers ignorant is going to help much -- they probably know more than you do about your system's weaknesses.) -- NASA is into artificial | Henry Spencer at U of Toronto Zoology stupidity. - Jerry Pournelle | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dls@mace.cc.purdue.edu (David L Stevens) (09/17/88)
[2 articles for one low price!] First: Drew Sullivan <drew@lethe.uucp> writes: [talks about how someone other than root needs to own files...] >..I can tell 6 months down the road what are local updated versions of >files vs the stock (bin) distibuted files. That's what timestamps are for! If you want to know what's changed in your home directory since some particular time, do you change all of the ownerships? > I have found that the need to go super user is slowing disappearing. Doesn't that pretty much mean you're essentially root all the time? Second: Also, Re: Chris Torek's remarks. I think you may have missed my point, Chris. It doesn't matter if you set "bin" to uid 0 or if you call it "root" or "bob", for that matter. The kernel uses the uid number so either the files will be distributed owned as root, or they won't. Password file tricks won't save that. I see where your method is convenient in that you can have all the Makefiles have "bin" and then you can set "bin" to be root or not, as you see it, but that's really sidestepping the issue. If you don't have sources, which is generally true in the "real" world, it doesn't help at all, and even if you do, you are required to either re-install everything or run chown's, if you don't like the default uid *number* for system file ownership. What, then, have you gained? New installs will be the owner you've chosen, magically, yes, but that isn't the major issue, unless you typically change everything. Our local version of install(1) replicates the existing files modes and ownership by default, so your solution, at least for us, does absolutely nothing. Picking consistent uid (numbers!) for file ownership is what I'd like to see; that may not be the issue you're addressing [I'm sure you'll tell me if you've "already covered that" :-)], but that is what is relevant to the majority of system administrators. We have discussed this locally and have chosen root ownership and to remove the root->nobody mapping across NFS links. We have been using "binary", a "bin" equivalent, but at best, it gives us nothing and at worst, it gives us a false sense of security. Of course, if we see some new information that makes an id other than root attractive, we'll change that. Unless I've missed something, your suggestion still leaves installers with having to do chown's, except for new installations, and a clever install(1) fixes that a little more cleanly then password file dancing. -- +-DLS (dls@mace.cc.purdue.edu)
gwyn@smoke.ARPA (Doug Gwyn ) (09/18/88)
In article <647@mace.cc.purdue.edu> dls@mace.cc.purdue.edu.UUCP (David L Stevens) writes: > Of course, if we see some new information that makes an id other >than root attractive, we'll change that. UID 0 is a very special UID on UNIX systems and should not be used lightly.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (09/20/88)
In article <3224@geac.UUCP> drew@lethe.UUCP (Drew Sullivan) writes: >Yes, the system owner. I for one run a different copy of sh then the stock >one. Sh is owned by local (its my box, I can changed sh if I want to). In >this way I can tell 6 months down the road what are local updated versions of >files vs the stock (bin) distibuted files. A technique I have used to quickly identify which binaries have been locally replaced is to rename the old one to something recognizable, replace it with a new one, and link the new one to a long name I can identify. E.g.: move /bin/mail to /bin/mail.original install new /bin/mail, link it so /bin/mail.from.Usenet.15.jan.1988 (Under System V you are unfortunately limited to 14-char names.) When there is any doubt, just do "ls -li" and identify what is linked to what by glancing at file sizes and finally comparing inode numbers. The above allows you to have several local updates, and not get confused as you might if the only identifying feature was the name of the owner. (Ideally all binaries would have descriptive SCCS strings embedded.) -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi