lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (02/02/90)
In article <JV.90Jan31134044@mhres.mh.nl> jv@mh.nl (Johan Vromans) writes:
:
: 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.
Larrypvo3366@sapphire.OCE.ORST.EDU (Paul O'Neill) (02/04/90)
In perl man page lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: > ...... 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 <6940@jpl-devvax.JPL.NASA.GOV> lwall@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. Paul O'Neill pvo@oce.orst.edu Coastal Imaging Lab OSU--Oceanography Corvallis, OR 97331 503-754-3251
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (02/07/90)
In article <15475@orstcs.CS.ORST.EDU> pvo3366@sapphire.OCE.ORST.EDU (Paul O'Neill) writes: : In perl man page lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: : : > ...... 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 <6940@jpl-devvax.JPL.NASA.GOV> lwall@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? 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