deyrau@ciba-geigy.ch (Dipl agr Veronique Eyraud) (07/28/90)
I am trying to set the SUID on a shell script. It appears beeing set with the ls command, but has no effect. Is it the case on this system that one can only SUID on programs,and not on scripts??? Thanks,
russell@CCU1.AUKUNI.AC.NZ (07/30/90)
> > I am trying to set the SUID on a shell script. > It appears beeing set with the ls command, but has no effect. > Is it the case on this system that one can only SUID on programs,and not > on scripts??? > What release of Irix are you running? I beleive that SGI have done something that affects suid on shell scripts at 3.3. This is because it is a known loophole in unix security. At 3.3 I think that it is a kernal option and that it will be removed altogether at V.4. I remember this from reading the 3.3 release notes. (We don't have 3.3 yet.) Could somebody from SGI confirm? Cheers, Russell. -- +-----------------------------------------------------------------+ | Russell Fulton 'phone +64 9 737-999 x 8955 | | Computer Centre domain rj_fulton@aukuni.ac.nz | | University of Auckland fax +64 9 303-2467 | | Private Bag time gmt -12 (13) (summer time)| | Auckland, New Zealand. | +-----------------------------------------------------------------+
olson@anchor.esd.sgi.com (Dave Olson) (07/30/90)
In <9007292052.AA21084@ccu1.aukuni.ac.nz> russell@CCU1.AUKUNI.AC.NZ writes: | > | > I am trying to set the SUID on a shell script. | > It appears beeing set with the ls command, but has no effect. | > Is it the case on this system that one can only SUID on programs,and not | > on scripts??? | > | What release of Irix are you running? I beleive that SGI have done something | that affects suid on shell scripts at 3.3. This is because it is a known | loophole in unix security. At 3.3 I think that it is a kernal option and that | it will be removed altogether at V.4. Yes, it is disabled by default as shipped, and the few shell scripts in the release that required it were rewritten or replaced by binaries. See the variable 'nosuidshells' in /usr/sysgen/master.d/kernel. As far as I know, we have no intentions of completely dropping support for setuid scripts, even if/when we pick up the V.4 features. In 3.2 setuid scripts were supported with no way to disable them. -- Dave Olson Life would be so much easier if we could just look at the source code.
fsfacca@AVELON.LERC.NASA.GOV (Tony Facca) (07/30/90)
> I am trying to set the SUID on a shell script. > It appears beeing set with the ls command, but has no effect. > Is it the case on this system that one can only SUID on programs,and not > on scripts??? In versions of IRIX prior to 3.3, you could use the "-b" switch on a C-Shell script (#! /bin/csh -b) to do this. I have read or heard that 3.3 won't allow SUID on scripts, so you'll have to use a C program with some system() calls or something to get the same results. -- ----------------------------------------------------------------------------- Tony Facca | fsfacca@avelon.lerc.nasa.gov | phone: 216-433-8318 ----------------------------------------------------------------------------- You are at Witt's end. Passages lead off in *all* directions.
guy@auspex.auspex.com (Guy Harris) (07/31/90)
>As far as I know, we have no intentions of completely dropping >support for setuid scripts, even if/when we pick up the V.4 >features. Given that S5R4 includes support for setuid scripts, complete with the "standard" fix for what is probably the most (in)famous security hole (although there may well be other holes; when you're dealing with a shell, you're dealing with a fairly big program, and there may well be, umm, *interesting* combinations of individually-reasonable features that open holes in set-UID scripts), I'd expect you wouldn't drop support for them....
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/04/90)
In article <3795@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:
] >As far as I know, we have no intentions of completely dropping
] >support for setuid scripts, even if/when we pick up the V.4
] >features.
]
] Given that S5R4 includes support for setuid scripts, complete with the
] "standard" fix for what is probably the most (in)famous security hole
...
How do you close the main hole without changing the shells themselves?
Given 3rd party shells such as bash and ksh, how do you close the hole?
What about "shells scripts" with an initial line like "#!/bin/make -f"?
(Yes, MAKEDEV is not suid.)
I'm referring to the hole caused by the shell reopening the file rather
than use the same FD that was validated by exec.c while it was parsing
#! line.
What is the "standard fix?" Does it require /dev/{stdin,fd,etc}?
Vernon Schryver
vjs@sgi.comguy@auspex.auspex.com (Guy Harris) (08/05/90)
>I'm referring to the hole caused by the shell reopening the file rather >than use the same FD that was validated by exec.c while it was parsing >#! line. > >What is the "standard fix?" Does it require /dev/{stdin,fd,etc}? The answer to the second question is "yes". The answer to the first question - as, given your second question, I'll bet you already suspected - is "for set-UID scripts, at least, open the file giving it an FD, and pass the pathname of the appropriate '/dev/fdN' entry instead of the pathname of the script to the interpreter." >How do you close the main hole without changing the shells themselves? >Given 3rd party shells such as bash and ksh, how do you close the hole? >What about "shells scripts" with an initial line like "#!/bin/make -f"? >(Yes, MAKEDEV is not suid.) If this isn't sufficient to close that particular hole, you might want to let AT&T know, *and* probably Berkeley as well if they're planning on putting it into 4.4BSD. (You might also let Dave Korn know, as he is at least one of the originators of this idea, as I remember.) (BTW, "ksh" isn't a third-party shell, at least not in S5R4....) Whether this leaves any *other* security holes, for any particular interpreter (shell-of-the-day, "make", "awk", "sed", "vi", etc.), is another question; the answer to that question is probably "yes", for many of the potential interpreters....