I think you're looking at it backward. Elevation to root already lets you escape those things if you try (and for seccomp, keeping it is not even an option). OTOH if the program running suid doesn't make effort to escape whatever mess it inherited from before exec...
Conversation
...all of these things potentially alter its behavior in ways that could become exploitable. For example, by setting ulimits you can make a particular malloc or open call fail.
2
2
what rich said. using a daemon is *actually* the proper UNIX way of doing this, and has no drawbacks from security POV over using an SUID. only benefits, really.
1
3
I'm not starting to discuss the UNIX philosophy. Suid is the result of a shortcoming of this model just as having an intermediate deamon is. Both approaches have pros and cons, as already stated. We only disagree about the impact of the properties.
1
1
My main problem is, that the child process implicitly loses the context of the parent. Think of an environment where you work with network namespaces, you want to change the UID, but implicitly change the network context.
1
1
use the appropriate tools for that, `ip vrf exec` or `unshare` :p
1
Sure, there are ways to reconstruct the process state manually, but the fact that you need to do that requires knowledge about implicit behavior of the system.
1
I'm not saying the daemon approach is fundamentally flawed, but it changes many assumptions that have been established with sudo. And if it's about creating a replacement for sudo, please consider those instead of telling me how my opinion doesn't matter.
1
1
i should clarify: this is about creating a replacement for typical usecases of sudo, for use in the alpine base system. this is not about enabling all possible usecases that sudo allows.
1
alpine is not planning to remove sudo because it is known that creating a 100% replacement is not possible.
2
sshd with a restricted shell is essentially already an implementation of this. The concept of a restricted shell is the same very flawed approach as sudo policy and can have the same kind of logging.
You can make sshd listen on a Unix socket via the inherited fd support.
yes, but the ergonomics of doing it that way are somewhat problematic :p
2
It's pretty easy to wrap into something useful. I just don't think the whole restricted shell or sudo policy concept is a good idea.
Main usage of sudo is simply to delegate full access to an account in which case you might as well just add that SSH key to the authorized_keys.
2
Show replies
Came here to say this. 👆 sshd already does it all and already has an impenetrable authentication system.
1
It even solves the tty problem for interactive commands.