develooper Front page | perl.perl5.porters | Postings from December 2008

Re: suidperl goes

Thread Previous | Thread Next
From:
Paul Fenwick
Date:
December 22, 2008 19:25
Subject:
Re: suidperl goes
Message ID:
495059F8.1090604@perltraining.com.au
G'day Nicholas / p5p,

Executive summary: Happy for suidperl to go.

Nicholas Clark wrote:
> suidperl goes in 5.12

If I recall correctly, suidperl exists because certain operating systems[1]
when seeing a shebang line pass in the file-*name* of the script to be
executed.  This is inherently insecure, because by using symlinks and race
conditions, we can use any setuid program to launch an entirely different
program of our own choosing.  As such, on these operating systems, "scripts"
(anything that uses a shebang line) entirely ignore any setuid/setgid bits.

Operating systems that pass a /dev/fd/* filename to the script (IIRC, most
BSDs) don't have this problem, and setuid scripts work just fine.  These
good operating systems don't need suidperl, and will not mourn its passing.

suidperl exists as a user-space solution for what is fundamentally an OS
problem.  By indicating that a script should use suidperl, the perl binary
itself can check to see if any trickery is involved, and then can run the
program with additional privileges.  Unfortunately, there are a lot of
things that can go wrong, and suidperl needs to get all of them or we have
very serious security flaws.

The alternative to suidperl is a simple C wrapper, which is compiled and
marked as setuid, and which simply executes perl with a filename in a known
location (ie, not some symlink trickery).  It's simple, it's easy, it's
safe, and I could probably turn the entire thing into a command line tool.

The real beauty of suidperl is that it was easy for the user.  The C
wrapper, while incredibly safer and systemically simpler, requires a
compiler and means the file one executes is different to the file one executes.

I imagine one could actually replace suidperl with a very small amount of C,
and a configuration file (let's say /etc/suidperl.allow or
~/.perl/suidperl.allow) of authorised setuid files.  This is an easier
upgrade path for the user, since as far as they're concerned we're not
completely tossing suidperl, we're just requiring you have a config file for
it.  It's an easy path for p5p, since we're completely tossing suidperl and
replacing it with a very small C program.  It should also be easier to audit.

Given the simplicity of the C program, it could also be made independent of
perl itself, and distributed by the CPAN.  This makes things easier still.

Having said all of that, I could be completely misjudging the situation
here, so any picking holes in my thinking is greatly appreciated.

Summary: Happy for suidperl to go.

Cheerio,

	Paul

[1] "Certain operating systems" includes Linux.
[2] It could be possible to write a module that detects when we're running
setuid, but have been called as a (setuid-disabled) script, and exec's the
appropriate setuid binary.

-- 
Paul Fenwick <pjf@perltraining.com.au> | http://perltraining.com.au/
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About