suid-perl deprecated... why?

[chris-usenet]

Hi folks,

Perl 5.6.1 from debian "testing" (aka "sarge" for those who like
to know). According to debian's package installation manager, the
corresponding suid-perl is deprecated and is likely to be removed in some
(unspecified) later release.

perlsec doesn't appear to explain why it's deprecated, although it
does give the expected dire warnings about writing secure scripts,
and it offers a sample C wrapper (see the section "Security Bugs").
Google has a couple of threads from which I infer that it may be related
to a vulnerability with no-suid filesystems. However, I cannot find any
concrete details.

What's the score with perl scripts that really do need to be setuid? Do
I go back to using a C wrapper for each, or is there a supported secure
but "more elegant" solution?

This is perl. I don't want to have to go back to writing C

Thanks,
Chris

 

[Darin McBride]

Hi folks,

Perl 5.6.1 from debian "testing" (aka "sarge" for those who like
to know). According to debian's package installation manager, the
corresponding suid-perl is deprecated and is likely to be removed in some
(unspecified) later release.

perlsec doesn't appear to explain why it's deprecated, although it
does give the expected dire warnings about writing secure scripts,
and it offers a sample C wrapper (see the section "Security Bugs").
Google has a couple of threads from which I infer that it may be related
to a vulnerability with no-suid filesystems. However, I cannot find any
concrete details.

What's the score with perl scripts that really do need to be setuid? Do
I go back to using a C wrapper for each, or is there a supported secure
but "more elegant" solution?

This is perl. I don't want to have to go back to writing C

My solution:

my $apache_user = 'wwwrun';
my $apache = getpwnam($apache_user);

unless ($< == $apache->uid())
{
if ($ARGV[0])
{
print "Gotta run this as the apache user, $apache_user\n";
exit 1;
}

exec(qw(sudo -u), $apache_user, $0, qw(1));
}

And then, in /etc/sudoers, I have:
ALL ALL=(wwwrun) NOPASSWD: /path/to/my/script



This, obviously, allows any user to run this script as one specific
user, and only that specific user. Since /etc/sudoers is only writable
by root, it means that even if someone manages to hack my script, it
still can't become anyone else.

Feel free to adapt to your own situation which is probably only
tangentially similar to mine ;-)

 

[Brian McCauley]

(Sorry for the formatting - I'm having trouble with NNTP clients)

(e-mail address removed) wrote:


Perl 5.6.1 from debian "testing" (aka "sarge" for those who like
to know). According to debian's package installation manager, the
corresponding suid-perl is deprecated and is likely to be removed in some
(unspecified) later release.

perlsec doesn't appear to explain why it's deprecated, although it
does give the expected dire warnings about writing secure scripts,
and it offers a sample C wrapper (see the section "Security Bugs").
Google has a couple of threads from which I infer that it may be related
to a vulnerability with no-suid filesystems. However, I cannot find any
concrete details.


suid scripts are the subject of religious wars.

For what it's worth the the check for no-suid filesystems
(S_fd_on_nosuid_fs()) is certainly present in bleedperl and 5.8.5 and was
also in 5.6.1.

I can't say for certain it works.


What's the score with perl scripts that really do need to be setuid? Do
I go back to using a C wrapper for each, or is there a supported secure
but "more elegant" solution?


There are two ways to do suid scripts. Both are to some extent a kluge.
One is a user-space kluge the other a kernel-space kludge. I'm of the
school of thought that says a the user-space kludge is more elegant.

 

[chris-usenet]

suid scripts are the subject of religious wars.

Yes, but mostly it seems to be around the issue of whether the writer
really knows what they're doing when they (think they) want a suid script.

There are two ways to do suid scripts. Both are to some extent a kluge.
One is a user-space kluge the other a kernel-space kludge. I'm of the
school of thought that says a the user-space kludge is more elegant.

Yes, true... but as far as user space goes I see two kinds of solutions:

* the suidperl "hidden" kind of kludge (where the perl interpreter
"knows" what to do)

* the "I've got to write another wrapper, sigh" kind of kludge
(where it's possible that someone somewhere will introduce too
much complexity and therefore a security hole).

Thanks,
Chris

 

[chris-usenet]

unless ($< == $apache->uid())
{
if ($ARGV[0])
{
print "Gotta run this as the apache user, $apache_user\n";
exit 1;
}
exec(qw(sudo -u), $apache_user, $0, qw(1));
}

Why've you got the "if" round the error message? I would have thought
that it should only constrain the "exec...sudo" clause?

And then, in /etc/sudoers, I have:
ALL ALL=(wwwrun) NOPASSWD: /path/to/my/script

I quite like this kind of solution. It pushes the configuration back to
a single contained point, and leaves (most of) the security issues to
be dealt with by sudo.

Thanks,
Chris