From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 24 00:33:47 2023 Received: (at 61462) by debbugs.gnu.org; 24 Mar 2023 04:33:47 +0000 Received: from localhost ([127.0.0.1]:39637 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pfZ7a-0008Ua-JG for submit@debbugs.gnu.org; Fri, 24 Mar 2023 00:33:47 -0400 Received: from cascadia.aikidev.net ([173.255.214.101]:42570) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pfZ6D-0008SF-U2 for 61462@debbugs.gnu.org; Fri, 24 Mar 2023 00:33:45 -0400 Received: from localhost (unknown [IPv6:2600:3c01:e000:21:7:77:0:20]) (Authenticated sender: vagrant@cascadia.debian.net) by cascadia.aikidev.net (Postfix) with ESMTPSA id B88171AC6F; Thu, 23 Mar 2023 21:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=debian.org; s=1.vagrant.user; t=1679632321; bh=tXtwnCpMDo84rynIJj+21B8ArOyjndaJhNJr7BDtYfw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DDrQC4tErizMNbrGJkK3wj7wNdJ7PV38D8wWf+6qe9U5EpZGTWaZpGvZX2T8wVmjW LNBmgEHi1rHori1ddvox3QvaMaSflO3eWcIhSKpJWfha5OLPsc+qcAzdCGyktjpf3N BoEsD/XAJerssqjgEZzoqLE/eLB3OmNAe8OKYrbX9oCaL0W1AqJzaPEwYk9ZHwq5H8 hBcqFxA1EGZpoJabe63HGRxkObm0RY89gz9Ke9t0AwQ3kGYagIP242AUwkZ5oW5TPk 2KNStcAm14CQXIMa+lP2XM+y33XuwpNswUO6diVKO1Ylw/z9iBKrz2i03VxVom0rJ1 4AUxJsOYGclhA== From: Vagrant Cascadian To: Ludovic =?utf-8?Q?Court=C3=A8s?= , Tobias Geerinckx-Rice Subject: Re: [bug#61462] Add support for file capabilities(7) In-Reply-To: <877cvwsbfk.fsf@gnu.org> References: <87r0uuehlr.fsf@nckx> <877cvwsbfk.fsf@gnu.org> Date: Thu, 23 Mar 2023 21:31:53 -0700 Message-ID: <87cz4y6a86.fsf@contorta> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61462 Cc: 61462@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2023-03-04, Ludovic Court=C3=A8s wrote: > Tobias Geerinckx-Rice skribis: > >> I need to offload some of my eternally rebased local patches. Here's >> one that makes it easy to assign capabilities(7) =E2=80=94 currently thr= ough >> setcap(8) =E2=80=94 to programmes like we can set{u,g}id. >> >> There are many packages that benefit from this. Mine are: >> >> (privileged-programs >> (cons* (privileged-program >> (file-append mtr "/sbin/mtr") >> (capabilities "cap_net_raw+ep")) >> (privileged-program >> (file-append nethogs "/sbin/nethogs") >> (capabilities "cap_net_admin,cap_new_raw+ep")) >> (privileged-program >> (file-append light "/bin/light") >> (setuid? #t)) >> %default-privileged-programs)) > > Neat! Agreed! Thanks! >> I'm quite opinionated about the setuid-programs unification: there >> should not be multiple confusing and masking layers of privilege, and >> it should be possible to setgid a capable executable. > > So you mean that =E2=80=98privileged-programs=E2=80=99 should entirely re= place > =E2=80=98setuid-programs=E2=80=99, right? > > I=E2=80=99m a bit unsure about using file capabilities: > > 1. File capabilities are persistent and less visible than setuid bits > (you won=E2=80=99t see them with =E2=80=9Cls -l=E2=80=9D), so easily= overlooked. Could > there be a risk of lingering file capabilities when reconfiguring a > system? Does reconfigure leave old setuid binaries laying around in /run/setuid-programs currently? That sounds like leaking state from previous generations into the current generation, and should be fixed if it is indeed the case. Seems like with setuid/setgid and the proposed priviledged binaries, the setuid/setgid bits and capabilties should be explicitly set on any defined binaries, and any that are left over in the /run/*-programs directories should be... forcibly removed! Otherwise your current system is vulnerable to previous potentially bad choices indefinitely... Basically, guix system reconfigure should be fastidious and ideally deterministic with generating and updating /run/*-programs ... > 2. How =E2=80=99bout portability to different file systems and to GNU/H= urd? Currently I *think* /run/setuid-programs is tmpfs (at least on systems I have used running a linux-libre kernel) ... I do not think this attempts to change that...; we probably do not need broad filesystem compatibility, just whatever filesystem /run/*-programs is implemented on. And since they are not compatibly with GNU/Hurd, then let us drop support for x86_64-linux, riscv64-linux, ppc64el-linux, arm64-linux, etc. ... to make sure things are compatible! :P In all seriousness though, while I appreciate thinking about broad compatibility across different types of systems, I am a bit nervous about an approach that would require features to behave compatibly across all systems... ...though I suspect you were more getting at "What are the consequences of implementing this for some other system types?" > 3. What=E2=80=99s the complexity/benefit ratio? :-) > > Then there=E2=80=99s the compatibility story with moving from > /run/setuid-programs to /run/privileged-programs etc. that=E2=80=99ll hav= e to be > handled with care. I am less opinionated about adding yet another directory to PATH, although obivously then you get into the weird issues with old $PATH values laying around (e.g. not getting the new directory added until logging out or re-loading the running profile) > I=E2=80=99m very much sold to the principle of least authority, but I fee= l like > POSIX capabilities (not to be confused with =E2=80=9Cactual=E2=80=9D capa= bilities) are a > bit of a hack. And setuid/setgid is not a hack? It seems like essentially the same thing, just with no granularity... > Thoughts? There are some things that are just not possible without capabilities, and setuid/setgid is a dangerous hammer that should be used very sparingly, if at all, and capabilities are no *worse* that setuid/setgid, allowing a finer grained set of problems :) The need for this functionality has come up more than a few times: https://issues.guix.gnu.org/27415 https://issues.guix.gnu.org/39136 https://issues.guix.gnu.org/55683 And possibly a few others: https://issues.guix.gnu.org/search?query=3Dsetcap live well, vagrant --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZB0nugAKCRDcUY/If5cW qs9AAQDmHv2X5PEZVmW6X0wGSbqTGP/1lT22DrJGHUnhKJyIMgEA2e2/zzQjDxwd NUfndSt+0z/GfKibdAv/8tiXvaLuZwU= =jTL3 -----END PGP SIGNATURE----- --=-=-=--