ernest@pegasus.dsg.tandem.com (Ernest Hua) (03/03/91)
-------------------------------------------------------------------------------
Actually the real question is:
Should the Unix kernel refuse to execute binaries (or scripts) that are ...
1. setuid-ed plus group and/or world writable?
2. setgid-ed plus world writable?
It seems like a simple check that should be help ensure a more secure Unix.
Please E-mail replies and I will post a summary.
-------------------------------------------------------------------------------
Ernest Hua
Tandem Computers
ernest@tandem.com
408-285-5580rcd@ico.isc.com (Dick Dunn) (03/03/91)
ernest@pegasus.dsg.tandem.com (Ernest Hua) writes: > Should the Unix kernel refuse to execute binaries (or scripts) that are ... > 1. setuid-ed plus group and/or world writable? > 2. setgid-ed plus world writable? I see two levels at which the answer ought to be "no". 1. The pedantic rote answer is "no, because the kernel isn't supposed to be in the business of making [that sort of] policy decision." 2. A practical answer is "no, because the situation is more complicated than that." The restrictions required to keep the least experienced users from hurting themselves may be more than the most experienced users want to put up with. As an example, I had for some time a root-owned 4777 executable, quite intentionally. It was useful because it was a program I was frequently rebuilding and testing, on my own workstation. Having it globally writable allowed the make to toss the executable where I wanted it, ready to run without the su/chown/chmod, and without killing the make the next time around if I forgot to move the file or change it back. The machine is only accessible to a few people, and even beyond that the file was within a 700 directory of mine. Depending on administrative domains and policies, you can probably come up with reasonable uses for group-writable setuid--just assume that the members of the group have to trust one another and/or the result uid is a pseudo-user representing the group. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...But is it art?
sef@kithrup.COM (Sean Eric Fagan) (03/03/91)
In article <1991Mar2.193639.21105@tandem.com> ernest@pegasus.dsg.tandem.com (Ernest Hua) writes: >Should the Unix kernel refuse to execute binaries (or scripts) that are ... > 1. setuid-ed plus group and/or world writable? > 2. setgid-ed plus world writable? >It seems like a simple check that should be help ensure a more secure Unix. What appears to be done more often is to have writes clear the SUID and/or SGID bits (unless the writer is root or the owner?). Even that one I have problems with. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
mike (03/03/91)
In an article, ico.isc.com!rcd (Dick Dunn) writes: |ernest@pegasus.dsg.tandem.com (Ernest Hua) writes: || Should the Unix kernel refuse to execute binaries (or scripts) that are ... || 1. setuid-ed plus group and/or world writable? || 2. setgid-ed plus world writable? | |I see two levels at which the answer ought to be "no". |1. The pedantic rote answer is "no, because the kernel isn't supposed to | be in the business of making [that sort of] policy decision." |2. A practical answer is "no, because the situation is more complicated | than that." The restrictions required to keep the least experienced | users from hurting themselves may be more than the most experienced | users want to put up with. Good points. Another reason that I would avoid this restriction is because some developers (keeping myself in mind, primarily :-) like to modify the executable itself for various and sundry purposes. -- Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- Remember folks: If you can't flame MS-DOS, then what _can_ you flame?
emv@ox.com (Ed Vielmetti) (03/03/91)
would this increase the risk of denial of service attacks, or accidental disaster? consider if /etc/rc is world writable and you couldn't boot... --Ed
bzs@world.std.com (Barry Shein) (03/04/91)
Any writeable, public executable is a hazard, most users consider
their own files valuable and such executables are a hazard to them as
they run with their own privs. It's somewhat admin-o-centric to think
there's something special about setuid/setgid, just a different form
of damage possible (and system disruption is fairly possible from even
non-priv'd accounts, for example a hacked program which fills /tmp.)
The only idea that comes to mind would be something analogous to the
umask() indicating which bits can and cannot be set on an executable,
tho I suspect some thought will reveal that the problem is more subtle
than that, but something like xmask(022) might help.
--
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD