brwk@doc.ic.ac.uk (Bevis King) (10/11/88)
in article <10421@tekecs.TEK.COM> andrew@tekecs.TEK.COM says: >SHELLS > ... >The kernel will be able to exec shell scripts which begin with "#!". >The setuid/setgid bits for such files will be ignored. These comments nearly started a riot. Being of a "System V's ok if you add quite a lot of Berkeley bits to it" pursuasion, I had a flaming row with a Sun-freak "Berkeley is best, system V is so broken it's worse than MS-DOS". I interpretted the above to mean "setuid/setgid" shells can only be run by the default shell, and any attempt to change from that results in the setuid/setgid being ignored. Consider this example: a root shell script is written by a systems programmer who thinks tcsh is the best thing since sliced bread (NO FLAMES PLEASE - I HAVE NOT EXPRESSED AN OPINION EITHER WAY). It needs to be setuid/setgid for some reason. On most systems tcsh is in /usr/local/bin, which in many systems is publicly writable to encourage people to put their ports of PDSoft up. Someone can easily place a trojan horse in place of /usr/local/bin/tcsh and get root permission. /bin should never be publicly writable, after all thats what /usr/local/bin is all about. He believes that AT&T (or is it Sun - no can't be Sun, he worships the ground they walk on) have removed all setuid/setgid abilities from all shell scripts EVER. (PERIOD, FULL STOP, etc). Which of us is right? Am I being to kind to AT&T, and this is really broke? Or, is he just overacting because the words System V were mentioned? Tell us please, or the wars will continue... Thanks, Bevis Disclaimer: These are my views, many disagree with them, often loudly :-) Bevis King, Systems Programmer | Email: brwk@doc.ic.ac.uk Dept of Computing, Imperial College | UUCP : ..!mcvax!ukc!icdoc!brwk 180 Queens Gate, London, SW7 2BZ, UK. | Voice: +44 1 589 5111 x 5085 "Never argue with a computer" ... Avon (Blake's 7)
chris@mimsy.UUCP (Chris Torek) (10/12/88)
>in article <10421@tekecs.TEK.COM> andrew@tekecs.TEK.COM says: >>The [SVR4] kernel will be able to exec shell scripts which begin >>with "#!". The setuid/setgid bits for such files will be ignored. In article <467@gould.doc.ic.ac.uk> brwk@doc.ic.ac.uk (Bevis King) writes: >I interpretted the above to mean "setuid/setgid" shells can only be run >by the default shell, and any attempt to change from that results in the >setuid/setgid being ignored. [Someone else] believes that AT&T (or is >it Sun - no can't be Sun, he worships the ground they walk on) have >removed all setuid/setgid abilities from all shell scripts EVER. ... You are both wrong :-) It was Berkeley; AT&T and Sun will do it (did it in SunOS4.0?) for the same reason. The set-ID bits on shell scripts are always ignored. A set-ID binary can, of course, run a shell script, although the disable in 4.3BSD-tahoe makes this ugly: you have to setre[gu]id first. There is a large and nasty (but very friendly-looking) bug hiding behind set-ID shell scripts. The bug is embedded in the file system semantics. (Actually, I do know how to fix it, even under NFS, though it is not pretty, and I have never really liked set-ID scripts anyway.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
bostic@ucbvax.BERKELEY.EDU (Keith Bostic) (10/12/88)
In article <467@gould.doc.ic.ac.uk>, brwk@doc.ic.ac.uk (Bevis King) writes: > He believes that AT&T (or is it Sun - no can't be Sun, he worships the > ground they walk on) have removed all setuid/setgid abilities from all > shell scripts EVER. (PERIOD, FULL STOP, etc). The current Berkeley distribution (4.3BSD-tahoe) does not allow setuid/gid shell scripts. The Volume 1, #59 posting to the comp.bugs.4bsd.ucb-fixes newsgroup (attached) was a change to the kernel to disable them. This is because there was a security problem associated with shell scripts that we thought could only be fixed by changing the semantics of shell scripts. We have since found another method of fixing them, which will require fairly major modifications to the system, so will probably not be posted as a bug fix. Setuid/gid scripts should be available in the next BSD release. Keith Bostic ++++++++++++++++++++ Subject: setuid/setgid shell scripts are a security risk Index: sys/kern_exec.c 4.3BSD Description: Setuid/setgid shell scripts have inherent problems that may be used to violate security. These problems cannot be fixed without completely revising the semantics of executable shell scripts. Fix: Panel your office in asbestos, and apply the following patch to sys/kern_exec.c. *** kern_exec.c.orig Sun May 22 14:07:19 1988 --- kern_exec.c.new Sun May 22 14:07:55 1988 *************** *** 180,185 **** --- 180,187 ---- bcopy((caddr_t)ndp->ni_dent.d_name, (caddr_t)cfname, MAXCOMLEN); cfname[MAXCOMLEN] = '\0'; + uid = u.u_uid; + gid = u.u_gid; goto again; }
jc@minya.UUCP (John Chambers) (10/18/88)
> There is a large and nasty (but very friendly-looking) bug hiding behind > set-ID shell scripts. The bug is embedded in the file system semantics. > (Actually, I do know how to fix it, even under NFS, though it is not > pretty, and I have never really liked set-ID scripts anyway.) This is something I've been hearing for some time, and wondering when the people who understand the supposed security problem are going to enlighten the rest of us. It's not even obvious that such a claim is credible. As a null hypothesis, I'd make a fairly obvious suggestion: All programming languages are equal security risks until proven otherwise. To be more specific, I'd sure like to know what it is about the shell programming languages (Bourne, C, K, T, etc...) that make them more risky than a C program. I don't believe there's anything magical about C that makes it less a security risk than any other language. If anything, I'd give more credit to a claim that C is the dangerous one. I'm sure the the partisans of Ada, not to mention those of Pascal, Fortran, Lisp, etc., are not too happy with a claim that C programs are the only ones that can be trusted to be setu/gid. If that is the claim. Or perhaps the claim is that interpreted languages are inherently security risks. Can someone justify this one? It seems false on its face, as a setuid compiled program can always exec an interpreter, and the interpreter will then be running under the setuid permissions. Or is the suggestion perhaps to make exec*() calls change the permissions to something unspecified by the execing program? I'd be a bit surprised if this gains you anything (other than surprises for unsuspecting super-users who start up a program that looks like it is setuid to someone else (like uucp), not suspecting that it will exec a subprocess that will run as root. I can think of lots of fun things to do on a system that does this. Anyhow, enough rambling. Just what is this supposed security bug that infects setuid shell scripts but not C programs? Why are C programs more trustworthy? Or is that even the claim? Are Ada and Lisp programs equally (un)trustworthy? Can you prove it? [Yes, I know, I'm bound to get a lot of flames telling me what an incredibly ignorant idiot I am for not understanding it all without being told. Save your fingers. I've been told that lots of times before, and more insults won't smarten me up a bit. But hard information might. ;-] -- 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.]
hedrick@geneva.rutgers.edu (Charles Hedrick) (10/19/88)
There have been a series of such problems. Several of them involve setting environment variables or path to something unexpected, so that you end up with the user's version of the programs. But apparently there are worse problems than that. I can't tell you because I'm not interested enough in these things to remember them. I think the problem is that the shell isn't just a programming language. It supplies lots of builtin mechanisms. They can be used to get a different effect from the one you had in mind. It's not any one bug that has people worried, but the fact that there have been a seemingly endless stream of them. It makes people sceptical of any claims that the last problem has been fixed.
allbery@ncoast.UUCP (Brandon S. Allbery) (10/19/88)
As quoted from <467@gould.doc.ic.ac.uk> by brwk@doc.ic.ac.uk (Bevis King): +--------------- | I interpretted the above to mean "setuid/setgid" shells can only be run | by the default shell, and any attempt to change from that results in the | setuid/setgid being ignored. +--------------- Shell scripts probably -- HOPEFULLY -- cannot be suid/sgid. ALLOWING SETUID SHELL SCRIPTS IS A SECURITY HOLE. It's notable that Berkeley itself has sent out a "mandatory" BSD patch which disables setuid on "#!" executables. On the other hand, your Sun-blinded friend is probably incurable. [ 1/2 ;-) ] ++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 allbery@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct (But the aliases are NOT on UUNET yet, use the aliases at backbone sites!)
guy@auspex.UUCP (Guy Harris) (10/20/88)
>It's not even obvious that such a claim is credible.
Such a claim is credible. On most UNIX systems supporting "#!"
executables, if that system supports set-UID "#!" scripts, there exists
a program that can, given the existence of a set-UID shell script that
can be executed by user X, permit user X to run any other shell script
set-UID to that user - *regardless* of what the underlying set-UID shell
script does, or what shell it uses! The problem isn't with the language
in which the script is written, it's with the "#!" mechanism itself.
I've seen the program do precisely that.bzs@xenna (Barry Shein) (10/23/88)
>Shell scripts probably -- HOPEFULLY -- cannot be suid/sgid. ALLOWING SETUID >SHELL SCRIPTS IS A SECURITY HOLE. It's notable that Berkeley itself has >sent out a "mandatory" BSD patch which disables setuid on "#!" executables. > >++Brandon Although I fully believe that setgid/uid shell scripts are a security hole why would the kernel enforce this? All setid programs are a potential security hole and generally only very careful wizards can assure reasonable safety, no one can make security programming "user-friendly", at least not without generally castrating the system. Not allowing me to create a setid shell script seems to assume that I am a) interested in security on this particular machine (eg. my home unix system or other personal workstation only I can log into anyhow) and b) that I am too stupid (but not stupid enough) to defeat this questionable "feature" by setuiding a C program which just does a system() or other exec*() of the script. Or am I missing something here and the hole is open to non-priv'd users such that they can attain root (or similar) status even tho I, as root, have not created any setuid/setgid scripts on my system? If so then I could go along with the above fix if no reasonable workaround to that problem can be thought of. The only holes I am aware of either involve the existence of a priv'd script created by a priv'd user or remote file system hacking which is just as open to any programming, not just shell scripts. -Barry Shein, ||Encore||
sane@brutus.cs.uiuc.edu (Aamod Sane) (11/27/89)
I would like to have detailed specs of System V Release 4. I have heard all sorts of stuff, like it treats processes as files, has lightweight processes etc. Is there a final/semi-final document? Please mail/post any article name, specs, or contact address for inquiry. Thanks , Aamod Sane sane@cs.uiuc.edu Dept. of Comp. Sc. 1304 W. Springfield, University of Illinois at Urbana Champaign, Urbana IL 61801.
taylor@ncrcae.Columbia.NCR.COM (Mildred Taylor) (04/21/91)
Under Unix System V.4 (NCR System 3000), directories with names such as /00, /01, /02, etc. are removed when the system is rebooted. This occurs even with files below those directories. Directories such as /01dirone, /02dirtwo, etc are not removed. Does anyone know at what point the system removes these directories and how this could be prevented? Please send email to taylor@ncrcae.Columbia.NCR.COM Thanks A Bunch! Mil