Mapping Linux capabilities(7) to our Capsicum rights(4)

Gleb Popov arrowd at freebsd.org
Mon Oct 26 17:04:41 UTC 2020


On Mon, Oct 26, 2020 at 4:17 PM Jonathan Anderson <jonathan at freebsd.org>
wrote:

> Hi Gleb,
>
> There won't be a clear mapping between the two, as Linux "capabilities"
> (actually privileges, but unfortunately Symbian and POSIX.1e both called
> their privileges "capabilities" [1]) describe things that a process can do,
> whereas Capsicum capabilities (which are object capabilities) describe
> things that a file descriptor can do. If you want to constrain the
> behaviour of a process, Capsicum provides cap_enter(2), giving up access to
> global namespaces, but that approach may not fit with the Linux-tailored
> software you're porting.
>
> What's the fundamental security goal of the software in question? Dropping
> privileges is one mechanism to try to accomplish your goal, but there may
> well be a very different way of accomplishing it. In many situations (e.g.,
> sandboxing), Linux "capabilities" and seccomp-bpf are a bit of an awkward
> fit... maybe we can help you find a better way?
>

It would be great, but I must admit that at the moment I barely understand
all the complexities of the software.

>From what I can tell, it spawns child processes and applies following
hardening for them:

- chroot into a sort of "jail".
- prohibits using some system calls (using that seccomp thing)
- drops capabilities with cap_* functions

For now, I'm simply #ifdef'ing this code, but the upstream is really
concerned about security and insists that all these security measures be
reimplemented when making a port. I have about zero experience in this
field, so any guidance would be most appreciated.


More information about the freebsd-hackers mailing list