Re: Getting perl code to run sgid
> I get the distinct impression, based on `perldoc perlsec` that perl
> is smart enough to detect and circumvent the relevant
> vulnerabilities:
> on many
> versions of Unix, set-id scripts are inherently insecure
> right from the start. The problem is a race condition in
> the kernel.
This race condition in the kernel effectively prevents any user space
program's ability to work around this. First it depends on the
kernel, of course. It happens before perl is run. Therefore if I can
trigger the condition I avoid running perl at all. And since the
cracker is the one seeing the perl diagnostics in the case that the
race condition is going the other way, I in the role of cracker can
run in a loop, ingore perl's warnings, keep running until I trigger
the race condition the way I want and then stop. Usually I need to
load the system down before I can get the race to fall the other way
so it takes a while.
> However, if the kernel set-id script feature isn't
> disabled, Perl will complain loudly that your set-id
> script is insecure.
I think this means that perl is saying that if your kernel allows this
problem to exist that it will prevent a user from thinking that it is
a good thing by complaining. Which means that if you are not seeing
this message then you are on a system which is okay. Which is true
enough. But since I am always porting code I hate running into system
specific hacks like that.
> No disagreement with respect to s[ug]id shell scripts, though.
Agreed. Personally I usually create a C program wrapper to clean the
environment and invoke the shell script. But using sudo is probably
better.
Bob
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: