Date: Sun, 17 Apr 2022 19:58:46 +0300 From: George Diaconu <pgn.george@gmail.com> To: David Chisnall <theraven@freebsd.org> Cc: freebsd-hackers@freebsd.org, Elena Mihailescu <maria.mihailescu@upb.ro>, =?UTF-8?B?yJhlbmRyZSBNaWhhaS1BbGlu?= <mihai.alin.sendre@gmail.com>, Darius MIHAI <darius.mihai@upb.ro> Subject: Re: Linux capabilities to Capsicum Message-ID: <CAJ1Z2uZyJDGy5f_MmiRrajm7tngm8G5W54oByz4LdsnnkSQ7nA@mail.gmail.com> In-Reply-To: <F5C1621B-782C-4980-B6FE-C2F4EDCA2B33@FreeBSD.org> References: <CAJ1Z2ub99U%2B2TVFs5qse_s=b8_zhjat_zfytYSQ2me1u0mQsGg@mail.gmail.com> <F5C1621B-782C-4980-B6FE-C2F4EDCA2B33@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000043a29505dcdc8f59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99t think you=E2=80=99ll have much luck trying to map Linux c= apabilities 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 =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 acces= s > 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 privilege= s > that root holds on *NIX systems were never intended to be decomposed. Th= e > 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 yo= ur > 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 hav= e > them exec code that you=E2=80=99ve injected. > - If you have CAP_SYS_ADMIN, can do pretty much anything that root can d= o > 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 lo= t > 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 separat= e > 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 negligib= le > if the set of privileged actions includes the full set authorised by thos= e > 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&m= anpath=3DFreeBSD+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 OpenSta= ck > called oslo_privsep. This package uses linux capabilities to give OpenSta= ck > 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=3Drights&sektion=3D4&apropos=3D= 0&manpath=3DFreeBSD+13.0-RELEASE+and+Ports > > [2] https://man7.org/linux/man-pages/man7/capabilities.7.html > > --00000000000043a29505dcdc8f59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hello David,<div><br></div><div>Thank you for the detailed= response.</div><div><br></div><div>George</div></div><br><div class=3D"gma= il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Apr 17, 2022 at 6:2= 6 PM David Chisnall <<a href=3D"mailto:theraven@freebsd.org">theraven@fr= eebsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex">Hi,<br> <br> I don=E2=80=99t think you=E2=80=99ll have much luck trying to map Linux cap= abilities to Capsicum.=C2=A0 Although they have similar names, they are ver= y different.=C2=A0 <br> <br> Linux capabilities, confusingly, are not a capability system.=C2=A0 A capab= ility is an unforgeable token of authority that can be delegated and must b= e presented to perform an action.=C2=A0 Linux =E2=80=98capabilities=E2=80= =99 are permissions that relate to the ambient authority of a process: simp= ly having the permission is sufficient to perform any of the privileged act= ions.=C2=A0 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.=C2=A0 Once = you enter capability mode, you have no ambient authority.=C2=A0 You many no= t access any global namespace except by presenting a capability (file descr= iptor) with the relevant authority to a system call.<br> <br> Linux capabilities are intended to allow programs to have some subset of ro= ot privileges.=C2=A0 This is very difficult to do well because the privileg= es that root holds on *NIX systems were never intended to be decomposed.=C2= =A0 The set that you list add up to complete root power, in several ways.= =C2=A0 For example:<br> <br> =C2=A0- If you have CAP_SYS_PTRACE then you can attach to init (or any othe= r unrestricted daemon), inject arbitrary code, and tell it to execute on yo= ur behalf.<br> =C2=A0- If you have CAP_DAC_OVERRIDE then you can (unless running with some= code-signing checks) modify bits of the filesystem that unrestricted progr= ams running as root will trust as containing system binaries and have them = exec code that you=E2=80=99ve injected.<br> =C2=A0- If you have CAP_SYS_ADMIN, can do pretty much anything that root ca= n do even without additional elevation steps, including any `ioctl` on bloc= k devices.<br> <br> I don=E2=80=99t think that you=E2=80=99d lose anything other than a tiny bi= t of defence in depth that costs an attacker several seconds to bypass by s= imply skipping the privilege separation that this kind of use of Linux capa= bilities buys you.<br> <br> Similar restrictions could be imposed by a MAC policy[1] but that is a lot = of work to implement.=C2=A0 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 t= hat performs these trusted actions on its behalf.=C2=A0 That would be a lot= less effort to implement, though again the security benefits are negligibl= e if the set of privileged actions includes the full set authorised by thos= e Linux permissions since they equate to giving the unprivileged process co= mplete control over your system.<br> <br> David<br> <br> [1] <a href=3D"https://www.freebsd.org/cgi/man.cgi?query=3Dmac&sektion= =3D9&apropos=3D0&manpath=3DFreeBSD+13.0-RELEASE+and+Ports" rel=3D"n= oreferrer" target=3D"_blank">https://www.freebsd.org/cgi/man.cgi?query=3Dma= c&sektion=3D9&apropos=3D0&manpath=3DFreeBSD+13.0-RELEASE+and+Po= rts</a><br> <br> > On 16 Apr 2022, at 18:17, George Diaconu <<a href=3D"mailto:pgn.geo= rge@gmail.com" target=3D"_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 OpenSta= ck called oslo_privsep. This package uses linux capabilities to give OpenSt= ack services the least permissions they need.<br> > Now as part of porting to FreeBSD we want to replace the linux capabil= ities with Capsicum. We found a list of Capsicum capabilities at [1]. So fa= r we found that the package uses at least the following 5 capabilities desc= ribed 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=3D"https://www.freebsd.org/cgi/man.cgi?query=3Drights&= sektion=3D4&apropos=3D0&manpath=3DFreeBSD+13.0-RELEASE+and+Ports" r= el=3D"noreferrer" target=3D"_blank">https://www.freebsd.org/cgi/man.cgi?que= ry=3Drights&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+13.0-RELE= ASE+and+Ports</a><br> > [2] <a href=3D"https://man7.org/linux/man-pages/man7/capabilities.7.ht= ml" rel=3D"noreferrer" target=3D"_blank">https://man7.org/linux/man-pages/m= an7/capabilities.7.html</a><br> <br> </blockquote></div> --00000000000043a29505dcdc8f59--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ1Z2uZyJDGy5f_MmiRrajm7tngm8G5W54oByz4LdsnnkSQ7nA>