1 |
On Sunday 18 April 2010 07:41:51 Mike Edenfield wrote: |
2 |
> On 4/18/2010 12:29 AM, Jonathan wrote: |
3 |
> > On Sun, 18 Apr 2010 00:46:25 +0100 |
4 |
> > |
5 |
> > David W Noon<dwnoon@××××××××.com> wrote: |
6 |
> >> If any Joe Schmoe could imbue a program with capabilities, this might |
7 |
> >> be true. But that's not the way the system works. |
8 |
> > |
9 |
> > Sorry, I think i'm missing your point. |
10 |
> > |
11 |
> >> Only root can run the setcap program to add capabilities to a program, |
12 |
> >> at least on a normal, UNIX-style security system. On a role-based |
13 |
> >> security system, even root might not be permitted to do this. |
14 |
> > |
15 |
> > If I had the root password to own system(which I do...) and I wanted Wine |
16 |
> > to uses IPX without running as root. I would set "setcap cap_net_raw=ep |
17 |
> > /usr/bin/wine" as root. Then I could run Wine as my normal user. |
18 |
> > |
19 |
> > No one in there right mind would run Wine as root. If you did you may as |
20 |
> > well use Windows. |
21 |
> |
22 |
> You say "no one in their right mind" would run Wine as root. |
23 |
> But if you did not have capabilities support available, |
24 |
> and wanted Wine to use IPX, then you wouldn't have any other |
25 |
> choice but to run Wine as root. |
26 |
> |
27 |
> By using capabilities, you aren't increasing Wines |
28 |
> permissions, you are decreasing the permissions needed to |
29 |
> support IPX. Trying to compare Wine without IPX to Wine |
30 |
> with CAP_NET_RAW isn't a fair comparison, as the two don't |
31 |
> have the same feature set and thus clearly don't have the |
32 |
> same security needs. |
33 |
|
34 |
Or explain it like this: |
35 |
|
36 |
The kernel can do anything the software and hardware supports. |
37 |
|
38 |
Normally, the Unix kernel gives those same rights to any app running with UID |
39 |
0 (NOT the same thing as the root account - that's just a label. To prove it, |
40 |
create a new account "toor" with UID 0 and log in as it). |
41 |
|
42 |
Unix permissions are traditionally an all or nothing approach. You can do what |
43 |
root can do, or you can do what users can do. This got modified with the |
44 |
introduction of groups and group owners a long time ago, where a user could |
45 |
get the rights of the group owner of an app/file is they were members of the |
46 |
group. |
47 |
|
48 |
Please note that it's the kernel doing this, not the root account. The kernel |
49 |
trusts the root account and does what it says. But traditional Unix |
50 |
permissions have the problem of not being fine-grained enough. For the most |
51 |
part this works fine, but in the odd case where you need more, you are up a |
52 |
creek without a paddle and have to give everything to get a little. That's why |
53 |
we have SUID and it's bastard progeny GUID. A more ridiculous solution is very |
54 |
hard to find. |
55 |
|
56 |
So this whole argument about "do caps raise or lower permissions?" is utterly |
57 |
pointless and leads nowhere. It's not even the point, as there are two |
58 |
viewpoints and one seems to go up and one seems to go down. |
59 |
|
60 |
caps do this: |
61 |
|
62 |
Allow fine-grained access control to resources, without having to give |
63 |
everything to get something. |
64 |
|
65 |
-- |
66 |
alan dot mckinnon at gmail dot com |