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