skx has asked for the wisdom of the Perl Monks concerning the following question:

 I've just seen the following snippet in perldelta:

 o   After years of trying, suidperl is considered to be too complex to
     ever be considered truly secure.  The suidperl functionality is
     likely to be removed in a future release.

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

Steve
---
steve.org.uk

Replies are listed 'Best First'.
Re: Future security worries?
by ctilmes (Vicar) on Jun 09, 2003 at 12:11 UTC
    >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...

      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?
        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).

      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.";
      
Re: Future security worries?
by gellyfish (Monsignor) on Jun 09, 2003 at 15:04 UTC
    Just to add to the other comment. suidperl was only necessary on platforms where (secure) setuid scripts were not available so it is possible that you would have not needed it in the first place. If you do not have setuid scripts on your system then an alternative to suidperl (or indeed sudo ) would be to use a small C wrapper like:
    #include <unistd.h> int main( int argc, char **argv) { execv("./foo.pl", argv); }
    and make the executable setuid as appropriate. I would, however, be cautious using the above code lest you should unintentionally allow someone to run any program on the system as root: you would want to be absolutely sure that no-one would be able to replace the code of "foo.pl" with something unintended as the very first thing. You should also ensure that any program thus wrapped has taint mode on with the '-T' on the shebang line.
    /J\