1 |
> Bart Alewijnse wrote: |
2 |
> | Errm. I was referring to the *user* 'emerge' - I wasn't aware you can |
3 |
> | use su to execute binaries. sudo, yes, but su? 'sudo su emerge' would |
4 |
> | cause sudo to run su with the command line parameter 'emerge' which |
5 |
> | can only be a username - rather than hand sudo two executable names, |
6 |
> | right? |
7 |
> | But if you're paranoid, you could likely require the path to emerge in |
8 |
> | sudoers, so that it'd have to be |
9 |
> | 'sudo su /usr/bin/emerge' - or possibly just that it'd only accept |
10 |
> | running emerge if the actual emerge binary being suggested for running |
11 |
> | is the one in /usr/bin. Since you don't have direct accidental access |
12 |
> | to that as either considered user, it's not a risk. |
13 |
> | |
14 |
> Yes, su can run commands with the -c option. So 'su root -c "rm -rf /"' |
15 |
> would blow away your system. However, in your example you don't have |
16 |
|
17 |
Good point, didn't know that. |
18 |
|
19 |
But root? What? I was suggesting only su-ing from selected users to |
20 |
the 'emerge' user. |
21 |
|
22 |
The worst you could do then is probably 'sudo su emerge -c |
23 |
/evil/emergee', which would then be executed as emerge - which I was |
24 |
assuming to be a non-admin account, just as a syntactic command line |
25 |
sugar inbetween step. |
26 |
|
27 |
The point to that was that people that would emerge would both have a |
28 |
common account (possibly good for config files), but just to the |
29 |
point, that that's a nice conceptual location you could run the actual |
30 |
emerge binary from - again, through sudo, because if emerge is an |
31 |
admin acccount, it might as well be root itself. |
32 |
|
33 |
|
34 |
Actually, indeed, just adjusting sudoers to have specific people have |
35 |
the ability to run /usr/bin/emerge would be enough, pretty much |
36 |
period. |
37 |
|
38 |
|
39 |
And if not that, according to taste and as someone just mailed me, you |
40 |
also do what I suggest in one step, indeed with a 'sudu so -c |
41 |
/usr/bin/emerge' with assorted |
42 |
things-you-actually-also-need-in-reality(tm) (again, I've not used |
43 |
sudo much at all) |
44 |
|
45 |
That's indeed simpler systemwise. I was just going for the |
46 |
understandable-for-people-not-on-this-list (and possibly myself next |
47 |
week) angle. Rather pointless, really. There are such things as |
48 |
scripts:) |
49 |
|
50 |
|
51 |
Interesing suggestion, but how exactly would you break out of chroot |
52 |
once you're properly authenticated? I mean, there's very little point |
53 |
to running emerge within a chrooted environment, right? You're doing |
54 |
something cleaner, though, so do please explain. |
55 |
|
56 |
|
57 |
But as I keep saying, security is entirely moot in this matter, as bad |
58 |
intentsions are met with essential root access no matter what you do, |
59 |
because emerge itself needs it. It's better than giving them root |
60 |
access as accidental typo's could be entirely fatal there, but not as |
61 |
the emerge user - unless you did something stupid with emerge, but |
62 |
then you shouldn't be emerging in the first place. |
63 |
|
64 |
--Bart Alewijnse |
65 |
|
66 |
-- |
67 |
gentoo-security@g.o mailing list |