From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 8J9cO6EiGGAWJQAA0tVLHw (envelope-from ) for ; Mon, 01 Feb 2021 15:47:45 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id sDAuN6EiGGBmWgAA1q6Kng (envelope-from ) for ; Mon, 01 Feb 2021 15:47:45 +0000 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 AC0769402C2 for ; Mon, 1 Feb 2021 15:47:45 +0000 (UTC) Received: from localhost ([::1]:40336 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6bQW-0007G4-G7 for larch@yhetil.org; Mon, 01 Feb 2021 10:47:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42352) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6bQK-0007Fo-3N for guix-devel@gnu.org; Mon, 01 Feb 2021 10:47:32 -0500 Received: from lepiller.eu ([2a00:5884:8208::1]:58750) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6bQH-0006pB-TX; Mon, 01 Feb 2021 10:47:31 -0500 Received: from lepiller.eu (localhost [127.0.0.1]) by lepiller.eu (OpenSMTPD) with ESMTP id a4057fc9; Mon, 1 Feb 2021 15:47:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=lepiller.eu; h=date :in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:to:from:message-id; s=dkim; bh=XOsqlNkc1+GpvShl6UBBveOIsGWoUEkLQkaNs2eVKYc=; b=YETJiNZXFauP 36WrYuRFZZa5z7TIxlH1aUbmJ4kca+ipKQ60kzuQZWUeWdKWGI5ge9JPn1k+s8uU S9XwDT3kfVKu25g/NeJmrz/MzTJR4PXdaepAlnEYX6x5quVaNAjJIp6qK1MmEj+n nfYCZa5gaPhp40lhU6BJoM6dOlMnh1sRfxTTp6eGoOmt6La62Jz5z7t77l7TwRLJ wYLphts+HKHCRhD0VxOYVRPn1Cw96HacU188M/lljje6mFpjIvfmroqCVeKLrWXU vxJIHKf6A5Q1IXIAQtNt4LZ1ECVGHcE/KIUaSv1HiyuPgncDOi7EMC84+uCgZ6sJ aqwJDeM8Fw== Received: by lepiller.eu (OpenSMTPD) with ESMTPSA id cfdb6585 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Mon, 1 Feb 2021 15:47:22 +0000 (UTC) Date: Mon, 01 Feb 2021 10:47:08 -0500 User-Agent: K-9 Mail for Android In-Reply-To: <87k0rrls0z.fsf@gnu.org> References: <87k0rrls0z.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Potential security weakness in Guix services To: guix-devel@gnu.org, =?ISO-8859-1?Q?Ludovic_Court=E8s?= , Leo Famulari , Maxime Devos From: Julien Lepiller Message-ID: <08F0CD76-DDCF-4CFA-AE8D-5FB165A62B25@lepiller.eu> Received-SPF: pass client-ip=2a00:5884:8208::1; envelope-from=julien@lepiller.eu; helo=lepiller.eu X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.26 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lepiller.eu header.s=dkim header.b=YETJiNZX; dmarc=fail reason="SPF not aligned (relaxed)" header.from=lepiller.eu (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: AC0769402C2 X-Spam-Score: -1.26 X-Migadu-Scanner: scn0.migadu.com X-TUID: LrKmFxMENCdt Le 1 f=C3=A9vrier 2021 10:35:56 GMT-05:00, "Ludovic Court=C3=A8s" a =C3=A9crit : >Hi, > >Leo Famulari skribis: > >> For clarification: the scenario I currently have in mind, is that >noone >> has intentionally introduced a security hole in a service, but rather >> there's an accidental security bug somewhere in service package, that >> allows an attacker (I'm assuming the service is accessible from the >> network) arbitrary code execution *within* the service's process=2E >> >> As it is now, the attacker could overtake the service process, then >chown >> and chmod arbitrary directories from there=2E As a particular example, >I'm >> considering e=2Eg=2E a hypothetical ipfs-service-type=2E A compromised = IPFS >process >> shouldn't be able to change /etc/passwd entries=2E The security of the >IPFS >> service itself shouldn't be critical to the security of the system as >a >> whole=2E >> ----- >> >> A more specific exapmle: >> >> ----- Forwarded message from Maxime Devos >----- >> I seem to have stumbled upon a potential security issue, it has to >> do with how some services use mkdir-p/perms=2E For example, in >knot-activation: >> >> (define (knot-activation config) >> #~(begin >> (use-modules (guix build utils)) >> (mkdir-p/perms #$(knot-configuration-run-directory config) >> (getpwnam "knot") #o755) >> (mkdir-p/perms "/var/lib/knot" (getpwnam "knot") #o755) >> (mkdir-p/perms "/var/lib/knot/keys" (getpwnam "knot") #o755) >> (mkdir-p/perms "/var/lib/knot/keys/keys" (getpwnam "knot") >#o755))) >> >> /var/lib/knot/keys/keys is chmodded and chowned, which seems innocent >enough=2E >> However, what if knot whas compromised at some point, and the >compromised knot >> process has replaced /var/lib/knot/keys with, say, a symlink to >/gnu/store? > >I=E2=80=99m not sure I understand the threat model=2E If Knot has a RCE >vulnerability, it can be exploited to run anything on behalf of the >=E2=80=98knot=E2=80=99 user=2E > >At that point, all the state associated with Knot in /var/lib should be >considered tainted; new keys should be generated, and so on=2E > >Why focus on the permissions on /var/lib/knot? My understanding is that, in case of an RCE in knot, the attacker can repl= ace /var/lib/knot/* with symlinks to arbitrary files in the FS=2E When the = activation procedure is run afterwards, the files being linked to are chown= ed to the knot user, and the attacker can access them=2E >Also, every time it=E2=80=99s possible and not redundant with measures al= ready >implemented by the daemon itself, we should consider using >=E2=80=98make-forkexec-constructor/container=E2=80=99 as a further mitiga= tion=2E > >WDYT? > >Ludo=E2=80=99=2E