Re: Linux capabilities to Capsicum

From: George Diaconu <>
Date: Sun, 17 Apr 2022 16:58:46 UTC
Hello David,

Thank you for the detailed response.


On Sun, Apr 17, 2022 at 6:26 PM David Chisnall <> wrote:

> 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]
> > On 16 Apr 2022, at 18:17, George Diaconu <> 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]:
> >
> > What would be the respective capabilities in Capsicum?
> >
> > Thank you,
> > George
> >
> > [1]
> > [2]