friedl@vsi.UUCP (Stephen J. Friedl) (03/14/88)
In article <5209@uwmcsd1.UUCP>, jgd@csd1.milw.wisc.edu (John G Dobnick,EMS E380,5727,) writes: > After nosing around in source directories, and after looking at various > installation scripts, I was struck by a curiosity. After thinking about > the file security features of UNIX, and their total lack of applicability > to "root", I was even more struck by this same curiosity. > > Why does "root" seem to "own" everything? Why is almost *all* installed > software (at least that which is supplied *with* the stock system) installed > by "root"? [I think these are really two statements of the same question.] A file simply being owned by root is not a security hole, and some might call it a security feature. Note that this is just my preference and other wizards may not share it -- flames are welcome. It is indeed easy to screw up as root but just as easy with "library" or "bin" because it is not as "important" as root so your guard might be down a bit -- boy am I generalizing here :-). Let's say that I can somehow break the "bin" login. I just replace (say) /bin/ls with my own program. This program will do an exec on the "real" ls but if it is being run by root it will do something special for me. Basically, files not owned by root are prime targets for security breaches. It turns out that on my machine has this bug: I can break the "bin" group and the /bin directory is, by default: 4 drwxrwxr-x 4 bin bin 1680 Mar 6 04:49 /bin I can write to /bin and have successfully gotten somebody to run my phony ls as root. I can think of some convincing arguments on your side as well, primarily related directly to your point of letting non-root do system administration on a machine. I'll let the other wizards respond to that point. > Subsidiary questions. Is this organization historical? Is it just laziness > on the part of the [original/intermediate/recent] developers/distributors > of UNIX? Is this situation going to be addressed? Is the situation different > between the System V and Berkeley species of UNIX? (We use the bsd variant, > if that is really relevant to this issue.) Root is the only uid whose number<-->name match is guaranteed on all machines. Tar and cpio and most other archiving programs store the owner of a file as a number, not a name, and there is the chance that the name upon read doesn't match the name upon write. This means that a file written with uid=1 (bin) might be read as uid=1 (adm) and this is not necessarily what is wanted. You ask a good question, and these are just my thoughts. Steve -- Life : Stephen J. Friedl @ V-Systems, Inc./Santa Ana, CA *Hi Mom* CSNet: friedl%vsi.uucp@kent.edu ARPA: friedl%vsi.uucp@uunet.uu.net uucp : {kentvax, uunet, attmail, ihnp4!amdcad!uport}!vsi!friedl
jgd@csd1.milw.wisc.edu (John G Dobnick,EMS E380,5727,) (03/15/88)
Let's try this One More Time!
> The subject line should, of course, read 'Why does "root" own everything?'
[If it's not right *this* time, I don't want to know.]
--
John G Dobnick
Computing Services Division @ University of Wisconsin - Milwaukee
UUCP: {ihnp4|uwvax}!uwmcsd1!jgd
INTERNET: jgd@csd4.milw.wisc.edu
"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight." -- William Safirechris@mimsy.UUCP (Chris Torek) (03/15/88)
In article <3755@bloom-beacon.MIT.EDU> wesommer@athena.mit.edu (William E. Sommerfeld) writes: >If you're using the 4.x-oid `dump' and `restore', it's simple. Dump >reads the raw disk, so all you have to do is to create a `backup' >pseudo-user and give it group read (but not write) access the raw >devices you want to have backed up. An easier way: % ls -lgd /etc /etc/{,r}dump /etc/dumpdates /dev/rra1d drwxr-xr-x 12 bin bin 5120 Mar 15 05:45 /etc -rwxr-s--- 1 bin operator 36864 Nov 18 15:34 /etc/dump -rwsr-s--- 1 root operator 51200 Nov 18 15:34 /etc/rdump -rw-rw-r-- 1 bin operator 5544 Mar 15 08:56 /etc/dumpdates crw-r----- 1 root operator 9, 11 Mar 13 19:56 /dev/rra1d % This depends on the fact that new versions of /etc/dump open /etc/dumpdates in mode `r+' and use ftruncate() to shorten the file when necessary (hence dump and rdump no longer need write permission on /etc). (rdump must still run setuid-root so as to get a restricted port.) Incidentally, in 4.3-tahoe (and around here, ever since we installed 4.2BSD) root does not own everything. Now `bin' owns everything that need not be special. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
terry@wsccs.UUCP (terry) (03/22/88)
In article <7448@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > Yes, UNIX System V typically has its system software owned by "bin", an > account with no privileges other than being able to reinstall system > software. Except for access to /dev/kmem, thereby providing the capability to eavesdrop on the input buffer for the console, at least on PC-based systems where the tty driver for the console writes directly to screen memory! terry@wsccs