[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: setgid-wrapper



> Now I know why I had such trouble getting setuid programs to work
> on Linux.
> 
> My understanding of Greg and Jeroen's explanations is that the kernel
> ignores whether an interpreted program has the setuid bit set -- it
> just executes the interpreter given after the #!, passing the full
> pathname of the file containing interpreted program as the first argument.
> If the interpreter wants to then go ahead and look at the setuid or
> setgid bits on the file it was given as the first argument, the way
> perl and suidperl do, that's the interpreter's business.

This has not always been like that.  I looked at the issue of suid/sgid
shell scripts before and there were some patches (in times of 2.0.x
kernles) to enable it.  BUT this functionality is not present for a good
reason: shell scripts are inherently unsafe!

I'd say that for a SUID/SGID *shell* script taking any untrusted
parameters is serious security hazard.  It is not an issue for game
wrappers that basically just start the game passing to it all parameters
as they were given by the caller.  But writing anything more advanced
in suid/sgid shell is just asking for serious (security) troubles.

In setid-wrapper package there should be *BIG* warning about it, possibly
in more than one place.

> >Should we
> >pass the concept by Debian Security first?
> 
> I like Greg Prokopski's idea of writing the code first,

It doesn't seem big enough to be worth discussing w/o code in place
first.

If you were to actually write such universal wrapper, then I think
it'd make sense to allow for suids too. So the config file would
consist of lines more less like that:

/usr/bin/my_game   .games     /usr/lib/my_game/bin/game
/usr/bin/my_util   root.root  /usr/lib/my_util/util

BTW: your wrapper should also check whether the user who claims
to have ran your wrapper actually has *execution rights* to it!
One could play an ld.so trick and execute it (AFAIR).  There's
probably more security concerns.  You should see perl-suid sources.

Cheers,

			Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski <gadek@debian.org>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM



Reply to: