[gentoo-dev] Re: Re: Re: Looking for alternative to RESTRICT=userpriv

[Steven J. Long]

On Mon, Sep 29, 2014, Zac Medico wrote:
> On 09/28/2014, Steven J. Long wrote:
> > On Wed, Sep 24, 2014, Zac Medico wrote:
> >> The environment doesn't necessarily have to be isolated, since we could
> >> extend the existing environment saving/loading support to be used for by
> >> esudo. The steps to implement the shared environment could be as follows:
> >>
> >> 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.

> > Other than that, I agree esudo is the best approach, and gives us
> > much better granularity over privilege escalation, as discussed in
> > the bug.
>
> Yeah, me too.

Cool, glad we're on same page.

> > Part of me thinks though, that it'd be much cleaner to give the
> > portage user access to sudo. Isn't that effectively the purpose
> > of the "suid helper"? In which case we get all the options for
> > env etc, of sudo, and the admin gets to configure it along with
> > the normal wheel setup.
>
> Depending on our goals, using sudo may or may not have advantages. It.
> really depends on whether or not we want esudo to interact with the
> local sudo configuration. If we want it to be independent of the local
> sudo configuration, then it makes sense for the package manager to use
> it's own privilege escalation mechanism.

IDK; "independent of the local sudo configuration" /sounds/ good, but
what we are talking about is the configuration for *one* user, that to
run the package manager at the heart of our distro. Speaking as a uadmin
(a Gentoo user who's a defacto admin, not what I think of as an "admin",
which would be a net-admin) I'd much rather configure that in the same
place I configure everything else.

It's not like I don't see the portage user in /etc/passwd et al, or it's
little-known. We set perms for it on /var/tmp/portage so that userpriv
can work, at least we did last time I set that up. /usr/portage is
set like that too, here. 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.

AFAICT functional wrapping can be used for the capability side, but
I'd be interested to read otherwise, ie the ins and outs of why not.

Regards,
igli
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)