suidperl & taintperl
Paul O'Neill
gonna' do it. :-)
Just what are suidperl and taintperl?
I'm kinda' understanding the 'Setuid Scripts' discussion in the man page,
but is this the behavior of perl, suidperl, or taintperl?
When does one use suidperl or taintperl?
Do they go on the #! line of your script?
Did I miss something in the docs? Is there something missing in the docs?
Thanks.
Paul O'Neill p...@oce.orst.edu
Coastal Imaging Lab
OSU--Oceanography
Corvallis, OR 97331 503-754-3251
Larry Wall
: Just what are suidperl and taintperl?
taintperl is normal perl plus the taint checks. They're a little bit more
overhead, which is the only reason normal perl doesn't do them.
suidperl has the taintchecks plus a mechanism for emulating setuid
scripts on machine where setuid scripts have been disabled in the kernel.
It is useless unless they have been disabled.
Hence, taintperl runs with normal permissions, and suidperl runs setuid
root so as to be able to setuid to the owner of the script. And suidperl
has some extra checks to make sure the script it's executing is in fact
the script that you wanted to execute.
: When does one use suidperl or taintperl?
One doesn't use them directly, in general. Normal perl detects whether
a script is running set[ug]id, or wants to run set[ug]id, and calls
taintperl or suidperl automatically.
The only time you might want to use taintperl directly is if you are going
to make a dumped/undumped version of a script that is going to be running
setuid, but is not running setuid when you do the dump.
I can't think of any reason for using suidperl directly.
: Do they go on the #! line of your script?
Generally not.
: Did I miss something in the docs? Is there something missing in the docs?
Let's say the docs present a simplified view of reality... :-)
Larry
Johan Vromans
In article <69...@jpl-devvax.JPL.NASA.GOV> lw...@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
> taintperl is normal perl plus the taint checks. [...]
> suidperl has the taintchecks plus a mechanism for emulating setuid
> scripts on machine where setuid scripts have been disabled in the kernel.
> One doesn't use them directly, in general. Normal perl detects whether
> a script is running set[ug]id, or wants to run set[ug]id, and calls
> taintperl or suidperl automatically.
This leads me to the opinion that
1. Taintperl and suidperl could be combined. If setuid root it is
suidperl, taintperl otherwise.
2. They (it?) could be placed in the perl library instead of the
'public path'.
Johan
--
Johan Vromans j...@mh.nl via internet backbones
Multihouse Automatisering bv uucp: ..!{uunet,hp4nl}!mh.nl!jv
Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62944/62500
------------------------ "Arms are made for hugging" -------------------------
Larry Wall
:
: 1. Taintperl and suidperl could be combined. If setuid root it is
: suidperl, taintperl otherwise.
Close, but not quite. It's possible to have a system that needs suidperl
to be setuid root, but taintperl to not be setuid root because there
are still "wrapped" perl scripts, and running the setuid root suidperl would
destroy the current effective id.
: 2. They (it?) could be placed in the perl library instead of the
: 'public path'.
That's certainly a possibility.
Larry
Paul O'Neill
> ...... If the kernel feature isn't disabled,
> perl will complain loudly that your setuid script is
> insecure.
It sure does:-)
YOU HAVEN'T DISABLED SET-ID SCRIPTS IN THE KERNEL YET!
FIX YOUR KERNEL, PUT A C WRAPPER AROUND THIS SCRIPT, OR USE -u AND UNDUMP!
How does this increase security of suid/sgid perl scripts?
In article <69...@jpl-devvax.JPL.NASA.GOV> lw...@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes:
>
> ...... Normal perl detects whether
> a script is running set[ug]id, or wants to run set[ug]id, and calls
> taintperl or suidperl automatically.
So, since perl is going to feed your suid perl script to taintperl to
do lots of testing for dumb mistakes, why does it care that your kernel
would allow csh or sh to interpret dumb csh or sh suid scripts?
> suidperl has the taintchecks plus a mechanism for emulating setuid
> scripts on machine where setuid scripts have been disabled in the kernel
> It is useless unless they have been disabled.
^^^^^^^^^^^^
> I can't think of any reason for using suidperl directly.
I found a great use for suidperl. I invoke it directly on my suid perl
script, or start the suid perl script with the line:
#!/usr/local/bin/suidperl
And the loud complaining about the kernel patch goes away!!
(Now I get to see all the loud complaining about insecure paths, etc.,
neat stuff.) Is this a nasty that should be fixed? If so, why? Am I
asking for trouble doing this w/o the kernel patches? Can I still
consider my "perl script ... more secure than the corresponding C program"?
PS -- any pointers to how this kernel patching is done on assorted Sun's
at 4.0.x and NeXT's would be greatly appreciated.
Larry Wall
Possibly. It is certainly the case that if you put a setuid root csh or sh
script on your system, and give me a normal account on your system, I could
have root privs within about 2 minutes of the time I find the script.
: If so, why? Am I asking for trouble doing this w/o the kernel patches?
Possibly, especially if you machine doesn't support setreuid(). The problem
is that, because of the aliasing possible with links, there is no way to
guarantee that the script opened by the interpreter is in fact the same
one that the kernel examined and granted setuid privs to.
Now suidperl goes to great lengths to assure that the script you are
executing is a set-id script, and that the arguments passed on the command
line correspond to the #! line, but it can't assure that it is the same
script that the kernel execed. If you have setreuid(), suidperl can
swap uid and euid and check that it isn't giving away any privs that
the kernel wouldn't give away. If you don't, perl can only use access
to check the directory permissions, which is known to have race conditions.
(Though perl uses fstat to test the file permissions itself.) So suidperl
won't let you run a script that's protected against you, and it won't
let you run set-id to anything other than what the script itself is set
to, but it can let you run a script in a directory that you don't have
access to ordinarily, if you don't have setreuid().
A worse problem is if you decide to bypass the loud message by invoking
taintperl rather than suidperl. This also bypasses the checks, because
taintperl will assume that it is running a wrapped script. In this case,
a setuid perl script is as bad as a setuid shell script--basically gives
away the farm.
A factor contributing to this is that if setuid is really working, and the
uid of the script is not root, then the script uid overrides the suidperl
uid, and suidperl will note that it is not running as root, and exit. So
your trick only works on setuid root programs. This might tempt you on
non-root setuid scripts to use taintperl instead, but that's a losing
solution, as pointed out in the previous paragraph.
: Can I still
: consider my "perl script ... more secure than the corresponding C program"?
Maybe. If you have setreuid(), it probably is. But I'm not going to
guarantee it if you haven't disabled set-id scripts in the kernel.
: PS -- any pointers to how this kernel patching is done on assorted Sun's
: at 4.0.x and NeXT's would be greatly appreciated.
I've done it on a Vax by just changing a branch, but on Suns it's harder
because (at least in 3.5) you'd have to insert instructions, and I never
bothered. I just use a C wrapper. Sun was no help--they basically ignored
the patch that Berkeley sent out for the problem. But if 1000 people all
ask for the patch, perhaps controlled by a adbable variable, they might
reconsider...
Larry