jgd@csd1.milw.wisc.edu (John G Dobnick,EMS E380,5727,) (03/13/88)
[Is the line eater an endangered species?]
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.]
Given the security risks of running as root (*NO* protection at all),
I would think that most system maintenance work (like software installation)
would be done under as userid that is "protected". It is *easy* to screw up,
and if you screw up as root ...
I would think that a "library" (or "bin") login would exist for the purpose
of installing and maintaining software. The second timesharing system I
ever used (a DEC TSS-8, on a PDP-8/e), was organized this way. (The first
timesharing system was a Burroughs B5500 running MCP... but I digress [and
show my age].)
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.)
I have limited this to North America only, as the suppliers of UNIX all
seem to be located there. [Unless California has fallen off already. :-) ]
--
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 Safiregwyn@brl-smoke.ARPA (Doug Gwyn ) (03/13/88)
In article <5209@uwmcsd1.UUCP> jgd@csd1.milw.wisc.edu (John G Dobnick,EMS E380,5727,) writes: >I would think that a "library" (or "bin") login would exist for the purpose >of installing and maintaining software. >Is the situation different between the System V and Berkeley species of UNIX? 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.
ugfailau@sunybcs.uucp (Fai Lau) (03/14/88)
In article <5209@uwmcsd1.UUCP> jgd@csd1.milw.wisc.edu (John G Dobnick,EMS E380,5727,) writes: >[Is the line eater an endangered species?] > ......... >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.] > Well, root owns everything because there has to be an user that owns everything. Since root owns everything, why not work with root for the convenience? Also root privilege can be assigned to any other user other then root. >Given the security risks of running as root (*NO* protection at all), >I would think that most system maintenance work (like software installation) >would be done under as userid that is "protected". It is *easy* to screw up, >and if you screw up as root ... > It IS risky. Therefore some systems only allow hard wired terminals in a secure location where root can be logged on. Also, on most (if not all) systems there are back up run regularly. It saves the system from a disk crash or two, not to mention root screw ups. >I would think that a "library" (or "bin") login would exist for the purpose >of installing and maintaining software. The second timesharing system I ...... > Well, sure. But that doesn't mean root can't get to it. You need root to create the directory, right? Anything root creates, root owns. Anything root creates creates, root owns. >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.) > Well, you can call it a tradition. So that some UNIX hackers working with a new system wouldn't get confused 8-). System V and Berkeley's are pretty much the same in terms of directory organization. And yes, anyone who has the root privilege can wreck havoc with the system. Fai Lau SUNY at Buffalo (The Arctic Wonderland) UU: ..{rutgers,ames}!sunybcs!ugfailau BI: ugfailau@sunybcs INT: ugfailau@joey.cs.buffalo.EDU
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/14/88)
In article <9269@sunybcs.UUCP> ugfailau@sunybcs.UUCP (Fai Lau) writes: >Well, root owns everything because there has to be an user >that owns everything. Not true. >anyone who has the root privilege can wreck havoc with the system. Yes, this is why on a properly set-up system the only occasion for an interactive user to operate as "root" is when installing some software that requires privilege (e.g., "passwd"). Operating as "root" to do routine administrative actions is a stupid policy.
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/15/88)
In article <7454@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: | software that requires privilege (e.g., "passwd"). Operating as | "root" to do routine administrative actions is a stupid policy. I hope you say that somewhat casually. I consider backups to be a routine administrative action, and don't have the luxury of being able to do the daily in single user mode. If not root, then how would you do it? -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
wesommer@athena.mit.edu (William E. Sommerfeld) (03/15/88)
In article <9926@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: > I hope you say that somewhat casually. I consider backups to be a >routine administrative action, and don't have the luxury of being able >to do the daily in single user mode. If not root, then how would you do it? 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. You will have to either hack dump to put /etc/dumpdates into backup's homedir, or let backup be able to create files in /etc; we do the latter, by making /etc writeable by group `operator' with the sticky bit set and by having backup own /etc/dumpdates. - Bill
bzs@bu-cs.BU.EDU (Barry Shein) (03/15/88)
worn everything? what is this, rogue?
jgd@csd1.milw.wisc.edu (John G Dobnick,EMS E380,5727,) (03/15/88)
From article <20626@bu-cs.BU.EDU>, by bzs@bu-cs.BU.EDU (Barry Shein): > > worn everything? what is this, rogue? [Ack! Caught by Barry Shein, no less! How humiliating...] Mea Culpa! I tried posting a followup to my original article but it was apparently eaten by the "article eater"! After very carefully reviewing my (original) posting for spelling and grammar problems, I sent it off. So, what do I notice? I screwed up on the *subject* line, of all things! Embarassing! :-} The subject line should, of course, read 'Why does "root" own everthing?' -- 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 Safire
kensmith@sunybcs.uucp (Ken Smith) (03/15/88)
In article <9926@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: > > I hope you say that somewhat casually. I consider backups to be a >routine administrative action, and don't have the luxury of being able >to do the daily in single user mode. If not root, then how would you do it? All that's needed for being able to dump is permission to read the device you're trying to dump. Group privileges for an 'operator' account are a convenient way of handling it. Be sure they also have write permission on /etc/dumpdates. It's too bad rdump uses a privileged socket, it'd be nice to be able to remote dump workstations from a non-root account. At least there is a way to set it up so you don't have to make root on the workstation equivalent to root on the system you're dumping to... For you security minded people check the permissions of your disks in /dev, we found them world readable at one point on a couple of our systems. I have no idea how they got that way, the list of past and present system administrators here is long... Ken Smith internet: kensmith@cs.buffalo.edu bitnet: kensmith@sunybcs.BITNET uucp: ..!{ames,boulder,decvax,rutgers}!sunybcs!kensmith
tim@doug.UUCP (Tim J Ihde) (03/16/88)
In article <9926@steinmetz.steinmetz.UUCP>, davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) writes: > I consider backups to be a > routine administrative action, and don't have the luxury of being able > to do the daily in single user mode. If not root, then how would you do it? Our solution in this situation was to create a login called 'backup,' which came up as uid zero with a special C program as its shell. This program then did the backup. -- Tim J. Ihde ihnp4!ctsmain!doug!tim (201) 560-6808 This disclaimer intentionally left blank.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/19/88)
In article <9926@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: -In article <7454@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: -| software that requires privilege (e.g., "passwd"). Operating as -| "root" to do routine administrative actions is a stupid policy. - I hope you say that somewhat casually. I consider backups to be a -routine administrative action, and don't have the luxury of being able -to do the daily in single user mode. If not root, then how would you do it? The way it's done at BRL is that there is an "operator account" (UID non-zero), and a set-UID 0 interface executable only by the operator UID that can invoke a limited number of privileged functions, including backup/restore. That is the proper way to invoke privileged functions on UNIX.
ugfailau@sunybcs.uucp (Fai Lau) (03/21/88)
In article <7464@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > >The way it's done at BRL is that there is an "operator account" (UID >non-zero), and a set-UID 0 interface executable only by the operator >UID that can invoke a limited number of privileged functions, >including backup/restore. > Or one can 'su' himself to be root, if he has the privilege. Fai Lau SUNY at Buffalo (The Arctic Wonderland) UUCP: ..{mit-ems|watmath|rocksanne}!sunybcs!ugfailau BI: ugfailau@sunybcs
ugfailau@sunybcs.uucp (Fai Lau) (03/21/88)
In article <9464@sunybcs.UUCP> ugfailau@sunybcs.UUCP ( I ) writes: >In article <7464@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >> [.......] > Or one can 'su' himself to be root, if he has the privilege. > The article I referred to was writen by Bill Dacivsen actually. In the process of editing the article I deleted the wrong "In article write" line. My apology. " In article <9926@steinmetz.steinmetz.UUCP> davidsen@crdos1.UUCP (bill davidsen) writes: " Fai Lau SUNY at Buffalo (The Arctic Wonderland) UUCP: ..{mit-ems|watmath|rocksanne}!sunybcs!ugfailau BI: ugfailau@sunybcs
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/21/88)
In article <9464@sunybcs.UUCP> ugfailau@sunybcs.UUCP (Fai Lau) writes: > Or one can 'su' himself to be root, if he has the privilege. Weren't you paying attention? That is the practice I was objecting to!