From nobody Sun Apr 17 16:58:46 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1E59E11E3B88 for ; Sun, 17 Apr 2022 16:59:00 +0000 (UTC) (envelope-from pgn.george@gmail.com) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KhGVq2fK8z4YkP; Sun, 17 Apr 2022 16:58:59 +0000 (UTC) (envelope-from pgn.george@gmail.com) Received: by mail-pg1-x52f.google.com with SMTP id k29so14830354pgm.12; Sun, 17 Apr 2022 09:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w+5omdbCRFkwpra6MHy07rfvAb1VLppHgjt26mi/C5U=; b=CywCP9NiH0bjwREkwShPz6c859XQq0h3NMq5YPrCPHhVbPaVtdbMLjolEH8LNFaXw9 cBYCyPx4KMAelZj2hz+ZgUsXgIyUdyDW4Iz0SKSB4yRoaI/8QpQX2LDvzxjE4kmezMV9 hWbRPsPmFykkDw3I+Bb6oa/CCyH2oI+uiKm40FYgnxbf5vVl0k6Ye4XdpzP+6JjrAWnD eHDakacNtDMRsjrAn42SNHK+F3++JKvBl0B5Fpw/qZBjafK3n3FjrW/snowA86X3UE8Y IU1yvZuWUZSlZDnbR9oHq4xcmvwcZfMq2MGjpCRB/lMB2efJj2BKhzwQJ3G7g8pgbAee TmsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w+5omdbCRFkwpra6MHy07rfvAb1VLppHgjt26mi/C5U=; b=tpaNlGi+xI4QwF1QoVfXtK2ZuQSw1agjlbR+2UV5xMUGtJr7th+u8x17bRuBm8cfch XpxZNI8p8FshP2sP0tkbW7RLuwsRiXOyxylVwxRt/N+G8Ql38Atz06NnEig8yLOaPvaF wNyZ2ZNVSWuE2KvfUAIEcSMcze3YUIUkANmBQELRy0xqx0r5SW4ImQ3Cqidz3lPD6Jc3 PhHvsu7GuoTz+utpfj/lIgxkXrVqof28VBdM3S9XHlnA3bgH+u/SdtgAKG9XosEGns17 1yQBzD0sGT09AjP7Sh+92O/S2oRQukRYcjnXb18urvjQXOC5IvGuLlsUkeYs4w5CFGlj rgDA== X-Gm-Message-State: AOAM531kZDhhvQ3UcIFEnaTOJ1kuib0nCd+1vgTYAjnosZyRZY13eZns Oa60gurYRNvDq76moMpdHZvYxqRnFfLLieAgYrRXXQAXULnxQWiw X-Google-Smtp-Source: ABdhPJwKZ/GqRrVuvBbUjUs7S5gBulCd0LlFSWnyeAxfxs1GeUco4RK1UUSfFvX5btScDgm+ES4bqrZZehkGlmB9mOE= X-Received: by 2002:a05:6a00:b46:b0:508:2d0f:9f83 with SMTP id p6-20020a056a000b4600b005082d0f9f83mr8171754pfo.80.1650214738042; Sun, 17 Apr 2022 09:58:58 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: George Diaconu Date: Sun, 17 Apr 2022 19:58:46 +0300 Message-ID: Subject: Re: Linux capabilities to Capsicum To: David Chisnall Cc: freebsd-hackers@freebsd.org, Elena Mihailescu , =?UTF-8?B?yJhlbmRyZSBNaWhhaS1BbGlu?= , Darius MIHAI Content-Type: multipart/alternative; boundary="00000000000043a29505dcdc8f59" X-Rspamd-Queue-Id: 4KhGVq2fK8z4YkP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=CywCP9Ni; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of pgngeorge@gmail.com designates 2607:f8b0:4864:20::52f as permitted sender) smtp.mailfrom=pgngeorge@gmail.com X-Spamd-Result: default: False [-0.96 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[5]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.04)[0.039]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52f:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[freebsd.org,upb.ro,gmail.com]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --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 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 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
Hello David,

Thank you for the detailed= response.

George

On Sun, Apr 17, 2022 at 6:2= 6 PM David Chisnall <theraven@fr= eebsd.org> wrote:
Hi,

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

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.

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.

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:

=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.
=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.
=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.

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.

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.

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.

David

[1] https://www.freebsd.org/cgi/man.cgi?query=3Dma= c&sektion=3D9&apropos=3D0&manpath=3DFreeBSD+13.0-RELEASE+and+Po= rts

> 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 OpenSt= ack services the least permissions they need.
> 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]:
> - 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?que= ry=3Drights&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+13.0-RELE= ASE+and+Ports
> [2] https://man7.org/linux/man-pages/m= an7/capabilities.7.html

--00000000000043a29505dcdc8f59--