peter@ficc.uu.net (Peter da Silva) (11/10/89)
In article <4473@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > Thanks, but no thanks. POSIX has a long story about chown, depending on > the status of _POSIX_CHOWN_RESTRICTED. I have defined it and will make > the implementation conform accordingly. This is like links to directories... something slightly dangerous and occasionally very useful. Please reconsider this action... like links to directories, this is something that should be at most a configuration option that's normally OFF. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>. 'U` -------------- +1 713 274 5180. "*Real* wizards don't whine about how they paid their dues" -- Quentin Johnson quent@atanasoff.cs.iastate.edu
chasm@attctc.Dallas.TX.US (Charles Marslett) (11/13/89)
In article <1989Nov7.185627.24105@world.std.com>, madd@world.std.com (jim frost) writes: [With respect to allowing the owner of a file (other than root) to issue a chown() system call] > I'm curious as to what you do if the file is setuid; do you clear the > setuid bit? If not, you make a huge security hole (assuming you > care, which I do). If you've done this, please ignore. System V.3 (the interactive version, at least) does exactly this -- I checked it Friday, but I forgot to see what the other bits do (sticky, et al.). I assume setuid/setgid are the only real security holes? > jim frost > software tool & die "The World" Public Access Unix for the '90s > madd@std.com +1 617-739-WRLD 24hrs {3,12,24}00bps Charles Marslett =============================================================================== "Those who would sacrifice ** Charles Marslett liberty for security, ** STB Systems, Inc. <-- apply all std. disclaimers deserve neither." ** Wordmark Systems <-- that's just me -- Benjamin Franklin ** chasm\@attctc.dallas.tx.us -------------------------------------------------------------------------------
madd@world.std.com (jim frost) (11/14/89)
chasm@attctc.Dallas.TX.US (Charles Marslett) writes: >I assume setuid/setgid are the only real security holes? That depends on what you call a security hole; if a user can change the ownership of one of his files, there is no way to prove that a particular user actually made a particular file, or if some very large image (for instance) is owned by "foo" who has no disk quota, or "bar" who has only a megabyte. There is no way to deal with accountability. I honestly think chown should be a root-only; it's much simpler that way and if a user really needs to chown a file, logging in as the other user and using "cp" works great. This is getting off the minix track, though. jim frost software tool & die "The World" Public Access Unix for the '90s madd@std.com +1 617-739-WRLD 24hrs {3,12,24}00bps
mju@mudos.ann-arbor.mi.us (Marc Unangst) (11/14/89)
In article <10159@attctc.Dallas.TX.US>, chasm@attctc.Dallas.TX.US (Charles Marslett) writes: >In article <1989Nov7.185627.24105@world.std.com>, madd@world.std.com (jim frost) writes: >[With respect to allowing the owner of a file (other than root) to issue a >chown() system call] >> I'm curious as to what you do if the file is setuid; do you clear the >> setuid bit? If not, you make a huge security hole (assuming you >> care, which I do). If you've done this, please ignore. > >System V.3 (the interactive version, at least) does exactly this -- I checked >it Friday, but I forgot to see what the other bits do (sticky, et al.). I >assume setuid/setgid are the only real security holes? Well, my new version of protect.c strips off the SUID and SGID bits if the person is not the super-user. I figure that if you're root, you could always just issue another chmod() after the chown(), so it's kind of pointless to bother stripping them... Sticky really isn't a problem, for two reasons. (1) The meaning of the sticky bit is "Never swap this out, EVER. Also, keep it in core all the time, even when it's not being run." I suppose it's possible for a person to make the system unusable, especially on a 640K system, by making something like Elle sticky, and then loading it, but there's really no way to prevent this. (2) Since MINIX doesn't have swapping, the sticky bit doesn't do anything there. I'll be posting the cdiffs against stock 1.3d soon, and once I do, you can pound on it all you want. -- Marc Unangst Internet: mju@mudos.ann-arbor.mi.us UUCP : ...!uunet!sharkey!mudos!mju Fidonet : Marc Unangst of 1:120/129.0 BBS : The Starship Enterprise, 1200/2400 bps, +1 313-665-2832 ?
mju@mudos.ann-arbor.mi.us (Marc Unangst) (11/14/89)
In article <1989Nov13.192902.15473@world.std.com>, madd@world.std.com (jim frost) writes: >I honestly think chown should be a root-only; it's much simpler that >way and if a user really needs to chown a file, logging in as the >other user and using "cp" works great. If you want chown to be root-only, you don't have to apply my patches. I honostly think that they make MINIX a lot easier to use, especially if you don't have the root password. I know that if *I* was administrating a system, I sure wouldn't want to be called every time someone needed to chown a file! (Hypothetical situation: Say I need to uucp a sensitive file over to my home machine. User "uucp" needs to be able to read it, in order to send it, but I don't want to make the file readable to everyone. So, I copy it to /usr/spool/uucppublic, chmod it to mode 600, and then chown it to uucp. I tell uucp to remove the file when it's done. Now, uucp can read the file to transmit it, but no one else can. It doesn't really matter that it will end up mode 666 on my home machine, because that isn't public-access, and I'm the only one who uses it. How do you do this if you don't have access to chown?) -- Marc Unangst Internet: mju@mudos.ann-arbor.mi.us UUCP : ...!uunet!sharkey!mudos!mju Fidonet : Marc Unangst of 1:120/129.0 BBS : The Starship Enterprise, 1200/2400 bps, +1 313-665-2832 ?
peter@ficc.uu.net (Peter da Silva) (11/14/89)
In article <1989Nov13.192902.15473@world.std.com> madd@world.std.com (jim frost) writes: > image (for instance) is owned by "foo" who has no disk quota, or "bar" > who has only a megabyte. There is no way to deal with accountability. I really think that the day when disk quotas become important for MINIX is sufficiently far away that this isn't a real concern. Make it an option. > I honestly think chown should be a root-only; it's much simpler that > way and if a user really needs to chown a file, logging in as the > other user and using "cp" works great. Can't put that in a script. If you're going to start talking about security, how about backups and restorations? You want to have to make system operators root? > This is getting off the minix track, though. For sure. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>. 'U` -------------- +1 713 274 5180. "*Real* wizards don't whine about how they paid their dues" -- Quentin Johnson quent@atanasoff.cs.iastate.edu
root@cca.ucsf.edu (Systems Staff) (11/16/89)
In article <707.255F764F@mudos.ann-arbor.mi.us>, mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: > > Sticky really isn't a problem, for two reasons. (1) The meaning of > the sticky bit is "Never swap this out, EVER. Also, keep it in core ^------------------------------------------------- > all the time, even when it's not being run." I suppose it's possible ------------------------------------------^ This is not true of any version of Unix I have seen (even V6 and PWB). All it says is keep the swap space image; its use is restricted to the superusers and applies only to programs which can be re-executed from the swap image (for some systems this is all of them). Your observation (2) below is therefore the correct behaviour. > for a person to make the system unusable, especially on a 640K system, > by making something like Elle sticky, and then loading it, but there's > really no way to prevent this. (2) Since MINIX doesn't have swapping, > the sticky bit doesn't do anything there. Thos Sumner Internet: thos@cca.ucsf.edu (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos BITNET: thos@ucsfcca U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA I hear nothing in life is certain but death and taxes -- and they're working on death. #include <disclaimer.std>