jc@minya.UUCP (John Chambers) (11/18/88)
> It might; but there are no known uses for the (now disallowed) kernel > invocation of set-id #! scripts that are also secure. ksh can be made > to interpret set-id scripts, but it works without #! doing the ID setting; > one installs ksh itself setuid root instead. Similar changes could be > made to sh and csh. > > In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Hmmmm; I have a problem where this seems an ideal solution, and I'd like to hear another way to do it. True, I can code up a C program to do the job, and make it setuid, but a one-line script seems so much easier... The problem? Well, there's a floppy disk drive on this Sys/V machine, and as usual, floppies may be formatted in various ways, including made into file systems and mounted. The problem with this is that the mount command says: | WARNING!! - mounting: <> as </fd> | mount: Not owner This despite the fact that the /dev/dsk file has 666 permissions and /fd has 777 permissions. Only root can do a mount. This sorta interferes with users sticking a floppy in and saying to mount it. If this system had the #! convention implemented, I could just put the floppy-mount command into a script, make it setuid to root, and users would be happy. It seems that instead I have to write a bigger C program. (Well, actually, I've temporarily implemented another kludge, but it's insecure, so I won't tell you about it.) Is there a straightforward way for a sh script on a Sys/V system to do a mount on a device when run by an ordinary user? Is there some reason (other than bureaucratic perversity) that the Sys/V mount command won't do its job when the /dev and the directory have write permissions? Note that I'm talking about a small, personal workstation here, not a 1000-user system. It's obvious why you might not want this capability on a giant system. But most Sys/V machines are small, with one or two users. This hangup is viewd by some users I know as an example of how Unix is less powerful than MS/DOS. ("With DOS, all you gotta do is stick the floppy in, turn the lever, and it works. What's Unix's problem that it can't handle that?") I can feel the flames already....;-) -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
mrm@sceard.UUCP (M.R.Murphy) (11/19/88)
If any user can mount floppy disks, then you might as well allow setuid shell scripts :-)
heiby@mcdchg.chi.il.us (Ron Heiby) (11/19/88)
John Chambers (jc@minya.UUCP) writes: > This despite the fact that the /dev/dsk file has 666 permissions and > /fd has 777 permissions. Only root can do a mount. > > This sorta interferes with users sticking a floppy in and saying > to mount it. > > Is there > some reason (other than bureaucratic perversity) that the Sys/V > mount command won't do its job when the /dev and the directory > have write permissions? The reason you don't (in general) want a user to be able to mount an arbitrary floppy is that once mounted, a.outs on it can be executed and the suid and sgid bits will be honored. In the environment you describe, I could format and mount a floppy, copy /bin/sh to it, chown the sh to root, and unmount the floppy. Now, since the /dev entry is mode 666, I can modify the inode of the copy of sh just put onto the floppy to change its mode bits, turning on the suid bit. Now, mounting the floppy again, I execute "my" copy of sh from the floppy and I'm running with euid of 0. Not a pretty picture. Note that AT&T's standard System V release has incorporated the facility for user mounting of floppies for some time. Of course, the way it was done for the releases of two years ago (when I left AT&T) made it even easier to become root using that facility. Disable the logins: checkfsys, makefsys, mountfsys, and umountfsys by changing the password field to "NONE" for those four in the /etc/passwd file if you have them. Do it now! In your environment, where there are only one or two people using the machine, this is probably no big deal. Do what you want. Your vendor doesn't know ahead of time how you plan to use the system, though. -- Ron Heiby, heiby@mcdchg.chi.il.us Moderator: comp.newprod "There is a fine line between stupidity and cleverness." (This is Spinal Tap)
andrew@frip.gwd.tek.com (Andrew Klossner) (11/19/88)
[]
"Is there some reason (other than bureaucratic perversity) that
the Sys/V mount command won't do its job when the /dev and the
directory have write permissions?"
Being able to mount a floppy is a far more powerful thing that being
able to read or write the floppy. For example, you could prepare the
floppy so that it contains a file system with a suid-root shell, using
only floppy read/write (or on a PC). Hence, whoever can mount the
floppy has the equivalent of root powers; so the mount syscall is
restricted to root.
If you don't need this restriction on your workstation, make /etc/mount
a suid-root executable by all. (This works on my 4.2BSD-based
workstation; I haven't tried it on sysV.) No need for suid shell
scripts or special programs.
-=- Andrew Klossner (uunet!tektronix!hammer!frip!andrew) [UUCP]
(andrew%frip.gwd.tek.com@relay.cs.net) [ARPA]jc@minya.UUCP (John Chambers) (11/24/88)
In article <14598@mcdchg.chi.il.us>, heiby@mcdchg.chi.il.us (Ron Heiby) writes: > John Chambers (jc@minya.UUCP) writes: > > This despite the fact that the /dev/dsk file has 666 permissions and > > /fd has 777 permissions. Only root can do a mount. > > > > This sorta interferes with users sticking a floppy in and saying > > to mount it. ... > [Explanation of security problems deleted] Yeah, I said in the original posting that I understood why for a big installation it might not be a good idea. But this is a two-user system, and we're good friends (POSSLQs, actually ;-). It's the sort of environment where most people would use DOS, but we're smarter than that, and have Unix. We'd like Unix to be able to do some things that DOS can do, like sticking in a floppy disk and using its files. > In your environment, where there are only one or two people using the > machine, this is probably no big deal. Do what you want. Your vendor > doesn't know ahead of time how you plan to use the system, though. OK, so how do I get it to do what I want? It seems to me that if I'm interested in securing access to the floppy drive, that making it owned by root or daemon or bin with 770 permissions would be sufficient notice to mount that mere users aren't to touch it. I've set the permissions to 777, which should convince mount that the system's owner has decided to let anyone use the device. But mount refuses to do it anyway, even though root has given permission. This seems rather pointless to me. This strikes me as a case where a setuid-root script (which this Sys/V doesn't have) would come in very handy. I don't think it's a *good* use of setuid-root, because I don't think I should have to play any such games at all. But it would work. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]
flint@gistdev.UUCP (11/27/88)
I think it would be nice to have an option on mount that would basically say "If the suid or guid bits are set on any files not owned by me, then clear the bits and then mount the floppy." Such an option could presumably be used without your having to be the super-user: it might be extremely slow, but so what? Mounting a floppy is hardly a fast operation in the first place.
law@udel.EDU (Jeff Law) (11/28/88)
In article <8800002@gistdev> flint@gistdev.UUCP writes: > >I think it would be nice to have an option on mount that would basically say >"If the suid or guid bits are set on any files not owned by me, then clear the >bits and then mount the floppy." suid programs are not the only problem with allowing users to mount floppies, what is going to stop me from putting my floppy in the drive and saying mount /dev/floppy /etc now i have mounted a floppy as /etc... what happens if i have a passwd file on my floppy with a no password root account?? This is the exact procedure i used to circumvent hewlett packard's PAM on the integral pc. it allows anyone to mount floppies... Jeff -- Jeffrey A Law University of Delaware PHONE: (302)-451-8005, (302)-451-6339 ARPA: law@udel.EDU, UUCP: ...!<your_favorite_arpa_gateway>!udel.edu!law
lvc@cbnews.ATT.COM (Lawrence V. Cipriani) (11/28/88)
In article <8800002@gistdev> flint@gistdev.UUCP writes: > >I think it would be nice to have an option on mount that would basically say >"If the suid or guid bits are set on any files not owned by me, then clear the >bits and then mount the floppy." Such an option could presumably be used >without your having to be the super-user: it might be extremely slow, but so >what? Mounting a floppy is hardly a fast operation in the first place. Something similar to this is in *some* versions of UNIX(tm). The set[ug]id bits are ignored on exec, opens on block or character devices are failed, and copying a set[ug]id file on such a file system would clear the s[ug]id bits. This is applicable on a file system basis, not just for floppies. I hope it is in UNIX SVR4. UNIX is a registered trademark of AT&T. -- Larry Cipriani, AT&T Network Systems, Columbus OH, Path: att!cbnews!lvc Domain: lvc@cbnews.ATT.COM
lvc@cbnews.ATT.COM (Lawrence V. Cipriani) (11/28/88)
In article <2350@cbnews.ATT.COM> lvc@cbnews.ATT.COM (Lawrence V. Cipriani) writes: >Something similar to this is in *some* versions of UNIX(tm). The set[ug]id >bits are ignored on exec, opens on block or character devices are failed, and >copying a set[ug]id file on such a file system would clear the s[ug]id bits. >This is applicable on a file system basis, not just for floppies. I hope >it is in UNIX SVR4. I should have said that the list of users allowed to mount what file systems is stored in a file somewhere in /etc. This prevents the problem of mounting a floppy with a password file that someone mentioned. >UNIX is a registered trademark of AT&T. -- Larry Cipriani, AT&T Network Systems, Columbus OH, Path: att!cbnews!lvc Domain: lvc@cbnews.ATT.COM
les@chinet.chi.il.us (Leslie Mikesell) (11/29/88)
In article <139@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >> > This despite the fact that the /dev/dsk file has 666 permissions and >> > /fd has 777 permissions. Only root can do a mount. >Unix. We'd like Unix to be able to do some things that DOS can do, like >sticking in a floppy disk and using its files. >OK, so how do I get it to do what I want? Can't you just make /etc/mount setuid-root? Les Mikesell
hakanson@mist.cs.orst.edu (Marion Hakanson) (11/29/88)
I also had some experience with the HP Integral (which someone else mentioned) doing summer work in QA on the thing. I remember calling it the "Portable SU" at the time. In article <8800002@gistdev> flint@gistdev.UUCP writes: > >I think it would be nice to have an option on mount that would basically say >"If the suid or guid bits are set on any files not owned by me, then clear the >bits and then mount the floppy." Such an option could presumably be used >without your having to be the super-user: it might be extremely slow, but so >what? Mounting a floppy is hardly a fast operation in the first place. Years ago (1985, in fact), I wrote a C program (which runs setuid-root) to do exactly this. It was written and tested on 4.2bsd, but was almost ported to SysV (I think all it lacks are mkdir(), rmdir(), and getgroups() routines to emulate those in 4.2). The program has languished since our floppy drives went away, but I did test it pretty thoroughly. Basically, any user could mount (and unmount) the devices listed in /etc/pubmount. The program used access(2) to check to see if the caller had rwx access to the mount point, thus helping to disallow mounting over system directories. For further explanation, see the header comments below. I haven't even looked at the program for a couple of years, so please excuse any mistakes I might've made in my youth. I'd be willing to post the thing to comp.sources.unix, I suppose, if demand warrants it, and with the caveat that my time to maintain the thing is very limited. Note that the program could undoubtedly be made more robust, and that it was written without consideration for NFS mounts. /* ** $Header: mountpub.c,v 1.15 85/11/18 11:45:36 hakanson Exp $ ** ** Usage: ** mountpub [-fr] device directory ** -f force clearing of bits (don't ask user). ** -r read only filesystem (pass on to mount command). ** or: ** umountpub device ** ** This program allows any user to mount/unmount devices to ** which the system administrator has allowed public access. ** It runs setuid to root, but will not give access to files, ** devices, or directories for which the user would not normally ** have permissions. ** ** The main thing mountpub does is to check the contents of ** the filesystem being mounted to be sure that there are no ** setuid/setgid files that would give permissions that the ** caller does not already have. Hence this makes it safer ** to allow the average user to mount filesystems. ** ** Mountpub uses find(1) to scan the candidate filesystem after ** mounting it to a temporary directory (which is inaccessible ** to all but root), looking for setuid files not owned by ** the caller and setgid files with group ID's other than ** those allowed for the user (in /etc/passwd and /etc/group). ** ** Mountpub will not allow the filesystem to be mounted unless ** it can clear the setuid/setgid bits of the offending files ** (if any). When the contents are safe, mountpub will unmount ** from the temporary directory and call the normal mount ** command with the original arguements, in order to set up ** the mount table properly, etc. (rather than do this itself). ** ** If mountpub is called with a command starting with a "u", ** it will go through the normal access checks for the caller, ** and invoke the system umount command to unmount the filesystem. */ -- Marion Hakanson Domain: hakanson@cs.orst.edu UUCP : {hp-pcd,tektronix}!orstcs!hakanson
gordon@sneaky.TANDY.COM (Gordon Burditt) (11/29/88)
>>I think it would be nice to have an option on mount that would basically say >>"If the suid or guid bits are set on any files not owned by me, then clear the >>bits and then mount the floppy." >suid programs are not the only problem with allowing users to mount floppies, >what is going to stop me from putting my floppy in the drive and saying >mount /dev/floppy /etc > >now i have mounted a floppy as /etc... what happens if i have a passwd file A long time ago I wrote a program that allowed users to mount floppies "safely". It ran setuid and checked the device against an allowable list of devices that were mountable by users. It permitted a given device to be mounted in *EXACTLY ONE* place, which existed only for that purpose. It checked that the directory being mounted on was empty. It scanned the floppy for set-uid programs. (It was my preference to disallow mounting rather than reset setuid bits. I didn't like the idea of supposedly "clean" copies of master distribution disks getting contaminated.) It also insisted that every sector of the floppy was readable. It shut off access to the raw and buffered devices when the floppy was mounted. It knew all the names that referred to the same drive. It poked around in the kernel to check that someone didn't already have the device open before access was shut off. There were hooks in the program for an authorized users list for each device. Under consideration was embedding a more thorough version of fsck into the program, and provision to allocate exclusive access to a particular user BEFORE the user had to insert the floppy. It didn't work. It was trivial to defeat, by a method similar to this: 1. Insert "clean" floppy in drive. 2. Mount it on /mnt0, using so-called "safe mount" described above. 3. Read War & Peace while it checked the floppy. 4. Remove "clean" floppy from drive (without dismounting). 5. Insert floppy containing setuid shell, preferably somewhere besides the top-level directory. 6. Cause plenty of hard disk activity to flush out the cache with a command like "du /usr". 7. Invoke setuid shell. 8. Wreak havoc. What the command needs, but didn't have, is a provision to either have the driver refuse to do any I/O after the floppy is swapped while the drive is open until it is closed (well, the driver actually did this, provided the drive detected the change. The new, improved drives didn't unless there was I/O in progress on that drive at the time), or make the drive not let go of the floppy while the drive is open without risk of electrocution of the person attempting removal. Gordon L. Burditt ...!texbell!sneaky!gordon P.S. Even this wouldn't prevent the alternate attack: 1. Obtain several cans of Classic Coke (tm). 2. Telephone sysadmin or get his attention by yelling. 3. Hold open cans of Coke (tm), or one can of Coke (tm) and one HandGun (tm) over CPU and threaten to pour Coke (tm) onto the circuit board unless the sysadmin tells you the root password. * Classic Coke (tm) is a trademark (tm) of someone, darn it.
stefan@mikros.systemware.de (Stefan Stapelberg) (11/29/88)
In article <5682@louie.udel.EDU> law@udel.EDU (Jeff Law) writes: >suid programs are not the only problem with allowing users to mount floppies, >what is going to stop me from putting my floppy in the drive and saying >mount /dev/floppy /etc I think, it is just that easy to write a small C program which checks wether the user doing the mount is the owner of the mounting point. BTW: You not only have to look for suid-files, but also for special device files! In Germany, there is a law for government agencies when accessing sensitive data (e.g. personal data): The sensitive data has to be physically present only when someone is working with it. So people like it to mount the floppy disk rather than read/write tar archives. -- Written (W) 1988 by Stefan Stapelberg <stefan@mikros.uucp> Phone: +49 9352 5948
les@chinet.chi.il.us (Leslie Mikesell) (11/30/88)
In article <4714@sneaky.TANDY.COM> gordon@sneaky.UUCP (Gordon Burditt) writes: > >A long time ago I wrote a program that allowed users to mount floppies >"safely". [...] >It didn't work. It was trivial to defeat, by a method similar to this: If you are going to go to the bother of reading the whole floppy before actually mounting it, why not just make a floppy-sized partition on the hard disk and copy the whole thing in where you can work at a reasonable speed? Then of course, you might as well not use a file system on the floppy - just cpio or tar the files (and then you don't need the separate partition on the hard disk which was just to make sure that the contents would fit back on the floppy when you were done). A nifty alternative is the "mtools" package posted by Emmet Grey, if you have a 5 1/4 or 3 1/2" floppy drive. It allows reading/writing MSDOS formatted disks under unix. This makes a fairly portable way to store files since nearly everyone these days has some way to get a file from a PC into their machine. You sometimes have to work to preserve the unix names and attributes but you can cpio or zoo the files first if necessary. Les Mikesell
guy@auspex.UUCP (Guy Harris) (12/01/88)
>BTW: You not only have to look for suid-files, but also for special >device files! Note that "ncheck", both on S5R3 and 4.3BSD, has a "-s" flag to do precisely those checks (it may do so on other UNIX versions as well); I suspect it may do so faster than, say, "find". You may be able to use it, rather than writing your own code to do it....
awm@gould.doc.ic.ac.uk (Aled Morris) (12/01/88)
>A nifty alternative is the "mtools" package posted by Emmet Grey, if you >have a 5 1/4 or 3 1/2" floppy drive. It allows reading/writing MSDOS >formatted disks under unix. How can I get hold of this package? Bearing in mind that I can't FTP from the US, an UK info-server would be best, but a mail based archive in the US would do. Alternatively, some kind sould could mail me a copy personally! (this offer is limited to the first applicant only :-) Than ksi nad van ce! Aled Morris systems programmer mail: awm@doc.ic.ac.uk | Department of Computing uucp: ..!ukc!icdoc!awm | Imperial College talk: 01-589-5111x5085 | 180 Queens Gate, London SW7 2BZ
ccdn@levels.sait.edu.au (DAVID NEWALL) (12/02/88)
In article <7606@orstcs.CS.ORST.EDU>, hakanson@mist.cs.orst.edu (Marion Hakanson) writes: > In article <8800002@gistdev> flint@gistdev.UUCP writes: >>I think it would be nice to have an option on mount that would basically say >>"If the suid or guid bits are set on any files not owned by me, then clear the >>bits and then mount the floppy." Such an option could presumably be used >>without your having to be the super-user: it might be extremely slow, but so >>what? Mounting a floppy is hardly a fast operation in the first place. > > [ explanations deleted ] > > /* > ** $Header: mountpub.c,v 1.15 85/11/18 11:45:36 hakanson Exp $ > ** > ** Usage: > ** mountpub [-fr] device directory > ** -f force clearing of bits (don't ask user). > ** -r read only filesystem (pass on to mount command). > ** or: > ** umountpub device > ** > ** This program allows any user to mount/unmount devices to > ** which the system administrator has allowed public access. > ** It runs setuid to root, but will not give access to files, > ** devices, or directories for which the user would not normally > ** have permissions. > ** > ** The main thing mountpub does is to check the contents of > ** the filesystem being mounted to be sure that there are no > ** setuid/setgid files that would give permissions that the > ** caller does not already have. Hence this makes it safer > ** to allow the average user to mount filesystems. > */ Gee, I don't know. I wonder what would happen if the user "mountpub"ed a floppy, and then replaced it with another disk that had setuid root shells on it -- ie, without unmounting the old disk? Could be nasty... -- David Newall Phone: +61 8 343 3160 Unix Systems Programmer Fax: +61 8 349 6939 Academic Computing Service E-mail: ccdn@levels.sait.oz.au SA Institute of Technology Post: The Levels, South Australia, 5095
cmf@cisunx.UUCP (Carl M. Fongheiser) (12/03/88)
In article <546@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >Note that "ncheck", both on S5R3 and 4.3BSD, has a "-s" flag to do >precisely those checks (it may do so on other UNIX versions as well) It's supposed to do just that on Ultrix as well, but the program was compiled with such small limits it can't cope with the 'h' partition of an RA81 or Eagle. And now that we've got RA82's it's completely worthless for checking to see if there's anything suspicious. Granted, it may be just the thing for an RX01. :-) Carl Fongheiser University of Pittsburgh ...!pitt!cisunx!cmf cmf@unix.cis.pittsburgh.edu cmf@pittunix.BITNET
allbery@ncoast.UUCP (Brandon S. Allbery) (12/04/88)
As quoted from <5682@louie.udel.EDU> by law@udel.EDU (Jeff Law): +--------------- | In article <8800002@gistdev> flint@gistdev.UUCP writes: | >I think it would be nice to have an option on mount that would basically say | >"If the suid or guid bits are set on any files not owned by me, then clear the | >bits and then mount the floppy." | suid programs are not the only problem with allowing users to mount floppies, | what is going to stop me from putting my floppy in the drive and saying | mount /dev/floppy /etc +--------------- I responded to the original posting by mail with a fairly secure approach. I should note that such an approach limits the usefulness of the floppy drive, however. Start out by making the floppy ?rwx------ root. (The ? is "c" or "b"; this must be done to both raw and character devices, and MUST BE DONE TO ALL FLOPPY DRIVES ON THE SYSTEM.) A setuid program is then used to mount floppies. It checks the floppy in question for a magic number in the superblock (most superblocks have an unused area where such a number could be hidden) which identifies the uid of the owner -- which must be that of the person doing the mount -- and that this is a special user-mountable floppy. (Root must build and flag the floppy because of the permissions.) It then will only mount the floppy on an empty directory in the user's directory hierarchy, whose path (at least from below the home dir on down) contains no symlinks and which is owned by the user doing the mount. It also might be a good idea to refuse mounts by people logged in on non-local terminals, although this isn't necessarily so. (Back when ncoast was a TRS-80 Model 16 with a 15MB disk, my home directory was the floppy drive....) The minus of this scheme is that only root can use the floppy for non-mounted disks (tar/cpio/whatever). The plus is that a user can have his/her own set of mountable disks, and not only can the user not break into the system, but nobody else can "borrow" the disks and mount them to snoop around in them. No doubt there are a few things I overlooked, but this is a pretty good start and can probably be refined to remove any remaining security holes. Note that under System V without symlinks, it's pretty secure already.... ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
jgy@hropus.UUCP (John Young) (12/05/88)
> As quoted from <5682@louie.udel.EDU> by law@udel.EDU (Jeff Law): > +--------------- > | In article <8800002@gistdev> flint@gistdev.UUCP writes: > | >I think it would be nice to have an option on mount that would basically say > | >"If the suid or guid bits are set on any files not owned by me, then clear the > | >bits and then mount the floppy." > | suid programs are not the only problem with allowing users to mount floppies, > | what is going to stop me from putting my floppy in the drive and saying > | mount /dev/floppy /etc > +--------------- > > I responded to the original posting by mail with a fairly secure approach. > I should note that such an approach limits the usefulness of the floppy > drive, however. > > Start out by making the floppy ?rwx------ root. (The ? is "c" or "b"; this > must be done to both raw and character devices, and MUST BE DONE TO ALL > FLOPPY DRIVES ON THE SYSTEM.) > > A setuid program is then used to mount floppies. It checks the floppy in > question for a magic number in the superblock (most superblocks have an > unused area where such a number could be hidden) which identifies the uid of > the owner -- which must be that of the person doing the mount -- and that > this is a special user-mountable floppy. (Root must build and flag the > floppy because of the permissions.) It then will only mount the floppy on > an empty directory in the user's directory hierarchy, whose path (at least > from below the home dir on down) contains no symlinks and which is owned by > the user doing the mount. It also might be a good idea to refuse mounts by > people logged in on non-local terminals, although this isn't necessarily so. > (Back when ncoast was a TRS-80 Model 16 with a 15MB disk, my home directory > was the floppy drive....) > > The minus of this scheme is that only root can use the floppy for non-mounted > disks (tar/cpio/whatever). The plus is that a user can have his/her own set > of mountable disks, and not only can the user not break into the system, but > nobody else can "borrow" the disks and mount them to snoop around in them. > > No doubt there are a few things I overlooked, but this is a pretty good > start and can probably be refined to remove any remaining security holes. > > Note that under System V without symlinks, it's pretty secure already.... > > ++Brandon No, you cannot rely on a system which attempts to stop bad things from being done to removable media, the effort should on defending against pressumed bad media. Therefore you still need your suid (sgid might be better?) mount command to check for s(uid|gid) programs and either clear them or refuse to mount.
peter@ficc.uu.net (Peter da Silva) (12/06/88)
Since you have to diddle with the system anyway, why not just ignore setuid bits and device special files on floppies not mounted by root? This is the logical solution to the problem... just get namei() and stat() in a conspiracy along with whatever other system calls are needed to make it work (open, exec, mount, etc...). -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: I accept full responsibility for my typos. peter@ficc.uu.net
rickert@local.mcs.anl.gov (Neil Rickert) (12/06/88)
Users should be able to mount floppies. But it would take some internal modifications. What is needed is for the kernel to ignore the suid and sgid mode flags for a disk mounted by other than root. Physically changing all of the flags is just a time waste. The kernel already keeps information in memory about each mounted file system. It needs to keep an additional mode flag for the file system which is automatically ANDed with all file modes from files on that file system, to compute an effective mode. When the file system is mounted by "root" on a directory owned by "root" that additional mode flag would consist of all 1's. In other cases it would turn off at least the suid and sgid bits, possibly also the execute bits. Of course anyone other than root should be permitted to mount only a file system on a device he has suitable access permissions to, and only on a directory he owns. This would prevent mounting a replacment for /etc (or even for /tmp). Once these changes are incorporated into Unix it becomes worth investigating arrangements where a user on a work station can mount his work station file system onto a remote system he is connected to. Neil Rickert, Northern Illinois University.
guy@auspex.UUCP (Guy Harris) (12/07/88)
>What is needed is for the kernel to ignore the suid and sgid mode flags >for a disk mounted by other than root. Physically changing all of the >flags is just a time waste. The kernel already keeps information in >memory about each mounted file system. It needs to keep an additional >mode flag for the file system which is automatically ANDed with all >file modes from files on that file system, to compute an effective >mode. SunOS already includes such a flag; see the M_NOSUID flag in MOUNT(2). (I suspect vendors who have picked up NFS from Sun may have picked it up as well.) The main purpose of this is for mounting NFS file systems from machines that you don't trust, but the same mechanism could be used for the similar situation with floppies. You'd also want to, as Peter Da Silva suggested, have either that flag or another flag disallow access to special files as well. Given that flag or flags, you could make "mount" semi-privileged, so that if you're not super-user you have to have the appropriate permissions on the device (or whatever you're mounting) and mount point, and you either have to request M_NOSUID and company - or the system could just force them to be on if you're not "root".
hakanson@mist.cs.orst.edu (Marion Hakanson) (12/10/88)
In article <841@levels.sait.edu.au> ccdn@levels.sait.edu.au (DAVID NEWALL) writes: . . . >> ** The main thing mountpub does is to check the contents of >> ** the filesystem being mounted to be sure that there are no >> ** setuid/setgid files that would give permissions that the > >Gee, I don't know. I wonder what would happen if the user "mountpub"ed >a floppy, and then replaced it with another disk that had setuid root >shells on it -- ie, without unmounting the old disk? Could be nasty... That's a hardware problem (1/2 :-). Doing such a thing would probably be as likely to crash the system as to allow unauthorized access, but that's a security problem as well. Mountpub also neglects to check for special (device) files, which I hadn't considered three years ago when I wrote the program. -- Marion Hakanson Domain: hakanson@cs.orst.edu UUCP : {hp-pcd,tektronix}!orstcs!hakanson
allbery@ncoast.UUCP (Brandon S. Allbery) (12/12/88)
As quoted from <404@hropus.UUCP> by jgy@hropus.UUCP (John Young): +--------------- | > (I [allbery@ncoast) suggest a secure user floppy mounter) | | No, you cannot rely on a system which attempts to stop bad things | from being done to removable media, the effort should on defending | against pressumed bad media. | Therefore you still need your suid (sgid might be better?) | mount command to check for s(uid|gid) | programs and either clear them or refuse to mount. +--------------- This can be done as well; after all, a linear pass through a floppy's ilist doesn't take very long... and you *do* have a point, since someone could build a floppy on an unprotected system and set the proper flags on it, etc. (A mountable user floppy doesn't need suid/sgid files anyway. Special files (i.e. character or block devices, but not necessarily FIFOs or Xenix name files, etc. [and do BSD AF_UNIX sockets bind()'ed to filenames still work after the last close on the socket?]) would probably cause a refusal to mount, since otherwise the mount utility needs to know quite a bit more about the filesystem. Now that I think about it, both conditions (my non-modifiability and your security checking) are necessary, but neither is sufficient by itself. --Query: do we need to avoid symlinks as well? From what I know about them, it might not be necessary because they can't grant access to otherwise protected files, but.... BTW, sgid won't work in this case; the kernel returns EPERM if anyone except root tries to do a mount(). Maybe I'll whip up such a program. Won't do much for ncoast (no floppies...) but might be useful on the job. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.