Linux – program needs to be run as root by any user and can be located anywhere

Requiring dual approval for certain actions is part of some security policies; for example:

• In banking, very large transactions typically require validation by two managers.
• Launching heavy weapons such as nukes requires validations by two or more high-ranking officers or decision-makers.
• Approving or rejecting a suggested edit on Stack Overflow requires two users with sufficient reputation to agree.

You'll note that this is not about authentication (e.g. typing a password to show that you're who you pretend to be), but about authorization, i.e. deciding whether a certain action is permitted.

For background reading, I recommend Security Engineering by Ross Anderson. Buy the latest edition if you can, but otherwise the first edition is available online. The most relevant chapter is “Access Control”; there are examples in the chapters on banking and nuclear command.

Unix offers a simple security model, with only two levels: user and superuser. This is both a strength (simple means less room for errors in the design and implementation of the system itself and of security policies) and a weakness (complex security policies cannot be expressed natively). If you're worried about a rogue user gaining root, don't give him root permissions. There are very few checks on what root does; the only constraint would be that the action of gaining root can be logged remotely, as can certain external actions (network traffic). A rogue user could pretend to want to gain root to do a certain thing and actually do another while hiding his actions from the other user. So you would not gain much security by requiring root access to be vetted by another user. Conversely, you would lose security by reducing the availability of root access (I gather you want to give less trusted users root access to serve as back-ups if something goes wrong; dual approval would increase the burden a lot).

Dual approval is useful for specific actions: Alice says “please authorize me do do X”, Bob says “I authorize Alice to do X”, and the system performs X (X can be e.g. transferring $1,000,000,000 from one bank account to another, or nuking Moscow, or rejecting an edit). If Alice says “please authorize me to do anything I want” and Bob agrees, all Bob is doing is echoing what you (the policy maker) already said, namely that Alice can be authorized to do anything. You might as well make Alice a sudoer.

I don't know of any existing system on unix to have multiple users approve specific commands in a sudo-like framework.

The only bug I see with your code is that you're running the user's command unnecessarily through sh -c when you should just run it directly. Running it through sh -c buys you nothing but it destroys quoting that the user originally put into the command. For example, try this:

sudo /usr/local/sbin/_oob_shim ls -l "a b"

should list a file called a b inside the context of the namespace but instead it lists two files called a and b.

sudo /usr/local/sbin/_oob_shim ls -l "*"

should list a file called * (literal asterisk), fails for the same reason.

So it should look like this instead:

#!/bin/sh
/bin/ip netns exec oob \
    /usr/bin/sudo -u "#$SUDO_UID" -g "#$SUDO_GID" -- "$@"

Makes the script simpler to boot!

Another point I can make is that although in this case the bug was just a functionality bug, not a security bug, one is always suspicious when auditing security-sensitive code and finding that it runs things through shells because that's almost always a problem.

Finally, the user's supplementary groups will not be propagated into the namespace (they get only their uid and main gid), but that doesn't seem like a huge problem and fixing that is not trivial.

Other than that, it looks good to me.