Re: setuid scripts

[christos%zoulas.com@localhost (Christos Zoulas)]

On Feb 14,  7:15pm, david%l8s.co.uk@localhost (David Laight) wrote:
-- Subject: Re: setuid scripts

| On Sat, Feb 14, 2009 at 06:31:36PM +0000, Christos Zoulas wrote:
| > In article <87r62158mq.fsf%inbox.ru@localhost>, Aleksej Saushev  
<asau%inbox.ru@localhost> wrote:
| > >Alan Barrett <apb%cequrux.com@localhost> writes:
| > >
| > >> On Sat, 14 Feb 2009, Aleksej Saushev wrote:
| > >>> > I think you can run setuid scripts if you build a custom kernel with
| > >>> > SETUIDSCRIPTS enabled.
| > >>> 
| > >>> Does it prevent symlink attack or simply disables the check?
| > >>
| > >> AFAIK it works properly, by passing the script to the shell using an
| > >> open file descriptor, named via /dev/fd/${number}.  I have no idea why
| > >> it's disabled by default.
| > >
| > >Any reason to keep it disabled?
| > 
| > People who write setuid shell scripts usually don't know what they are 
doing?
| 
| At least modern shells don't substitute variables before analysing
| the syntax.
| With a really old /bin/sh passing arguments like '>/etc/passwd'
| to a suid script would likely cause the password file to be deleted.
| 
| These days, provided all that almost all shell variable uses are in ""
| and that most commands use -- to ensure dubious data isn't treated
| as options (and you don't want gnu getopt() in your way either) I
| don't believe there are any attack vectors against suid scripts.
| 
| Of course, a user doesn't need read access for a suid script (unless
| they are the owner!).

And you need to sanitize the environment, specially IFS and PATH... And
who knows what other security hole you can hit by playing with stdin/out/err.


christos