mgallagh@uhasun.hartford.edu (Michael Gallagher) (04/09/91)
While doing some more testing/looking-about of Minix [1.5], came across
what I would tend to certainly call a potential security problem in
Minix:
Using two accts that were not priv'd, I found that while files created
by one could not be read, etc with by the other if protections were not set
for world or group [umask = 77], they COULD be rm'd. In fact, you are
prompted as to whether you wish to actually remove this file DESPITE that
it's protection code is 700 [no world or group access].
This would seem to me to be a potential problem. i.e., files that must
stay world-readable, such as passwd could be erased....
Anyone know why this would be the case?? I suppose one could just
patch rm & re-compile it, but I'm surprised that it is set as such.
-mg
protonen@daimi.aau.dk (Lars J|dal) (04/09/91)
mgallagh@uhasun.hartford.edu (Michael Gallagher) writes: > While doing some more testing/looking-about of Minix [1.5], came across >what I would tend to certainly call a potential security problem in >Minix: [In short: You can rm files you have no acces rights for] > This would seem to me to be a potential problem. i.e., files that must >stay world-readable, such as passwd could be erased.... I have seen the same problem with my ST Minix 1.1, but I thought must have been corrected long ago, so I haven't reported. Actually, I couldn't rm the passwd file (of course I had to try :-) ), seemingly because rm respected the protection of the directory the passwd file is in. > Anyone know why this would be the case?? I suppose one could just >patch rm & re-compile it, but I'm surprised that it is set as such. I don't know if I'm right, but I would guess that the rm program runs as a set-uid owned by root. This means that if the program itself does not check then the OS will not protect you (OS claim: The root is always right :-) ). > -mg |--------------------------------------------------------------------------| | Lars J|dal | (put your favourite quotation here) | | protonen@daimi.aau.dk | | |--------------------------------------------------------------------------| | Computer Science Department - Aarhus University - Aarhus - Denmark | |--------------------------------------------------------------------------|
richard@aiai.ed.ac.uk (Richard Tobin) (04/09/91)
In article <553@ultrix.uhasun.hartford.edu> mgallagh@uhasun.hartford.edu (Michael Gallagher) writes: > Using two accts that were not priv'd, I found that while files created >by one could not be read, etc with by the other if protections were not set >for world or group [umask = 77], they COULD be rm'd. Unix allows you to remove a file if you have write permission on the directory containing the file. The permissions on the file itself are irrelevant, but rm warns you on the grounds that you might be making a mistake. > This would seem to me to be a potential problem. i.e., files that must >stay world-readable, such as passwd could be erased.... /etc is not normally world-writable, so you should not be able to remove /etc/passwd. If you can, then either the permissions on /etc are wrong, or you really have a bug (not in rm, but in the operating system). > Anyone know why this would be the case?? I suppose one could just >patch rm & re-compile it, but I'm surprised that it is set as such. A change to rm would be useless, since one could just write one's own version. The protection is implemented by the file system, not the application. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
groot@idca.tds.philips.nl (Henk de Groot) (04/09/91)
In <553@ultrix.uhasun.hartford.edu> mgallagh@uhasun.hartford.edu (Michael Gallagher) writes: > While doing some more testing/looking-about of Minix [1.5], came across >what I would tend to certainly call a potential security problem in >Minix: > Using two accts that were not priv'd, I found that while files created >by one could not be read, etc with by the other if protections were not set >for world or group [umask = 77], they COULD be rm'd. In fact, you are >prompted as to whether you wish to actually remove this file DESPITE that >it's protection code is 700 [no world or group access]. It's the same in UNIX. Removing the file has to do with the privileges of the directory. Try this: create a directory as an ordinary user. go into that directory. become superuser. make a file x by typing "> x" chmod 000 x --- now nobody should be able to read/write/execute the file become the normal user again remove with "rm x" the system responds (at least mine) with "x: 0 mode ? " answer "y" and the file is remove though it's not yours and you don't have any access to it! This is how it works with AT&T unix. Now the otherway around: become superuser make a directory (say x) chmod 755 x (so only root can write the directory) cd x "> x" chmod 777 x (whole world permission to do anything with file x) now become the ordinary user again cd x you can vi, ed, etc the file x but if you try "rm x" you will get: "rm: x not removed." "Permission denied" So that is how AT&T unix works, compare that to Minix. Henk. -- / / Henk de Groot | Department: PG 9000i - System Services /---/ __ __ / V2/A12-A13 | Internet : groot@idca.tds.philips.nl / / (-_ / / /( Tel: +31 55 432099 | == PHILIPS INFORMATION SYSTEMS == Disclaimer: I only speak for myself, not for my employer!
klamer@mi.eltn.utwente.nl (Klamer Schutte) (04/09/91)
In <553@ultrix.uhasun.hartford.edu> mgallagh@uhasun.hartford.edu (Michael Gallagher) writes: > While doing some more testing/looking-about of Minix [1.5], came across >what I would tend to certainly call a potential security problem in >Minix: > Using two accts that were not priv'd, I found that while files created >by one could not be read, etc with by the other if protections were not set >for world or group [umask = 77], they COULD be rm'd. In fact, you are >prompted as to whether you wish to actually remove this file DESPITE that >it's protection code is 700 [no world or group access]. In UNIX a file is deleteable (rather, unlinkable, if you get the fine difference) when the directory in which it resides is writable. So the directory in which you tried this should have been writable for both users. Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer
scholes@spot.Colorado.EDU (SCHOLES MARTIN LEE) (04/10/91)
In article <553@ultrix.uhasun.hartford.edu> mgallagh@uhasun.hartford.edu (Michael Gallagher) writes: > > While doing some more testing/looking-about of Minix [1.5], came across >what I would tend to certainly call a potential security problem in >Minix: > > Using two accts that were not priv'd, I found that while files created >by one could not be read, etc with by the other if protections were not set >for world or group [umask = 77], they COULD be rm'd. In fact, you are >prompted as to whether you wish to actually remove this file DESPITE that >it's protection code is 700 [no world or group access]. The reason is that changes to a directory (creating new files, deleting old ones) are allowed or not allowed by the directory privileges, not the file privileges. Marty
Christoph van Wuellen <HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu> (04/10/91)
The ability of removing a file has nothing to do with permissions set on the file, but with permissions set on the directory where the file resides: When you remove a file, you actually write to its parent directory. On UNIX, you can e.g. remove files beloging to other users if they reside in /tmp Check if this is the case in your case (?) C.v.W.
dfs@doe.carleton.ca (David F. Skoll) (04/10/91)
In <50276@nigel.ee.udel.edu> Christoph van Wuellen <HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu> writes: >The ability of removing a file has nothing to do with permissions set >on the file, but with permissions set on the directory where the file >resides: >When you remove a file, you actually write to its parent directory. >On UNIX, you can e.g. remove files beloging to other users if they reside >in /tmp If you can do this, then /tmp has been set up wrong. Most Unix systems allow you to set a "sticky" bit in the /tmp permissions. This sticky bit causes the OS to specifically disallow anyone other than the owner of the file, root, or the owner of /tmp to remove a file in /tmp. Maybe Minix needs a directory "sticky bit." -- David F. SKoll
v882087@si.hhs.nl (04/10/91)
In article <9104091436.AA13999@mcsun.EU.net> and mgallagh@uhasun.hartford.edu (Michael Gallagher) had a discussion about [In short: file can be rm'ed even if not owner. security bits, etc...] The ONLY thing that is important to the rm (or mv) command is the permission given to the directory. The permissions given to the file are only important when one tries to read, write or execute the file. If one removes the file, the file is not read, written or executed. Hope I could be any help to you guys. Hans, | | / Hans Voss <v882087@si.hhs.nl> |___| / Parkweg 200 +--------------------------------------------- | | / 3134 VS VLAARDINGEN | "Wow" -- Zaphod Beeblebrox | |/ The Netherlands |
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (04/11/91)
In article <50276@nigel.ee.udel.edu> HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >On UNIX, you can e.g. remove files beloging to other users if they reside >in /tmp Not in BSD. I think that BSD handles this correctly. A file owned by another user in /tmp should not be unlinkable if it doesn't have write status for the user doing the unlinking, even if the directory gives write status to that user. -- favourite oxymorons: student athlete, military justice, mercy killing Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh
wjb%cogsci.COG.JHU.EDU@vm1.nodak.edu (04/11/91)
In article <31804@usc> kjh wrote: >In article <50276@nigel.ee.udel.edu> HBO043@DJUKFA11.BITNET (Christoph van Wuellen) writes: >>On UNIX, you can e.g. remove files beloging to other users if they reside >>in /tmp > >Not in BSD. I think that BSD handles this correctly. A file owned by >another user in /tmp should not be unlinkable if it doesn't have write >status for the user doing the unlinking, even if the directory gives >write status to that user. Even BSD allows you to do this. It is a selectable option. If the directory has the "sticky" bit turned on then you can not remove other people's files. If it is not set (the default and historically compatible case) then you can do so. Check the permissions on /tmp and see if your sticky bit is turned on. Bill Bogstad
darius@edm.isac.CA (Darius S. Naqvi) (04/12/91)
In article <50276@nigel.ee.udel.edu> Christoph van Wuellen <HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu> writes: >The ability of removing a file has nothing to do with permissions set >on the file, but with permissions set on the directory where the file >resides: >When you remove a file, you actually write to its parent directory. > >On UNIX, you can e.g. remove files beloging to other users if they reside >in /tmp > This is the case on all the UNIXes that I have seen, except SCO UNIX. It has some extra security garbage that is a real pain, plus it just insists on doing some things differently than everyone else. As one example, you CANNOT remove other user's files residing in /tmp. -- Darius S. Naqvi mail:darius@edm.isac.ca ISA Corp. uucp:{uunet,alberta}!ncc!isagate!darius Edmonton, Alberta, Canada phone:(403) 420-8081
Christoph van Wuellen <HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu> (04/12/91)
I am pretty sure that I can remove files owned by other's in /tmp even if they are not writable under SunOS 4.X, which should behave BSD-like. -- I have just done exactly that. C.v.W.
amoss@SHUM.HUJI.AC.IL (Amos Shapira) (04/15/91)
mgallagh@uhasun.hartford.edu (Michael Gallagher) writes: > Using two accts that were not priv'd, I found that while files created >by one could not be read, etc with by the other if protections were not set >for world or group [umask = 77], they COULD be rm'd. In fact, you are >prompted as to whether you wish to actually remove this file DESPITE that >it's protection code is 700 [no world or group access]. The action of removing a file actually writes its "parent": the directory which holds the name of the file. This is not a security hole but part of the design. To not allow the world to remove a file you should deal with the permissions of the directory containing its name, that's why anyone can read /etc/passwd and other important files but can't, on a properly managed system, remove these files or change their names. Hope this explains, > -mg -Amos Shapira amoss@cs.huji.ac.il
hp@vmars.tuwien.ac.at (Peter Holzer) (04/15/91)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >I am pretty sure that I can remove files owned by other's in /tmp >even if they are not writable under SunOS 4.X, which should behave >BSD-like. >-- I have just done exactly that. In BSD the sticky bit is used to prevent people from unlinking other peoples files in world writable directories. Only the owner of the directory and the owner of the file can unlink files in a directory with the sticky bit set. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
wolff@duteca (Roger Wolff) (04/17/91)
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) writes: >On UNIX, you can e.g. remove files beloging to other users if they reside >in /tmp >Check if this is the case in your case (?) Well, there is the S_ISVTX (sticky) bit that can be set on a directory This will prevent this. This does not work on every unix system, and many system administrators will not bother to set the bit on /tmp and /usr/spool/mail but at least on suns. As a real security leak: our system administrator has a script that will put the password entry of a new user into /tmp/.newpasswd and then rsh machine 'cat >> /etc/passwd' </tmp/.newpasswd to add the user to other machines. This is a security leak as soon as the specific bit is off: one could wait for a new user to be added, and quickly copy the old one, append your own root account, delete the old one and insert your new entry! Rogier.