Messages in this thread | | | Date | Thu, 23 Apr 1998 20:16:51 +0200 | From | Alexander Kjeldaas <> | Subject | Re: suser() -> capable() for linux/* |
| |
On Thu, Apr 23, 1998 at 06:19:50PM +0200, David Woodhouse wrote: > > Looking at the capabilities patches, I can't help wondering if they are > granular enough. > > For example, I want certain users to be able to manipulate my second network > card, but not the main one. I certainly don't want them to have all the > privileges that CAP_NET_ADMIN gives. > > CAP_SYS_ADMIN is even worse - I'll want my own user to be able to set up the > frame buffer address on the TV card, but that's all. >
CAP_{NET,SYS}_ADMIN are `catch all' capabilities. They are used when none of the others fit. Yes, they are somewhat evil ;-).
> I'd also like a CAP_NETWORK, to control _any_ network access, > ideally with the possibility of allowing traffic only on certain > devices, although that's not quite feasible ATM. With the > SO_BINDTODEVICE code in place, I suppose one could enforce "only > loopback", though.
CAP_NETWORK would be nice. The reason we don't currently have it, is that it is not a part of having root privileges to be able to have network access.
The current capabilities are a partitioning of the root privileges. This makes it easy to implement - we basically only have to change all calls to suser() to call capable(). If we wanted to add CAP_NETWORK we would have to add credentials checks in places we currently do not have any.
This also have impact on file system storing of capabilities. To not break backwards compatibility we would want all processes to automatically get the CAP_NETWORK capability. Thus when we "read" capabilities from the file system, we would have to read the CAP_NETWORK bit as "set" in the allowed set. Currently we read all capabilities as "unset" from the file system. When we _get_ file system support, we would have to write a default capability with the CAP_NETWORK bit set [This means that _all_ executable, not only the privileged ones would have to have a capability stored on the file system]. Alternatively we would have a layer that "adds" this bit to what the file system actually store. This adds complexity that we currently do not have to deal with.
I'm not trying to say that it is difficult to implement the above, but I want to keep capabilities simple.
> Perhaps such granularity could be achieved by adding an opaque field > to the cap_t, which could be to further qualify the capability, for > example in the case of CAP_SYS_ADMIN it could contain a dev_t & mask > to specify the device(s) to which access is permitted.
A problem with this is how to represent them on disk. Many of the extra fields used to qualify the capability wouldn't map very well to be stored on a distributed file system or even to be stored on a file system between reboots. I think this kind of capabilities would have to start out as "disabled" and require a user-level daemon to provide the data to qualify and "enable" the capability.
So your points implies two additions to the current model
* Capabilities that are on by default * Capabilities requiring daemon support
But just for the record, I _don't_ think the current partitioning can't be improved. If anybody has comments or improvements please speak up.
astor
-- Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway http://www.guardian.no/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |