dwatola@NEXTASY2.EECS.WSU.EDU (David Watola) (06/23/91)
very recently, some people have pointed out that making automounted floppies or opticals owned by whoever is on the console (and ignoring actual written ownerships) is a security risk. but consider the alternative. i could make a setuid root script or program that gave me a subshell here on my machine at home, pop it on a floppy (or optical disk if i had one) and bring it to school. if the written ownerships were respected, then i would magically inherit root privileges. neat, huh? so which security risk is worse. there would also be the problem that internal user numbers for the same user vary from system to system. i suspect that this is the cause of some of the problems i have transferring writenow files between machines. often, when i try to open a file i have transferred, it will tell me that the file is locked by some other account that never even touched the file!!! apparently, writenow maintains (in the file itself) a record of who used it last for this purpose. hmmmm... i'm a little to lazy to try this out myself right now, so i'll submit it to all you readers. if you put a setuid root executable on a floppy and it gets automounted by the workspace, does it still come up as a setuid file? and setuid who? i dimly recall that once i tried putting a setuid root file on a floppy and it refused to work, but i was in no mood to find out why. and how about opticals? (i couldn't check this out--i don't have root access to a machine with an optical drive). dave watola dwatola@nextasy2.eecs.wsu.edu dwatola@yoda.eecs.wsu.edu
jwright@cfht.hawaii.edu (Jim Wright) (06/23/91)
dwatola@NEXTASY2.EECS.WSU.EDU (David Watola) writes: >very recently, some people have pointed out that making automounted >floppies or opticals owned by whoever is on the console (and ignoring >actual written ownerships) is a security risk. > >but consider the alternative. [ make a suid program on one NeXT using root access, take optical to another, bust in ] >neat, huh? so which security risk is worse. Not *THE* alternative. *ONE* alternative. I would prefer that the owner/group of removable media was preserved and suid/sgid was disabled. This makes a lot more sense to me. This is how the NeXT currently behaves: * Anyone can set the suid bit on any file on an automounted optical. * The suid bit will not be honored on any file on an automounted optical. * The suid bit will be preserved after the optical is unmounted. This is an easy way to get root privileges without ever needing the root password on any machine. If automounted disks honored the owner and group information, then you would need the root password on at least one machine for such an attack. -- Jim Wright jwright@cfht.hawaii.edu Canada-France-Hawaii Telescope Corp.