On 10/02/2014 07:32 PM, Steven J. Long wrote: > On Tue, Sep 30, 2014 at 07:52:02AM -0700, Zac Medico wrote: >> On 09/29/2014 04:31 PM, Steven J. Long wrote: >>> On Mon, Sep 29, 2014, Zac Medico wrote: >>>> On 09/28/2014, Steven J. Long wrote: >>>>> On Wed, Sep 24, 2014, Zac Medico wrote: >>>>>> 1) When esudo is called, it saves the current (unprivileged) bash >>>>>> environment to a file. >>>>>> >>>>>> 2) esudo uses IPC to request that a process with elevated privileges be >>>>>> launched to run a specific command using the saved environment, and that >>>>>> the environment of the elevated process be saved to a file after the >>>>>> command completes. >>>>> >>>>> I don't think it's going to be quite that easy to get the output env, >>>>> certainly not from some random command; tbh I don't even see the need >>>>> for it, unless I'm missing something. From the "elevated process" after >>>>> it waits on the child, but not from the child unless you control the >>>>> code. >>>> >>>> We control the shell code that launches the requested command, so we can >>>> save the environment after the requested command completes (using a >>>> modified version of our existing environment persistence code). >>> >>> Yeah but think it through; the "elevated process" inherits its environment >>> from us (current state, as normal). It runs a child process: nothing in the >>> env of that child is going to affect our env, by definition. The command >>> completes, and we save back the same env we started with. >>> >>> Sure, the child inherits its env from us, but we don't need to do anything >>> to make that happen: it's standard. In fact we take efforts to clean the >>> env in some situations for that reason. >>> >>> I just can't see it working, apart from perhaps where a command outputs >>> settings which should be run through eval. In which case, eval them >>> in ebuild space after the command has output whatever under esudo. To >>> be flexible, you're going to want to save them anyway for later use, >>> which again implies that happening in the ebuild/eclass. >> >> You're thinking in terms of a SUID helper like sudo. The implementation >> that I've been suggesting does not involve a SUID helper. > > No, I'm thinking in terms of "a process with elevated privileges" running > "a specific command"; whether that first process is started by us or not, > is irrelevant to whether it can get the environment from a child process > we have no control over, after it "completes".
You're assuming that we have no control over the child process, which would be true with a SUID helper like sudo (in the absence of a wrapper script, see below) that is only designed to run a specific command and then exit without saving the enviroment. However, imagine a helper that is designed to run a requested shell command and then save the environment before it exits. It could be done with sudo if you simply required that the first argument to sudo be a wrapper script that executes the requested command and then saves the environment. For example, consider the following usage: sudo /foo/bar/wrapper.sh <requested shell command with arguments> If the sudo command is constructed shown above, then wrapper.sh can load an arbitrary environment, execute the requested shell command with arguments, and then save the resulting environment afterwards. > Sure it can save its own, but since it's a generic "run any command" helper, > it can't do much more than give us back what we gave it, unless you're > talking about echoing back settings, in the manner of gpg et al, which > by definition is not about the saved env. That's why we have to use that > format in the first place; because the env setting must be done by the > process which wants to use it (have it inherited for child processes), > for the same reason: a child process can never affect the parent env. We could implement esudo so that it will insert wrapper.sh into the sudo arguments, so that the caller doesn't have to know anything about the wrapper.sh implementation details. For example: esudo <requested shell command with arguments> So, the privilege escalation mechanism is indeed irrelevant, as long as there's some opportunity to insert a wrapper script that runs with escalated privileges, allowing it to load/save the environment at the appropriate time during shell execution. >> Instead, IPC >> would be used to request that the privileged parent process launch a new >> privileged process on behalf of esudo. In this context, unless the esudo >> implementation provides explicit support for environment inheritance, >> the new privileged process will not inherit any environment from the >> environment where esudo was called. > > Well, assuming that were the implementation, that explains why you'd want > to save the env off, so that the privileged helper can access it. It still > sounds like more work in the long run in terms of what's happening, but > regardless: it doesn't get you the resultant env from the child command. Except that it is possible to save the resultant env from the child command, using a wrapper as described above. > But like I said, that's of dubious utility in any case. I think we should > just forget about it. It may have dubious utility, but it's still possible, nonetheless. >>> So we already have to deal with the user part of userpriv, as admins. >>> >>> On the implementation side, it makes a lot of sense: we delegate the >>> worry to a package used cross-distro for this specific purpose. In fact >>> this conversation has made me understand ubuntu a bit more, where I >>> always used to smile at the overuse of sudo. I certainly wouldn't >>> want the implementation headache of maintaining a secure clone. >> >> The IPC implementation that I've suggested does not involve an SUID >> helper, so it is much more secure. Security would rely on the permission >> bits of the named pipes that are used to implement IPC. > > I see, so presumably there's a fifo pair, that only the portage user can > access (likely at dir level too), one read-only? On the other end of which > you have a waiting process, ie a daemon, in the classic sense, with root > privilege, so it can run any command as any user, with any set of caps > required. If you're using IPC to request a process with privilege be > launched, something's got to be listening to the other end. Yes, this is how ebuild helpers like has_version and best_version already work. The IPC system can easily be extended to handle privilege escalation commands. > I don't see how that's "more secure", but then I don't really care how you > implement it, either ;) It's certainly less deps, I guess. Well, a named pipe that is only readable/writable by a specific user is inherently more secure that a SUID binary that can be executed by any user. > It still just sounds like a reimpl of sudo, by an indirect method (root > userland daemon, as opposed to kernel suid) leading to a lot more going > on at runtime (env saving to file, reloading in a new child process > from the privileged daemon, before we can start the actual command.) Well, the daemon is already there listening for commands such as has_version and best_version. Extending it to handle privilege escalation would be fairly easy. The overhead involved is negligible. For things like has_version and best_version, the daemon approach is actually much more efficient than the alternatives, since the daemon has access to relatively long-lived database instances that would otherwise have to be instantiated for each has_version/best_version call. > And as above, it cannot get us the env after randomcmd completes, but > that's orthogonal, since nothing can, and programs aren't written > to output to their env, since the parent can't access it. Again, a wrapper script like wrapper.sh described above would have access to the resultant env. > I assume you have code in mind for this already, perhaps from another > project? If so, and it's a reasonable maintenance burden, ie not > much needs to change once it's up and running correctly, then fair > enough. What I have in mind is the existing IPC system that portage already uses to implement commands like has_version and best_version. > Though from what I've seen even Linux-specific projects just > exec the command, after setting privileges, namespace etc as > appropriate, from a suid helper. An SUID helper would certainly work. However, given the existing IPC infrastructure, I would use IPC. > Are you sure you don't want to borrow someone else's code for a suid > helper instead? Not sure what a daemon buys you, apart from extra > maintenance overhead (listener, loading env, as well as what a suid > helper would do, and a protocol for communication, which no doubt is > going to change over time) plus an attack vector for someone who can > crack portage or python at any future point, or just get portage uid > via some other vector; for a relatively infrequent operation. The portage user/group is already a possible attack vector: https://bugs.gentoo.org/show_bug.cgi?id=149062 For this reason, it's very important not to grant access to this user/group to untrusted users. -- Thanks, Zac
