Re: setgid-wrapper
On (19/05/04 15:54), Goswin von Brederlow wrote:
> Jeroen van Wolffelaar <jeroen@wolffelaar.nl> writes:
>
> > On Wed, May 19, 2004 at 07:53:46AM -0400, James Damour wrote:
> >> On Tue, 2004-05-18 at 09:03, Steven Augart wrote:
> >> > As you probably know, when a shell sees that it is running a setuid or
> >> > setgid shell script, it detects this because the euid and ruid or egid
> >> > and rgid are different. It "fixes" this by setting the euid to be the
> >> > same as the ruid, and/or egid the same as the rgid, effectively
> >> > turning off the setuid/setgid bit.
> >
> > Huh? This is wrong. It is the kernel who refuses to set the UID or GID
> > on execution of setuid/gid shell scripts.
> >
> > Where did you read that?
>
> Could it be you mean bash droping the setuid/setgid bits when it is
> set setuid/setgid? Thats a bash speciality preventing hackers to
> setuid/gid bash as so many rootkits have done in the past.
No. Bash is not dropping any of its priviledges. If you want to give
all users root access just set suid on /bin/bash ;-))
When you execute a shell script it is *not* shell that actually gets
started BUT the interpreter listed in the first line. IIRC the path
to the script is simply passes as a parameter to the whatever program
is listed in "#! /sth/bin/prog" line.
Now, you might have notices that you *can* effectively have SUID/SGID
perl scripts - if you have perl-suid installed and used in them. This
is because perl-suid binary is suid root, and when it sees a SUID/SGID
script it performs a number of checks whether it's fine to actually
run such a script, then changes euid/egid to the right values and
starts execution of the script (there are more quirks involved in
the process though).
The idea of having /etc/setuid-wrapper.d/ central database seems more
secure and less flexible than perl's approach, but honestly I am in
favor of setuid-wrapper (desired) way of doing this.
The only thing I am afraid of is that there's some quirk we can't see
and that can open a serious security hole. You should at least try
to discuss the implementation once its done (there's not much to do,
right?). Not to mention that you should be absolutely ANAL about
all standard C and general security pitfails. Would be a shame if
debian included home-made tool with security hole included.
HTH
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: