这是（Python）脚本的安全suid /功能包装器吗？

Question

(Note: I've Linux in mind, but the problem may apply on other platforms.)

Problem: Linux doesn't do suid on #! scripts nor does it activate “Linux capabilities” on them.

Why dow we have this problem? Because during the kernel interpreter setup to run the script, an attacker may have replaced that file. How? The formerly trusted suid/capability-enabled script file may be in a directory he has control over (eg can delete the not-owned trusted file, or the file is actually a symbolic link he owns).

Proper solution: make the kernel allow suid/cap scripts if: a) it is clear that the caller has no power over the script file -or- like a couple of other operating systems do b) pass the script as /dev/fd/x, referring to the originally kernel-opened trusted file.

Answer I'm looking for: for kernels which can't do this (all Linux), I need a safe “now” solution.

What do I have in mind? A binary wrapper, which does what the kernel does not, in a safe way.

I would like to

1. hear from established wrappers for (Python) scripts that pass Linux capabilities and possibly suid from the script file to the interpreter to make them effective.
2. get comments on my wrapper proposed below

Problems with sudo : sudo is not a good wrapper, because it doesn't help the kernel to not fall for that just explained “script got replaced” trap (“man sudo” under caveats says so).

---

Proposed wrapper

• actually, I want a little program, which generates the wrapper
  • command line, eg: sudo suid_capability_wrapper ./script.py
  • script.py has already the suid bit and capabilites set (no function, just information)
• the generator suid_capability_wrapper does
  • generate C(?) source and compile
  • compile output into: default: basename script.py .py , or argument -o
  • set the wrapper owner, group, suid like script.py
  • set the permitted capabilities like script.py, ignore inheritable and effective caps
  • warn if the interpreter (eg /usr/bin/python) does not have the corresponding caps in its inheritable set (this is a system limitation: there is no way to pass on capabilites without suid-root otherwise)
• the generated code does:
  • check if file descriptors 0, 1 and 2 are open, abort otherwise (possibly add more checks for too crazy environment conditions)
  • if compiled-in target script is compiled-in with relative path, determine self's location via /proc/self/exe
  • combine own path with relative path to the script to find it
  • check if target scripts owner, group, permissions, caps, suid are still like the original (compiled-in) [this is the only non-necessary safety-check I want to include: otherwise I trust that script]
  • set the set of inherited capabilities equal to the set of permitted capabilities
  • execve() the interpreter similar to how the kernel does, but use the script-path we know, and the environment we got (the script should take care of the environment)

A bunch of notes and warnings may be printed by suid_capability_wrapper to educate the user about:

• make sure nobody can manipulate the script (eg world writable)
• be aware that suid/capabilities come from the wrapper, nothing cares about suid/xattr mounts for the script file
• the interpreter (python) is execve()ed, it will get a dirty environment from here
• it will also get the rest of the standard process environment passed through it, which is ... ... ... (read man-pages for exec to begin with)
• use #!/usr/bin/python -E to immunize the python interpreter from environment variables
• clean the environment yourself in the script or be aware that there is a lot of code you run as side-effect which does care about some of these variables

Answer 1

You don't want to use a shebang at all , on any file - you want to use a binary which invokes the Python interpreter, then tells it to start the script file for which you asked.

It needs to do three things:

• Start a Python interpreter (from a trusted path, breaking chroot jails and so on). I suggest statically linking libpython and using the CPython API for this, but it's up to you.
• Open the script file FD and atomically check that it is both suid and owned by root. Don't allow the file to be altered between the check and the execution - be careful.
• Tell CPython to execute the script from the FD you opened earlier.

This will give you a binary which will execute all owned-by-root-and-suid scripts under Python only . You only need one such program, not one per script. It's your "suidpythonrunner".

As you surmised, you must clear the environment before running Python. LD_LIBRARY_PATH is taken care of by the kernel, but PYTHONPATH could be deadly.