[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-hackers
Subject: Re: Linux capabilities to Capsicum
From: George Diaconu <pgn.george () gmail ! com>
Date: 2022-04-17 16:58:46
Message-ID: CAJ1Z2uZyJDGy5f_MmiRrajm7tngm8G5W54oByz4LdsnnkSQ7nA () mail ! gmail ! com
[Download RAW message or body]
Hello David,
Thank you for the detailed response.
George
On Sun, Apr 17, 2022 at 6:26 PM David Chisnall <theraven@freebsd.org> 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]
> 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
>
>
[Attachment #3 (text/html)]
<div dir="ltr">Hello David,<div><br></div><div>Thank you for the detailed \
response.</div><div><br></div><div>George</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 17, 2022 at 6:26 PM \
David Chisnall <<a href="mailto:theraven@freebsd.org">theraven@freebsd.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br>
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. <br> <br>
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.<br> <br>
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.<br> <br>
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:<br> <br>
- 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.<br>
- 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.<br>
- 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.<br> <br>
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.<br> <br>
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.<br> <br>
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.<br> <br>
David<br>
<br>
[1] <a href="https://www.freebsd.org/cgi/man.cgi?query=mac&sektion=9&apropos=0&manpath=FreeBSD+13.0-RELEASE+and+Ports" \
rel="noreferrer" target="_blank">https://www.freebsd.org/cgi/man.cgi?query=mac&sektion=9&apropos=0&manpath=FreeBSD+13.0-RELEASE+and+Ports</a><br>
<br>
> On 16 Apr 2022, at 18:17, George Diaconu <<a \
href="mailto:pgn.george@gmail.com" target="_blank">pgn.george@gmail.com</a>> \
wrote:<br> > <br>
> Hello,<br>
> <br>
> 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.<br> > 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]:<br> > - CAP_DAC_OVERRIDE<br>
> - CAP_DAC_READ_SEARCH<br>
> - CAP_NET_ADMIN<br>
> - CAP_SYS_PTRACE<br>
> - CAP_SYS_ADMIN<br>
> <br>
> What would be the respective capabilities in Capsicum?<br>
> <br>
> Thank you,<br>
> George<br>
> <br>
> [1] <a href="https://www.freebsd.org/cgi/man.cgi?query=rights&sektion=4&apropos=0&manpath=FreeBSD+13.0-RELEASE+and+Ports" \
rel="noreferrer" target="_blank">https://www.freebsd.org/cgi/man.cgi?query=rights&sektion=4&apropos=0&manpath=FreeBSD+13.0-RELEASE+and+Ports</a><br>
> [2] <a href="https://man7.org/linux/man-pages/man7/capabilities.7.html" \
rel="noreferrer" target="_blank">https://man7.org/linux/man-pages/man7/capabilities.7.html</a><br>
<br>
</blockquote></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic