From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id wL2QD3T0n2IzsgAAbAwnHQ (envelope-from ) for ; Wed, 08 Jun 2022 02:59:32 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id GPlhD3T0n2IjNQEAauVa8A (envelope-from ) for ; Wed, 08 Jun 2022 02:59:32 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 681B89A0B for ; Wed, 8 Jun 2022 02:59:31 +0200 (CEST) Received: from localhost ([::1]:37884 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nyk2j-0007pU-TD for larch@yhetil.org; Tue, 07 Jun 2022 20:59:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52378) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyk2J-0007pJ-Ss for bug-guix@gnu.org; Tue, 07 Jun 2022 20:59:05 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:48047) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nyk2I-0005Zn-CB for bug-guix@gnu.org; Tue, 07 Jun 2022 20:59:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nyk2I-0000dk-Bh for bug-guix@gnu.org; Tue, 07 Jun 2022 20:59:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#54786: Installation tests are failing Resent-From: bokr@bokr.com Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 08 Jun 2022 00:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54786 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: othacehe@gnu.org, Maxim Cournoyer , 54786@debbugs.gnu.org Received: via spool by 54786-submit@debbugs.gnu.org id=B54786.16546499182429 (code B ref 54786); Wed, 08 Jun 2022 00:59:02 +0000 Received: (at 54786) by debbugs.gnu.org; 8 Jun 2022 00:58:38 +0000 Received: from localhost ([127.0.0.1]:41944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nyk1t-0000d7-JS for submit@debbugs.gnu.org; Tue, 07 Jun 2022 20:58:38 -0400 Received: from mailout.easymail.ca ([64.68.200.34]:45640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nyk1r-0000ct-2q for 54786@debbugs.gnu.org; Tue, 07 Jun 2022 20:58:37 -0400 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id AD13261328; Wed, 8 Jun 2022 00:58:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bokr.com; s=easymail; t=1654649909; bh=yAFgcas4v//bGlAEPgEBML+mkPIbU0ytt54IrMnRLlk=; h=From:Date:To:Cc:Subject:References:In-Reply-To:From; b=TKo9ze/vhoJBHGWRf1D5Nmp29WNmqOiXnw3YfGJWI+pSy3RzTVcGEZCJPPxf5oo3I BKZPgrveVSHYZoTpdpDZWXLl1sDI8uW9Op5OsLQCDU5oayvNkh22cciACIwwmUO87X EeRLjLfTnCu0Q21Es75hIXPJvBwpHLyAZW5l7MsBCh/cnK+fqv10xu8MZyYZ4xcaRK V0pXrvF0fKwFEHIgI+rFz1gRCkX0A/aUcV6GDSv5n7qwnDJHd/k7wCR0fkF7/urbs7 OSupHyzqYDDSyVLrf4+ETRtRyzpjMqC2CLK2kxle3hfJT+ayoXX+YDtBAsya5Kj8o4 dXQppvu6320pw== X-Virus-Scanned: Debian amavisd-new at emo09-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo09-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJeEBwBM99e8; Wed, 8 Jun 2022 00:58:29 +0000 (UTC) Received: from localhost (m90-129-217-247.cust.tele2.se [90.129.217.247]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id AA37760E12; Wed, 8 Jun 2022 00:58:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bokr.com; s=easymail; t=1654649909; bh=yAFgcas4v//bGlAEPgEBML+mkPIbU0ytt54IrMnRLlk=; h=From:Date:To:Cc:Subject:References:In-Reply-To:From; b=TKo9ze/vhoJBHGWRf1D5Nmp29WNmqOiXnw3YfGJWI+pSy3RzTVcGEZCJPPxf5oo3I BKZPgrveVSHYZoTpdpDZWXLl1sDI8uW9Op5OsLQCDU5oayvNkh22cciACIwwmUO87X EeRLjLfTnCu0Q21Es75hIXPJvBwpHLyAZW5l7MsBCh/cnK+fqv10xu8MZyYZ4xcaRK V0pXrvF0fKwFEHIgI+rFz1gRCkX0A/aUcV6GDSv5n7qwnDJHd/k7wCR0fkF7/urbs7 OSupHyzqYDDSyVLrf4+ETRtRyzpjMqC2CLK2kxle3hfJT+ayoXX+YDtBAsya5Kj8o4 dXQppvu6320pw== From: bokr@bokr.com Date: Wed, 8 Jun 2022 02:58:09 +0200 Message-ID: <20220608005809.GA2794@LionPure> References: <878rql9wh9.fsf@gnu.org> <20220531164407.13914-1-maxim.cournoyer@gmail.com> <87o7zcwvy6.fsf_-_@gnu.org> <878rqgr0l4.fsf@gmail.com> <8735gnqkcp.fsf@gnu.org> <877d5zx9jt.fsf@gmail.com> <87v8tilrsh.fsf@gnu.org> <874k11ujqq.fsf@gmail.com> <877d5sbmjt.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <877d5sbmjt.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1654649972; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=XyBufSXEDQ7gLouzQksq9mDsfu6yeJK1RvVUw2FN+58=; b=DRyyV0SiHMbKm1FzR0BxGqQe17al5fNgLZSUrqZ0YtMf/Pr9rC3uvQpxxiN7qqddOYEFs9 UQUTkmXAUitgtV5hfZ9KSKeRUw3j37bLkXk3OWltppgdPBQw8mv6YG4ZeAotlmLkk4TAEU 3gC4ilHC6U7flfxu6SUBOzca6fpjuN5ES45zpMe9aYIhKr2799rSC7Occ+ax3+8qJaBwU1 +UZ6DB+uAwW96GDM5HnjGR8C0hBDQO5ZzUfC3tD4XJ7V1U7DT1H7k0PVVEvP/egQdjG8EI 9vQc9LSIHESNYF+JbWVbUHhh/Jpq5+rSQLaYvcSHmEavENmbQ+HormrfMIWl1w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1654649972; a=rsa-sha256; cv=none; b=oyL10mlfLGjAyotNcimfqawxsc5qnqaDxyqFuUxJZL9wNwxrrE2q0/AHu2U2zBKwUdzssK GZiZf4D/21MKLVLOfFcJwrAyTgYFjCwgaT4SLXwYGPW65bWmwBh/FGTdbG1xgo4RHBl/Bg pNLi/omB7pczjWmLNFQORmHDYwnZjq4zyV3RaB0PPEWy/pM0Ylj1KzMugAWK102uXEq0q4 ifE37XjmPO24LcPAXOCZjwVBTyWhiito5jD2YSRznSnzqbLWvcoqDu6vqzNxGkFWmjXErA r8+iZrOiKhhhCtcXQNC6FhPTrUolJ3A4RWAgEBCBlUqDdi8TJ2fWJEsxPa8ddA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=bokr.com header.s=easymail header.b="TKo9ze/v"; dkim=fail ("headers rsa verify failed") header.d=bokr.com header.s=easymail header.b="TKo9ze/v"; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 0.50 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=bokr.com header.s=easymail header.b="TKo9ze/v"; dkim=fail ("headers rsa verify failed") header.d=bokr.com header.s=easymail header.b="TKo9ze/v"; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 681B89A0B X-Spam-Score: 0.50 X-Migadu-Scanner: scn0.migadu.com X-TUID: kAg1kunWFTOg Hi, tl;dr: I hope there will be a security team discussing whether/how this kind of privileged execution interval could be exploited, and how to prevent such. E.g., could something that stealthily gets put in a finalizer for some innocent object be waiting to notice that it is running privileged, and do the next step in a dirty-work chain that sets things up nicely for e.g. remote DDOS control? Or is the independent FLOSS development process and its quality control being sabotaged stealthily with injections of "innocent mistakes" and (ultimately) trivial time-wasting bugs, making FLOSS projects look "not ready for production use" ? (despite the increasing evidence to the contrary) BTW, I think a minimalist/MES/RISCV team would be interesting! Regards, Bengt Richter On +2022-06-07 16:00:54 +0200, Ludovic Courtès wrote:gets\ > Hi! > > Maxim Cournoyer skribis: > > > Ludovic Courtès writes: > > [...] > > >>> I reviewed how that works, and it'd be easy; I just didn't see the > >>> incentive yet (there's no composition needed for the service, and it'd > >>> make the definition slightly less readable). If you tell me > >>> mark+forkexec-constructor/container is going the way of the Dodo though, > >>> that's a good enough incentive :-). > > > > That turns out to be bit problematic; dbus-daemon must not run in its > > own user namespace (CLONE_NEWUSER) as it wants to validate user/group > > IDs. That's probably the reason it was working with > > 'make-forkexec-constructor/container', as this was dropping the user and > > net namespaces, contrary to least-authority, which uses them all. > > > > The problem then seems to be that since we need CAP_SYS_ADMIN when > > dropping the user namespace, as CLONE_NEWUSER is what gives us > > superpowers. Per 'man user_namespaces': > > > > The child process created by clone(2) with the CLONE_NEWUSER flag starts > > out with a complete set of capabilities in the new user namespace. > > > > Which means that if we combine something like (untested): > > > > (make-forkexec-constructor > > (least-authority > > (list (file-append coreutils "/bin/true")) > > (mappings (delq 'user %namespaces)) > > #:user "nobody" > > #:group "nobody")) > > > > the make-forkexec-constructor will switch to the non-privileged user > > before the clone call is made, and it will fail with EPERM. > > > > When using 'make-forkexec-constructor/container', the clone(2) call > > happens before switching user, thus as 'root' in Shepherd, which > > explains why it works. > > Damnit, that’s right. For example the result of: > > (lower-object (least-authority-wrapper (file-append coreutils "/bin/uname") > #:namespaces (delq 'user %namespaces))) > > won’t run as an unprivileged user: > > --8<---------------cut here---------------start------------->8--- > $ $(guix build /gnu/store/hy8rd8p8pid67ac27dwm63svl5bqn0a1-pola-wrapper.drv) > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% > substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% > substitute: updating substitutes from 'https://guix.bordeaux.inria.fr'... 100.0% > The following derivations will be built: > /gnu/store/hy8rd8p8pid67ac27dwm63svl5bqn0a1-pola-wrapper.drv > /gnu/store/bd63i07rvvsw7xgsig0cbdsw7fpznd1k-references.drv > building /gnu/store/bd63i07rvvsw7xgsig0cbdsw7fpznd1k-references.drv... > successfully built /gnu/store/bd63i07rvvsw7xgsig0cbdsw7fpznd1k-references.drv > building /gnu/store/hy8rd8p8pid67ac27dwm63svl5bqn0a1-pola-wrapper.drv... > successfully built /gnu/store/hy8rd8p8pid67ac27dwm63svl5bqn0a1-pola-wrapper.drv > Backtrace: > 5 (primitive-load "/gnu/store/ifsh87aifh2k8pqzhkjxncq3vskpwx3l-pola-wrapper") > In ice-9/eval.scm: > 191:35 4 (_ #f) > In gnu/build/linux-container.scm: > 300:8 3 (call-with-temporary-directory #) > 397:16 2 (_ "/tmp/guix-directory.K9gBNH") > 239:7 1 (run-container "/tmp/guix-directory.K9gBNH" (#< device: "/gnu/store/jkjs0inmzhj4vsvclbf08nmh0shm7lrf-attr-2.5…> …) …) > In guix/build/syscalls.scm: > 1099:12 0 (_ 1845624849) > > guix/build/syscalls.scm:1099:12: In procedure clone: 1845624849: Operation not permitted > --8<---------------cut here---------------end--------------->8--- > > > I'm not sure how it could be fixed; it seems the user changing business > > would need to be handled by the least-authority-wrapper code? And the > > make-forkexec-constructor would probably need to detect that command is > > a pola wrapper and then avoid changing the user/group itself to not > > interfere. > > I think we would add #:user and #:group to ‘least-authority-wrapper’ and > have it call setuid/setgid. ‘make-forkexec-constructor’ doesn’t need to > be modified, but the user simply won’t pass #:user and #:group to it. > > Thanks, > Ludo’. > > >