From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <guix-devel-bounces+larch=yhetil.org@gnu.org>
Received: from mp1 ([2001:41d0:2:4a6f::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by ms11 with LMTPS
	id OAzZI4syE2CEMgAA0tVLHw
	(envelope-from <guix-devel-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Thu, 28 Jan 2021 21:54:19 +0000
Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp1 with LMTPS
	id 4Fi2H4syE2AhDwAAbx9fmQ
	(envelope-from <guix-devel-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Thu, 28 Jan 2021 21:54:19 +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 451209404CF
	for <larch@yhetil.org>; Thu, 28 Jan 2021 21:54:19 +0000 (UTC)
Received: from localhost ([::1]:43486 helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <guix-devel-bounces+larch=yhetil.org@gnu.org>)
	id 1l5FF4-00081T-3L
	for larch@yhetil.org; Thu, 28 Jan 2021 16:54:18 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:50294)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <leo@famulari.name>) id 1l5FEi-00081B-IA
 for guix-devel@gnu.org; Thu, 28 Jan 2021 16:53:56 -0500
Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:47553)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <leo@famulari.name>) id 1l5FEf-0001IX-WE
 for guix-devel@gnu.org; Thu, 28 Jan 2021 16:53:56 -0500
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
 by mailout.west.internal (Postfix) with ESMTP id 3114A1100;
 Thu, 28 Jan 2021 16:53:52 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
 by compute3.internal (MEProxy); Thu, 28 Jan 2021 16:53:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=famulari.name;
 h=date:from:to:cc:subject:message-id:mime-version:content-type;
 s=mesmtp; bh=SduxhBDPstqr2EP0n2qTZLpLpDxbrqyBMUoekAQXZos=; b=ZY
 JahvRcJM9ojcSjJ21NxJi9G2ZLP6mnvMQrfWyMTmJRmMqsOulmVHpJVoia8mP5BY
 CBuCzGGbJFZ2XvyT8tqouRVHjwqlrlLtwqp1dFS0lO2T8AVsKvh4kri/VxddDn2n
 YJYy8Bp8KOYnHbD8QEV+jT9iB2kF92Ebx5WtIU8gc=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:from:message-id
 :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender
 :x-me-sender:x-sasl-enc; s=fm1; bh=SduxhBDPstqr2EP0n2qTZLpLpDxbr
 qyBMUoekAQXZos=; b=ZOVPWhlW1uie46ICuez9eydP3SiVg+aUHLSSIhrSQ+iix
 PKnL2NcUIaXHsA8JxdFso+rj+lWpGIQA/fc+5DUk1l3Kc7smXWdyYlyy4nei61/1
 ocWQmo032flKe/DoCMsuLpJLkaSnpkvimgJNBqKCOwxJzuRtPDBtZ3K/7NvSTtb3
 Zw5c5NSKxbVIXGtlH9PlApgOi/N3DTchF4XoZh1XnLue8yyNA0KxMpAM01b1VP+E
 uJOzLB8ENWNiBVy2ooVe0kD2Yd+HMV5vX1IlkjyMqCztAnuuZEjvslr8bNKyVkzp
 yV5VikpbJ7m47rpihvn8QVbUUrYVTIOwxNoAOZWug==
X-ME-Sender: <xms:bzITYBfpvG_qKuuigEseREfkxXmI6wYn7c9mq8-_dTxl2fZVCkO3Zg>
 <xme:bzITYPMEBGiwz8TexiLISyZ8lg08DCRu6YZf73QL4CP7A-ow10smS30HckovQt2_L
 UpLnEAXAcTl07d6bQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtgdduhedvucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepfffhvffukfggtggusehgtderredttdejnecuhfhrohhmpefnvghoucfhrghm
 uhhlrghrihcuoehlvghosehfrghmuhhlrghrihdrnhgrmhgvqeenucggtffrrghtthgvrh
 hnpedvteegudevvdfggeefudfftdffhfelgfetkeekfeekheettdegvedtgfdttdetueen
 ucfkphepuddttddruddurdduieelrdduudeknecuvehluhhsthgvrhfuihiivgeptdenuc
 frrghrrghmpehmrghilhhfrhhomheplhgvohesfhgrmhhulhgrrhhirdhnrghmvg
X-ME-Proxy: <xmx:bzITYKjFjCcCoB3A2siXr3PUBLVMO_dpmY7VYVpsuaJlVbyB41BKbQ>
 <xmx:bzITYK-ESHx9inIRqAi6ff49KAPrgub5b1k4BppnbVKK5rkeGlHxcQ>
 <xmx:bzITYNt8rWEwZ0BFu1ejnVL2M75e1emA5TLMEj9Exya4T8jEJj8sPA>
 <xmx:bzITYC7DevvhLTNOoPgYF5wtUZx6Ovi9FATYqEPMfa4wgmEuKhCogQ>
Received: from localhost (pool-100-11-169-118.phlapa.fios.verizon.net
 [100.11.169.118])
 by mail.messagingengine.com (Postfix) with ESMTPA id 1125C1080057;
 Thu, 28 Jan 2021 16:53:51 -0500 (EST)
Date: Thu, 28 Jan 2021 16:53:49 -0500
From: Leo Famulari <leo@famulari.name>
To: guix-devel@gnu.org
Subject: Potential security weakness in Guix services
Message-ID: <YBMybeFOP0VfW6G7@jasmine.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="VkaVowxjgGd3Z3Gd"
Content-Disposition: inline
Received-SPF: pass client-ip=64.147.123.20; envelope-from=leo@famulari.name;
 helo=wout4-smtp.messagingengine.com
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 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,
 RCVD_IN_DNSWL_LOW=-0.7, 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."
 <guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
 <mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/guix-devel>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
 <mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org
