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>