See perlsec. It also contains the 5 lines of C code you need to write to get a suid-launcher for your script.
| [reply] |
I'll look into that. Just for curiosity, what exactly is the advantage over suidperl?
I understand the race condition issue, but the shell forks and calls execve() just as the wrapper code does. So, if there is anyone who can write root owned files (resp. links to them), the attack should work with the wrapper as well. Besides that an attacker who can write root owned files, would probably do something simpler than exploiting this race condition.
| [reply] |
I think at least part of the problem is that the script is setuid, and there is/was a race condition in kernels when they execute a script and then launch the (non-setuid) interpreter for (what the kernel believes to be) that script, which in turn tries again to load the script. If you are/were careful to introduce a high CPU load and launched the whole conoction through a symlink, you could readdress the symlink to point somewhere of your choosing in the time between when the kernel launched the interpreter and when the interpreter read the script to process.
Note that all my experience here is from hearsay - I've never looked into the real mechanics of various kernels.
| [reply] |