1 |
On Friday 25 January 2013 19:10:53 Gilles Dartiguelongue wrote: |
2 |
> It's not like libcap is a big dependency |
3 |
|
4 |
true, but not everyone needs this, nor can everyone leverage it (caps). it's |
5 |
a linux-centric implementation and is dependent upon filesystem support being |
6 |
available & enabled. |
7 |
|
8 |
that doesn't entirely justify making it a USE flag (since the code already has |
9 |
runtime fallback logic for when the fs doesn't support things), but since the |
10 |
USE is low overhead and leverages logic that already has to be there, i have |
11 |
no problem keeping it. plus it defaults to on. |
12 |
|
13 |
> and it's not like this is an |
14 |
> attempt to make the system more secure by according just the privileges |
15 |
> needed for apps to work as intended, right ? |
16 |
|
17 |
mmm that's exactly what this is |
18 |
|
19 |
> If the USE flag must stay, how is it different that current caps USE |
20 |
> flag ? It applies and not just enables support but is that relevant to |
21 |
> the purpose at hand ? |
22 |
|
23 |
USE=caps is for apps to control their runtime privs (there's also packages |
24 |
which want to query things like coreutils, but let's ignore those). in order |
25 |
to grant themselves reduced privs, they have to start with them in the first |
26 |
place -- capabilities allows you to remove privs from yourself, not extend |
27 |
them. that's accomplished (classically & today) by having the program set*id. |
28 |
thus, when the program is run, it is (typically) launched as the root user |
29 |
which means they have the full capset. |
30 |
|
31 |
if the package supports USE=caps, then it means the program is intelligent |
32 |
enough to know what capabilities it needs and so it can drop all of the rest |
33 |
before executing the main body of code. if it doesn't support USE=caps, then |
34 |
it either tries to do all the superuser stuff first and then drop its uid back |
35 |
down to the executing user's. if it can't do that, then it has to be super |
36 |
careful about everything it does. some packages (like openssh and Google |
37 |
Chrome -- not great examples, but good enough) implement even more complicated |
38 |
setups with privilege separation where there is IPC between a privileged |
39 |
process and an unprivileged one. |
40 |
|
41 |
either way, obviously the more code you have, the harder it is to make sure |
42 |
you get it right (and history is littered with vulns where people didn't). so |
43 |
wouldn't it be nice if you could set the required capabilities on a binary and |
44 |
drop the set*id entirely ? that's what USE=filecaps gets us. now there is no |
45 |
time frame within which you can attack and gain elevated privileges -- the |
46 |
kernel will have the new program start off with the right capset from the very |
47 |
beginning. |
48 |
|
49 |
obviously i'm glossing over bugs where people can get get a program to do |
50 |
things it shouldn't with the capset it didn't drop, but that scenario exists |
51 |
regardless of set*id and USE=caps behavior. in the ideal world: |
52 |
- USE=filecaps so you start only with the caps you need |
53 |
- not be set*id at all |
54 |
- do all the things at the very beginning that require the elevated caps |
55 |
- support USE=caps so you can then drop all of your elevated caps |
56 |
- run like normal and process all user input |
57 |
|
58 |
as an example, let's look at ping. we give it set*id because people want to |
59 |
be able to do something innocuous as `ping 192.168.0.1` w/out `sudo` first. in |
60 |
order to send ICMP_ECHO packets, it needs to create a SOCK_RAW socket which |
61 |
the kernel doesn't allow random users to create (otherwise they could generate |
62 |
arbitrary packets on the network). when USE=-cap, the first thing ping does is |
63 |
create the socket, then drop the root uid. when USE=cap, the first thing it |
64 |
does is drop all of its permitted caps to the bare min what it needs in the |
65 |
future, and then sets the effective even lower. when it needs to open the |
66 |
socket, it sets the effective to what it needs, opens the socket, and then sets |
67 |
the effective lower again. rinse/repeat. |
68 |
|
69 |
at least, this is all my understanding of things. i could be completely |
70 |
wrong, so feel free to correct something if you notice it. |
71 |
-mike |