Re: Linux capabilities to Capsicum

Hi,

I don’t think you’ll have much luck trying to map Linux capabilities to Capsicum.  Although they have similar names, they are very different.  

Linux capabilities, confusingly, are not a capability system.  A capability is an unforgeable token of authority that can be delegated and must be presented to perform an action.  Linux ‘capabilities’ are permissions that relate to the ambient authority of a process: simply having the permission is sufficient to perform any of the privileged actions.  There is no namable object that you are able to present to the relevant system calls to be explicitly choose to exert the authority.

In contrast, Capsicum makes file descriptors into capabilities.  Once you enter capability mode, you have no ambient authority.  You many not access any global namespace except by presenting a capability (file descriptor) with the relevant authority to a system call.

Linux capabilities are intended to allow programs to have some subset of root privileges.  This is very difficult to do well because the privileges that root holds on *NIX systems were never intended to be decomposed.  The set that you list add up to complete root power, in several ways.  For example:

 - If you have CAP_SYS_PTRACE then you can attach to init (or any other unrestricted daemon), inject arbitrary code, and tell it to execute on your behalf.
 - If you have CAP_DAC_OVERRIDE then you can (unless running with some code-signing checks) modify bits of the filesystem that unrestricted programs running as root will trust as containing system binaries and have them exec code that you’ve injected.
 - If you have CAP_SYS_ADMIN, can do pretty much anything that root can do even without additional elevation steps, including any `ioctl` on block devices.

I don’t think that you’d lose anything other than a tiny bit of defence in depth that costs an attacker several seconds to bypass by simply skipping the privilege separation that this kind of use of Linux capabilities buys you.

Similar restrictions could be imposed by a MAC policy[1] but that is a lot of work to implement.  It would be a nice project for someone to look at Linux Capabilities and the Solaris equivalents and build something that exposed this kind of functionality.

The more traditional UNIX way of doing what you need is to have a separate process that runs as root and exposes an RPC interface to the Python code that performs these trusted actions on its behalf.  That would be a lot less effort to implement, though again the security benefits are negligible if the set of privileged actions includes the full set authorised by those Linux permissions since they equate to giving the unprivileged process complete control over your system.

David

[1] https://www.freebsd.org/cgi/man.cgi?query=mac&sektion=9&apropos=0&manpath=FreeBSD+13.0-RELEASE+and+Ports

> On 16 Apr 2022, at 18:17, George Diaconu <pgn.george@gmail.com> wrote:
> 
> Hello,
> 
> Together with my colleagues we are trying to port OpenStack to FreeBSD. As part of the process we need to modify a python package used by OpenStack called oslo_privsep. This package uses linux capabilities to give OpenStack services the least permissions they need.
> Now as part of porting to FreeBSD we want to replace the linux capabilities with Capsicum. We found a list of Capsicum capabilities at [1]. So far we found that the package uses at least the following 5 capabilities described in [2]:
> - CAP_DAC_OVERRIDE
> - CAP_DAC_READ_SEARCH
> - CAP_NET_ADMIN
> - CAP_SYS_PTRACE
> - CAP_SYS_ADMIN
> 
> What would be the respective capabilities in Capsicum?
> 
> Thank you,
> George
> 
> [1] https://www.freebsd.org/cgi/man.cgi?query=rights&sektion=4&apropos=0&manpath=FreeBSD+13.0-RELEASE+and+Ports
> [2] https://man7.org/linux/man-pages/man7/capabilities.7.html