in reply to Future security worries?

>Where does this leave us if we wish to run perl scripts as root?

No problem. Just run them as root...

What suidperl does (used to do?) is allow you to run a script as a normal user, but with permission to do things as root. Obtaining that root permission on behalf of a normal user is exceedingly difficult to do securely.

The alternative is to use something like sudo to obtain them for you.

If you do so, you must take precautions (taint, etc.) to ensure that the program doesn't (can't) do anything naughty...

Replies are listed 'Best First'.
Re: Re: Future security worries?
by Mr_Person (Hermit) on Jun 09, 2003 at 14:39 UTC
    What security advantages does using sudo have over a plain suid program? I thought the main thing suidperl did was force taint mode on when running as root. With either approach, wouldn't you still have the danger of the user somehow escaping to a shell?
[reply]
      Some systems (e.g. Linux) do not allow suid scripts. You can set the suid bit on the file, but the system will just ignore it and run the script without switching users. The reasoning is that shell scripts are very insecure and allowing them to work results in more harm than good.

      The main thing that suidperl did was allow suid Perl scripts to work even on systems that operate this way.

      There is always the danger of a user trying to escape to a shell. That is one of the big reasons that suid shell scripts are disallowed on those systems. The idea behind taint mode is that it will help the programmer to reduce that risk by keeping track of things that come from user input. If the program never uses any input, it can't do anything unexpected (but it might not be able to do anything useful either).

[reply]
        I see, so suidperl mostly acted as a wrapper program that the operating system would allow to run suid, which in turn ran the Perl program suid that the operating system would not normally allow to run that way. But if that's the case, that doesn't sound too complicated (gellyfish was able to do that much in 5 lines of C) so why is suidperl (probably) being pulled because of its complexity? Or does it do more complicated things for other operating systems, and if that's the case, wouldn't it be a good idea to keep a simple version around for Linux-like systems?
[reply]
        Your facts are right, but the reasoning is wrong. Many Unices (including Linux) have kernel bugs that create a race condition when executing setuid scripts. These bugs allow you to start a setuid script, then quickly remove it and replace it with something else before the kernel executes it, resulting in a user being able to run anything they want on the system as whoever the script is setuid to. See Question 11 in:
        http://csrc.ncsl.nist.gov/publications/secpubs/faq-sec.txt
[reply]
Re: Re: Future security worries?
by sauoq (Abbot) on Jun 09, 2003 at 21:02 UTC
    What suidperl does (used to do?) is allow you to run a script as a normal user, but with permission to do things as root.

    Well, not exactly... suidperl provides setuid emulation. A program that is setuid runs with the privileges of the program's owner (whether the owner is root or not.) In order to provide that emulation though, suidperl itself must be setuid and owned by root...

    -sauoq
"My two cents aren't worth a dime.";
[reply]

In Section Seekers of Perl Wisdom