in reply to Re: Not understanding the code to drop privileges in perlsec
in thread Not understanding the code to drop privileges in perlsec

Thank you very much for the in-depth explanation.

I have to apologize that I left out the use English; statement at the begin of the example code. Of course, it is in my test program :-) It fell off the table during copy-and-paste.

I also would like to state that my test scenario works. For example, when I make the script setuid-root at the file system level, then log in as a normal user with user id 1016 and execute the script, $EUID is 0 and $UID is 1016 at the beginning (before executing line 4).

It also works if I make the script setuid-<user with id 1015>, log in with user id 1016 and run the script. Then $EUID is 1015 and $UID is 1016 at the beginning (before executing line 4).

With another scenario, I have found a bug in the meantime (I can't judge if Perl or if the script is the culprit). I'll describe it in a separate post below.

Hoping to gain some deeper understanding, I have studied the man pages of the library functions you mentioned. But I seem to be blind: I still can't understand the sense of lines 7 and 8. They would only make any sense if the assignments in lines 4 and 5 would change not only the left hand side, but also the right hand side.

IMHO, dropping privileges actually happens in lines 4 and 5, not in lines 7 and 8 as the comment implies. What lines 7 and 8 do will probably remain the author's secret.

Anyway, due to the bug I have found, I am unsure whether I should trust that script at all. Too sad that it's just perlsec that shows a buggy and totally incomprehensible script as reference for how to securely drop privileges.

Replies are listed 'Best First'.
Re^3: Not understanding the code to drop privileges in perlsec
by NERDVANA (Priest) on Feb 24, 2024 at 06:05 UTC
    if I make the script setuid-<user with id 1015>, log in with user id 1016 and run the script

    My understanding of the setuid situation is that the only safe way to actually make a script setuid is to not do that, and use the sudo tool. setuid with a scripting language has a much larger attack surface due to the interpreter using various environment variables like 'PERL5OPT' that the linux loader won't be aware of (it has some protections for LD_LIBRARY_PATH, but it can't know about much more than that) Making something setuid without opening up the ability to run arbitrary code as the other user is fairly difficult. sudo helps with this by sanitizing the environment before the script interpreter gets invoked.

    Maybe this is what you meant elsewhere by "the right way to make a script setuid" but I didn't see any mention of sudo, so I figured I'd warn you at least.