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