pz@munsell.UUCP (Paul Czarnecki) (03/17/88)
In article <9318@sunybcs.UUCP> kensmith@sunybcs.UUCP (Ken Smith) writes: > 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. I asked Sun what to do about this. (Isn't software support wonderful) They just told me to make /etc/dump setuid root, setgid operator. None of my backups are done by someone logging in as root. Was this stupid? pZ -- Paul Czarnecki -- Spam, spam, spam, Usenet, and spam {{harvard,ll-xn}!adelie,{decvax,allegra,talcott}!encore}!munsell!pz
louie@trantor.umd.edu (Louis A. Mamakos) (03/17/88)
In article <1610@pinney.munsell.UUCP> pz@pinney.UUCP (Paul Czarnecki) writes: >I asked Sun what to do about this. (Isn't software support wonderful) >They just told me to make /etc/dump setuid root, setgid operator. >None of my backups are done by someone logging in as root. > >Was this stupid? I think so. What's to stop Joe User from doing something like: dump 0f /dev/rra0c - | restore xf - ./path/secret-file to grab any file on your system? Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
kensmith@sunybcs.uucp (Ken Smith) (03/18/88)
In article <1610@pinney.munsell.UUCP> pz@pinney.UUCP (Paul Czarnecki) writes: >In article <9318@sunybcs.UUCP> kensmith@sunybcs.UUCP (Ken Smith) writes: >> 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. > >I asked Sun what to do about this. (Isn't software support wonderful) >They just told me to make /etc/dump setuid root, setgid operator. >None of my backups are done by someone logging in as root. > >Was this stupid? > > pZ >-- > Paul Czarnecki -- Spam, spam, spam, Usenet, and spam > {{harvard,ll-xn}!adelie,{decvax,allegra,talcott}!encore}!munsell!pz As long as /etc/dump is only executable by the people you want it to be. Otherwise it can be told to dump to stdout which can be piped to restore to extract any files on the disk. We have a program called 'sudo' that will exec a command as root for you if your username is on a certain list. My solution to the dumping problem was to make accounts on the 'unsecure' hosts called 'sundumps' that was only able to run 'sudo' for the command /etc/rdump. On the host they're dumping to there is also an account 'sundumps' with *no* privileges and a '.rhosts' file with 'root@unsecure_host' in it. The people we have doing the dumps log into the unsecure host as sundumps and do : sudo /etc/rdump 2udsf 6250 2200 joey.sundumps:/dev/rmt8 /dev/whatever to do the dump to the machine 'joey'. The 'joey.sundumps' means the rmt process on joey gets run as user sundumps. This was the best all-round way I could come up with to allow student consultants to be able to dump a couple SUN fileservers to 9-track tapes on our larger systems without compromising security too much. Ken Smith internet: kensmith@cs.buffalo.edu bitnet: kensmith@sunybcs.BITNET uucp: ..!{ames,boulder,decvax,rutgers}!sunybcs!kensmith
bzs@bu-cs.BU.EDU (Barry Shein) (03/18/88)
>I asked Sun what to do about this. (Isn't software support wonderful) >They just told me to make /etc/dump setuid root, setgid operator. >None of my backups are done by someone logging in as root. > >Was this stupid? > > pZ Given that and an unprivileged account I could read any file on your workstation and probably own it in a few minutes if I thought about it a little (consider the effect of dump 0f /etc/passwd filesys, or something along those lines.) If you're not worried about such things, or the user gaining access to all local files (it may not be of much use across nfs, tho it could be a first step in a multilevel attack) then there's not much to worry about, it depends on how hostile your environment is. Of course, they could wipe out a file or file system inadvertantly, like specifying the args in the wrong order, root privs are like that. You might instead consider writing a little setuid C program that only does exactly the right thing, providing all dump args etc or perhaps a limited menu of choices, then forking it, but not free choice such as specifying any output file on the command line. I'm not sure that would be completely secure (what harm can you do from a dump prompt?) but it may be close enough and it should only be a page of C code, you may have to be as imaginative as your imagined attacker. You might consider putting it execute-only onto a remote NFS partition, if you allow remote setuid root programs. -Barry Shein, Boston University
mjr@osiris.UUCP (Marcus J. Ranum) (03/19/88)
In article <1610@pinney.munsell.UUCP> pz@pinney.UUCP (Paul Czarnecki) writes: > >I asked Sun what to do about this. (Isn't software support wonderful) >They just told me to make /etc/dump setuid root, setgid operator. >None of my backups are done by someone logging in as root. > >Was this stupid? Gee - I am trying to remember if that is stupid or not: what happens if Joe Blow then logs in and does a "/etc/dump 0f /vmunix <dumpdev>" or something like that ?? :-) Does it also allow anyone to make a copy of a filesystem, including files that they normally couldn't look at ?? I don't know if Sun has modified dump, but I'd check it out... :-) Another option would be to have a COPY of dump that was setuid root executable only by group operator, in a place where only that group (you'd better HOPE) could execute it. --mjr(); -- ------------------------------------------------------------------------------ ...ich bin in einem dusenjet ins jahr 53 vor chr...ich lande im antiken Rom... einige gladiatoren spielen scrabble...ich rieche PIZZA...
sechrest@mist.cs.orst.edu (John Sechrest) (03/23/88)
We have set up rdump to take a flag that identifies the user to log in as. We have .rhosts that have root on the remote machines set up as backup on the machine with the tape. This lets the person doing dump on the remote machine access the tape without root privlages on that machine. But you still need root privalges on the machine doing the dump. Our next step is to set up rdump to be setuid to root but only executable by backup. But we have not gotten to that point yet. johns ----------------------------------------------------------------------------- . John Sechrest . Internet: sechrest@cs.orst.edu Lab Coordinator . UUCP: tektronix!orstcs!sechrest Computer Science Dept . UUCP: hplabs!hp-pcd!orstcs!sechrest Oregon State University . Corvallis,Oregon 97331 . (503) 754-3273 . . . . . `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`
pz@munsell.UUCP (Paul Czarnecki) (03/23/88)
In article <2463@umd5.umd.edu> louie@trantor.umd.edu (Louis A. Mamakos) writes: >In article <1610@pinney.munsell.UUCP> pz@pinney.UUCP (Paul Czarnecki) writes: >>They [Sun] just told me to make /etc/dump setuid root, setgid operator. >>None of my backups are done by someone logging in as root. >>Was this stupid? > >I think so. What's to stop Joe User from doing something like: > > dump 0f /dev/rra0c - | restore xf - ./path/secret-file This shouldn't happen. root@munsell #85 ls -lg /etc/dump -rwsr-s--- 1 root operator 90112 Sep 15 1986 /etc/dump There is no 'x' bit for normal users. You must be in the group "operator" to run this (or root). After seeing the volume of responses on this I wish I had included the 'ls' output in my original posting. pZ -- Paul Czarnecki -- Spam, spam, spam, Usenet, and spam {{harvard,ll-xn}!adelie,{decvax,allegra,talcott}!encore}!munsell!pz
karish@denali.UUCP (karish) (03/23/88)
In article <1610@pinney.munsell.UUCP> pz@pinney.UUCP (Paul Czarnecki) writes: > >I asked Sun what to do about this. (Isn't software support wonderful) >They just told me to make /etc/dump setuid root, setgid operator. >None of my backups are done by someone logging in as root. > >Was this stupid? This advice isn't stupid, but it's also not complete. There is an important security issue here, which setuid programs alone don't solve. The rdump command gets acess to the remote tape drive by using the rcmd() library function, with "root" as the remuser argument. The hosts.equiv mechanism typically denies transparent remote access to root. This denial is a Good Thing, since it means that if security is compromised on one machine, peers may still be safe. The fix is to use a special user ID, perhaps 'operator' or 'system', to run the remote process. This is easy if you have source. It's probably possible to patch the rdump binary to change the string 'root' in the parameter list for rcmd(); the string only shows up once in my (4.3BSD/SULTRIX) rdump executable. The rdump executable should still be a setuid program, setgid to a group of trusted users, with no execute permission for others. This configuration worked for us between two (4.2BSD) VAXen at the Stanford School of Earth Sciences, when one of our tape drives broke. I think the UCSF computer center uses the same scheme to back up a client's Sun disk server from a computer center VAX. I hope this helps. Chuck
mangler@cit-vax.Caltech.Edu (Don Speck) (03/25/88)
In article <1610@pinney.munsell.UUCP> pz@pinney.UUCP (Paul Czarnecki) writes: >I asked Sun what to do about this. (Isn't software support wonderful) >They just told me to make /etc/dump setuid root, setgid operator. >None of my backups are done by someone logging in as root. > >Was this stupid? 4.3bsd rdump is setuid and executable by world, but it is designed for it. After it calls rcmd(), it throws away its privileges. I don't think it's any more dangerous than 'rsh' (remote shell). SunOS rdump is derived from 4.2bsd rdump, which was NOT designed to be setuid. 4.2bsd rdump calls rcmd() with locuser = remuser = "root", and it doesn't throw away its setuid privileges afterward. Making it setuid instead of giving the operator a root shell is just fooling yourself. In article <9394@sunybcs.UUCP>, kensmith@sunybcs.uucp (Ken Smith) writes: > sudo /etc/rdump 2udsf 6250 2200 joey.sundumps:/dev/rmt8 /dev/whatever This syntax, patterned after 4.2bsd "rcp", is peculiar to SunOS and incompatible with the world of domain names. It should give way to a syntax more like 4.3bsd "rcp": rdump 0uf user@host.domain:device,device,device /filsys Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck