Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Apr 2022 16:26:50 +0100
From:      David Chisnall <theraven@FreeBSD.org>
To:        George Diaconu <pgn.george@gmail.com>
Cc:        freebsd-hackers@freebsd.org, Elena Mihailescu <maria.mihailescu@upb.ro>, =?utf-8?Q?=C8=98endre_Mihai-Alin?= <mihai.alin.sendre@gmail.com>, Darius MIHAI <darius.mihai@upb.ro>
Subject:   Re: Linux capabilities to Capsicum
Message-ID:  <F5C1621B-782C-4980-B6FE-C2F4EDCA2B33@FreeBSD.org>
In-Reply-To: <CAJ1Z2ub99U%2B2TVFs5qse_s=b8_zhjat_zfytYSQ2me1u0mQsGg@mail.gmail.com>
References:  <CAJ1Z2ub99U%2B2TVFs5qse_s=b8_zhjat_zfytYSQ2me1u0mQsGg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

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

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 =E2=80=98capabilities=E2=
=80=99 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=E2=80=99ve 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=E2=80=99t think that you=E2=80=99d 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=3Dmac&sektion=3D9&apropos=3D0&ma=
npath=3DFreeBSD+13.0-RELEASE+and+Ports

> On 16 Apr 2022, at 18:17, George Diaconu <pgn.george@gmail.com> wrote:
>=20
> Hello,
>=20
> 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
>=20
> What would be the respective capabilities in Capsicum?
>=20
> Thank you,
> George
>=20
> [1] =
https://www.freebsd.org/cgi/man.cgi?query=3Drights&sektion=3D4&apropos=3D0=
&manpath=3DFreeBSD+13.0-RELEASE+and+Ports
> [2] https://man7.org/linux/man-pages/man7/capabilities.7.html




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F5C1621B-782C-4980-B6FE-C2F4EDCA2B33>