Sender: "Guix-devel" <guix-devel-bounces+larch=yhetil.org@gnu.org>
X-Migadu-Flow: FLOW_IN
X-Migadu-Spam-Score: -3.45
Authentication-Results: aspmx1.migadu.com;
	dkim=fail ("headers rsa verify failed") header.d=famulari.name header.s=mesmtp header.b="ZY JahvR";
	dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=ZOVPWhlW;
	dmarc=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: 451209404CF
X-Spam-Score: -3.45
X-Migadu-Scanner: scn0.migadu.com
X-TUID: iuFsWHM0erpW


--VkaVowxjgGd3Z3Gd
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On January 19 2021, we received a message from Maxime Devos describing a
potential attack vector on Guix System.

If an attacker can exploit a remote code execution vulnerability (RCE)
in a program used by a Guix service, they could use it to take over the
system in some cases. We have not deployed any mitigations for this.

Below is a summary of their messages, including a mitigation proposal.
Your feedback is requested!

----- Forwarded message from Maxime Devos <maximedevos@telenet.be> -----
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.

As it is now, the attacker could overtake the service process, then chown
and chmod arbitrary directories from there. As a particular example, I'm
considering e.g. a hypothetical ipfs-service-type. A compromised IPFS proce=
ss
shouldn't be able to change /etc/passwd entries. The security of the IPFS
service itself shouldn't be critical to the security of the system as a
whole.
-----

A more specific exapmle:

----- Forwarded message from Maxime Devos <maximedevos@telenet.be> -----
I seem to have stumbled upon a potential security issue, it has to
do with how some services use mkdir-p/perms. For example, in knot-activatio=
n:

   (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 enoug=
h.
However, what if knot whas compromised at some point, and the compromised k=
not
process has replaced /var/lib/knot/keys with, say, a symlink to /gnu/store?
Then the next time the system the system is reconfigured, the knot-activati=
on
gexp is ran agan, and the last =E2=80=98mkdir-p/perms=E2=80=99 will chown /=
gnu/store to "knot",
and now the (compromised) knot service can manipulate the store!

Ok, this would be a security issue in knot but ideally the security hole
wouldn't =E2=80=98propagate=E2=80=99 to the whole Guix system.
-----

And in a followup:

----- Forwarded message from Maxime Devos <maximedevos@telenet.be> -----
It's also possible to create a symlink to /etc/passwd, in which case a
compromised (non-containerised) service can change /etc/passwd after
system reconfiguration -- mkdir-p/perms doesn't verify whether its
target is a directory before chowning and chmodding.
-----

And finally, a proposal:

----- Forwarded message from Maxime Devos <maximedevos@telenet.be> -----
Also, I propose a procedure to guix-security:

(define (mkdir-p/own root sub/.../dir owner bits)
  "Create ROOT/SUB/.../DIR, and its parent directories.

This procedure bails out if ROOT/SUB/.../DIR isn't owned by
OWNER. No restrictions are placed on the ownership of ROOT.
If ROOT doesn't exist, it is created with the current
uid, gid and umask. If SUB/... don't exist, they are created
with uid and gid OWNER and the current umask. If
ROOT/SUB/.../DIR doesn't exist, it is created with uid, gid
and permission bits BITS.

Symbolic links under ROOT/ are not followed."
  ... implementation)

idk if symlinks components in /ROOT should be followed.
Probably no service definition requires this, so *never*
following symlinks may also be possible? Not strictly
required for security I think, but it eases reasoning
about security properties. (Less variables to consider)
-----

--VkaVowxjgGd3Z3Gd
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmATMm0ACgkQJkb6MLrK
fwiPDBAA1Rel1HmqUL41duhwoN56JsDe7gDJUSHCyA+nKLRwyoJTdREOWs9X0PHB
M5p7QgLlcwQqmcHrnCmbpOtqrgiQP1CG48EadIcnYEQsjVtNFpb+WvnKjhnPzcqD
7M655rD20aI2RBCoenc7a1hh/GAIgLx2Fm5UtYXaojvdrocKnD7ifbwmAVWcStkc
R0OqYCGzvHo/8GDVMnPhui6/kZL0ZProqUSrNYnjbg5xsXsjW65Hpu+Wv56OCyKo
2ZUxPKsgiFKwxJTkSpVMctoIiDHV7M8wlDIL5FNIuFaEa6MwUNxGNXtg8zP9DVUn
KK5S7YXcChvXT+/OKSvy4/lcxf6P0sl0Nt3FV/dvvMS3CyUuAyzLntwh+evsbn/A
szRtnVaaPMPxw7nMtjlk2kjP10O7UJJGO/XiHO+nINQ0QUcERCOp1cI4qIwfyjai
XrlCCYY7JgZ0+YdN7WpVrbFkPWHZWxHEBpdlZctYEEa8fkmHJnaIT/jN3pwHxcDF
a1yV6ktxfbWlDeQ1tGZlyH1evEj8L6fGb6W37tJNsk65EyaewCEdH4A02cDVzHMC
e1ooqg5vDjq2IZxeIVhoT5GYZdtCc2yJD4+Peb8Z7v1vbRmQwMqLXFazqt0G22tQ
CZa3BEdsD4M7rAKVAbb7VDnDdM/ZWHGPq9OkrWOtJ28B6DZpKhE=
=bALF
-----END PGP SIGNATURE-----

--VkaVowxjgGd3Z3Gd--