1 |
On Tue, Sep 30, 2014 at 07:52:02AM -0700, Zac Medico wrote: |
2 |
> On 09/29/2014 04:31 PM, Steven J. Long wrote: |
3 |
> > On Mon, Sep 29, 2014, Zac Medico wrote: |
4 |
> >> On 09/28/2014, Steven J. Long wrote: |
5 |
> >>> On Wed, Sep 24, 2014, Zac Medico wrote: |
6 |
> >>>> 1) When esudo is called, it saves the current (unprivileged) bash |
7 |
> >>>> environment to a file. |
8 |
> >>>> |
9 |
> >>>> 2) esudo uses IPC to request that a process with elevated privileges be |
10 |
> >>>> launched to run a specific command using the saved environment, and that |
11 |
> >>>> the environment of the elevated process be saved to a file after the |
12 |
> >>>> command completes. |
13 |
> >>> |
14 |
> >>> I don't think it's going to be quite that easy to get the output env, |
15 |
> >>> certainly not from some random command; tbh I don't even see the need |
16 |
> >>> for it, unless I'm missing something. From the "elevated process" after |
17 |
> >>> it waits on the child, but not from the child unless you control the |
18 |
> >>> code. |
19 |
> >> |
20 |
> >> We control the shell code that launches the requested command, so we can |
21 |
> >> save the environment after the requested command completes (using a |
22 |
> >> modified version of our existing environment persistence code). |
23 |
> > |
24 |
> > Yeah but think it through; the "elevated process" inherits its environment |
25 |
> > from us (current state, as normal). It runs a child process: nothing in the |
26 |
> > env of that child is going to affect our env, by definition. The command |
27 |
> > completes, and we save back the same env we started with. |
28 |
> > |
29 |
> > Sure, the child inherits its env from us, but we don't need to do anything |
30 |
> > to make that happen: it's standard. In fact we take efforts to clean the |
31 |
> > env in some situations for that reason. |
32 |
> > |
33 |
> > I just can't see it working, apart from perhaps where a command outputs |
34 |
> > settings which should be run through eval. In which case, eval them |
35 |
> > in ebuild space after the command has output whatever under esudo. To |
36 |
> > be flexible, you're going to want to save them anyway for later use, |
37 |
> > which again implies that happening in the ebuild/eclass. |
38 |
> |
39 |
> You're thinking in terms of a SUID helper like sudo. The implementation |
40 |
> that I've been suggesting does not involve a SUID helper. |
41 |
|
42 |
No, I'm thinking in terms of "a process with elevated privileges" running |
43 |
"a specific command"; whether that first process is started by us or not, |
44 |
is irrelevant to whether it can get the environment from a child process |
45 |
we have no control over, after it "completes". |
46 |
|
47 |
Sure it can save its own, but since it's a generic "run any command" helper, |
48 |
it can't do much more than give us back what we gave it, unless you're |
49 |
talking about echoing back settings, in the manner of gpg et al, which |
50 |
by definition is not about the saved env. That's why we have to use that |
51 |
format in the first place; because the env setting must be done by the |
52 |
process which wants to use it (have it inherited for child processes), |
53 |
for the same reason: a child process can never affect the parent env. |
54 |
|
55 |
> Instead, IPC |
56 |
> would be used to request that the privileged parent process launch a new |
57 |
> privileged process on behalf of esudo. In this context, unless the esudo |
58 |
> implementation provides explicit support for environment inheritance, |
59 |
> the new privileged process will not inherit any environment from the |
60 |
> environment where esudo was called. |
61 |
|
62 |
Well, assuming that were the implementation, that explains why you'd want |
63 |
to save the env off, so that the privileged helper can access it. It still |
64 |
sounds like more work in the long run in terms of what's happening, but |
65 |
regardless: it doesn't get you the resultant env from the child command. |
66 |
|
67 |
But like I said, that's of dubious utility in any case. I think we should |
68 |
just forget about it. |
69 |
|
70 |
> > So we already have to deal with the user part of userpriv, as admins. |
71 |
> > |
72 |
> > On the implementation side, it makes a lot of sense: we delegate the |
73 |
> > worry to a package used cross-distro for this specific purpose. In fact |
74 |
> > this conversation has made me understand ubuntu a bit more, where I |
75 |
> > always used to smile at the overuse of sudo. I certainly wouldn't |
76 |
> > want the implementation headache of maintaining a secure clone. |
77 |
> |
78 |
> The IPC implementation that I've suggested does not involve an SUID |
79 |
> helper, so it is much more secure. Security would rely on the permission |
80 |
> bits of the named pipes that are used to implement IPC. |
81 |
|
82 |
I see, so presumably there's a fifo pair, that only the portage user can |
83 |
access (likely at dir level too), one read-only? On the other end of which |
84 |
you have a waiting process, ie a daemon, in the classic sense, with root |
85 |
privilege, so it can run any command as any user, with any set of caps |
86 |
required. If you're using IPC to request a process with privilege be |
87 |
launched, something's got to be listening to the other end. |
88 |
|
89 |
I don't see how that's "more secure", but then I don't really care how you |
90 |
implement it, either ;) It's certainly less deps, I guess. |
91 |
|
92 |
It still just sounds like a reimpl of sudo, by an indirect method (root |
93 |
userland daemon, as opposed to kernel suid) leading to a lot more going |
94 |
on at runtime (env saving to file, reloading in a new child process |
95 |
from the privileged daemon, before we can start the actual command.) |
96 |
|
97 |
And as above, it cannot get us the env after randomcmd completes, but |
98 |
that's orthogonal, since nothing can, and programs aren't written |
99 |
to output to their env, since the parent can't access it. |
100 |
|
101 |
I assume you have code in mind for this already, perhaps from another |
102 |
project? If so, and it's a reasonable maintenance burden, ie not |
103 |
much needs to change once it's up and running correctly, then fair |
104 |
enough. Though from what I've seen even Linux-specific projects just |
105 |
exec the command, after setting privileges, namespace etc as |
106 |
appropriate, from a suid helper. |
107 |
|
108 |
Are you sure you don't want to borrow someone else's code for a suid |
109 |
helper instead? Not sure what a daemon buys you, apart from extra |
110 |
maintenance overhead (listener, loading env, as well as what a suid |
111 |
helper would do, and a protocol for communication, which no doubt is |
112 |
going to change over time) plus an attack vector for someone who can |
113 |
crack portage or python at any future point, or just get portage uid |
114 |
via some other vector; for a relatively infrequent operation. |
115 |
|
116 |
Regards, |
117 |
igli |
118 |
-- |
119 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |