1 |
On 09/29/2014 04:31 PM, Steven J. Long wrote: |
2 |
> On Mon, Sep 29, 2014, Zac Medico wrote: |
3 |
>> On 09/28/2014, Steven J. Long wrote: |
4 |
>>> On Wed, Sep 24, 2014, Zac Medico wrote: |
5 |
>>>> The environment doesn't necessarily have to be isolated, since we could |
6 |
>>>> extend the existing environment saving/loading support to be used for by |
7 |
>>>> esudo. The steps to implement the shared environment could be as follows: |
8 |
>>>> |
9 |
>>>> 1) When esudo is called, it saves the current (unprivileged) bash |
10 |
>>>> environment to a file. |
11 |
>>>> |
12 |
>>>> 2) esudo uses IPC to request that a process with elevated privileges be |
13 |
>>>> launched to run a specific command using the saved environment, and that |
14 |
>>>> the environment of the elevated process be saved to a file after the |
15 |
>>>> command completes. |
16 |
>>> |
17 |
>>> I don't think it's going to be quite that easy to get the output env, |
18 |
>>> certainly not from some random command; tbh I don't even see the need |
19 |
>>> for it, unless I'm missing something. From the "elevated process" after |
20 |
>>> it waits on the child, but not from the child unless you control the |
21 |
>>> code. |
22 |
>> |
23 |
>> We control the shell code that launches the requested command, so we can |
24 |
>> save the environment after the requested command completes (using a |
25 |
>> modified version of our existing environment persistence code). |
26 |
> |
27 |
> Yeah but think it through; the "elevated process" inherits its environment |
28 |
> from us (current state, as normal). It runs a child process: nothing in the |
29 |
> env of that child is going to affect our env, by definition. The command |
30 |
> completes, and we save back the same env we started with. |
31 |
> |
32 |
> Sure, the child inherits its env from us, but we don't need to do anything |
33 |
> to make that happen: it's standard. In fact we take efforts to clean the |
34 |
> env in some situations for that reason. |
35 |
> |
36 |
> I just can't see it working, apart from perhaps where a command outputs |
37 |
> settings which should be run through eval. In which case, eval them |
38 |
> in ebuild space after the command has output whatever under esudo. To |
39 |
> be flexible, you're going to want to save them anyway for later use, |
40 |
> which again implies that happening in the ebuild/eclass. |
41 |
|
42 |
You're thinking in terms of a SUID helper like sudo. The implementation |
43 |
that I've been suggesting does not involve a SUID helper. Instead, IPC |
44 |
would be used to request that the privileged parent process launch a new |
45 |
privileged process on behalf of esudo. In this context, unless the esudo |
46 |
implementation provides explicit support for environment inheritance, |
47 |
the new privileged process will not inherit any environment from the |
48 |
environment where esudo was called. |
49 |
|
50 |
>>> Other than that, I agree esudo is the best approach, and gives us |
51 |
>>> much better granularity over privilege escalation, as discussed in |
52 |
>>> the bug. |
53 |
>> |
54 |
>> Yeah, me too. |
55 |
> |
56 |
> Cool, glad we're on same page. |
57 |
> |
58 |
>>> Part of me thinks though, that it'd be much cleaner to give the |
59 |
>>> portage user access to sudo. Isn't that effectively the purpose |
60 |
>>> of the "suid helper"? In which case we get all the options for |
61 |
>>> env etc, of sudo, and the admin gets to configure it along with |
62 |
>>> the normal wheel setup. |
63 |
>> |
64 |
>> Depending on our goals, using sudo may or may not have advantages. It. |
65 |
>> really depends on whether or not we want esudo to interact with the |
66 |
>> local sudo configuration. If we want it to be independent of the local |
67 |
>> sudo configuration, then it makes sense for the package manager to use |
68 |
>> it's own privilege escalation mechanism. |
69 |
> |
70 |
> IDK; "independent of the local sudo configuration" /sounds/ good, but |
71 |
> what we are talking about is the configuration for *one* user, that to |
72 |
> run the package manager at the heart of our distro. Speaking as a uadmin |
73 |
> (a Gentoo user who's a defacto admin, not what I think of as an "admin", |
74 |
> which would be a net-admin) I'd much rather configure that in the same |
75 |
> place I configure everything else. |
76 |
> |
77 |
> It's not like I don't see the portage user in /etc/passwd et al, or it's |
78 |
> little-known. We set perms for it on /var/tmp/portage so that userpriv |
79 |
> can work, at least we did last time I set that up. /usr/portage is |
80 |
> set like that too, here. So we already have to deal with the user part |
81 |
> of userpriv, as admins. |
82 |
> |
83 |
> On the implementation side, it makes a lot of sense: we delegate the |
84 |
> worry to a package used cross-distro for this specific purpose. In fact |
85 |
> this conversation has made me understand ubuntu a bit more, where I |
86 |
> always used to smile at the overuse of sudo. I certainly wouldn't |
87 |
> want the implementation headache of maintaining a secure clone. |
88 |
|
89 |
The IPC implementation that I've suggested does not involve an SUID |
90 |
helper, so it is much more secure. Security would rely on the permission |
91 |
bits of the named pipes that are used to implement IPC. |
92 |
|
93 |
> AFAICT functional wrapping can be used for the capability side, but |
94 |
> I'd be interested to read otherwise, ie the ins and outs of why not. |
95 |
> |
96 |
> Regards, |
97 |
> igli |
98 |
> |
99 |
|
100 |
|
101 |
-- |
102 |
Thanks, |
103 |
Zac |