From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 kDetHJaQI2ATYAAA0tVLHw (envelope-from ) for ; Wed, 10 Feb 2021 07:51:50 +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 KNV2GJaQI2DKVgAAbx9fmQ (envelope-from ) for ; Wed, 10 Feb 2021 07:51:50 +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 315649402A2 for ; Wed, 10 Feb 2021 07:51:50 +0000 (UTC) Received: from localhost ([::1]:33814 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9kHt-0007Qf-6Y for larch@yhetil.org; Wed, 10 Feb 2021 02:51:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60738) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9kHc-0007PG-DI for guix-devel@gnu.org; Wed, 10 Feb 2021 02:51:32 -0500 Received: from mira.cbaines.net ([2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27]:56461) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9kHZ-0002PT-Tj for guix-devel@gnu.org; Wed, 10 Feb 2021 02:51:32 -0500 Received: from localhost (unknown [IPv6:2a02:8010:68c1:0:8ac0:b4c7:f5c8:7caa]) by mira.cbaines.net (Postfix) with ESMTPSA id CC13627BC23; Wed, 10 Feb 2021 07:51:26 +0000 (GMT) Received: from capella (localhost [127.0.0.1]) by localhost (OpenSMTPD) with ESMTP id 012f14eb; Wed, 10 Feb 2021 07:51:26 +0000 (UTC) References: <461926c3d053474dd7196c9ed8f59a45b8c9c82f@hey.com> User-agent: mu4e 1.4.14; emacs 27.1 From: Christopher Baines To: Ryan Prior Subject: Re: Mitigating "dependency confusion" attacks on Guix users In-reply-to: <461926c3d053474dd7196c9ed8f59a45b8c9c82f@hey.com> Date: Wed, 10 Feb 2021 07:51:23 +0000 Message-ID: <871rdobbt0.fsf@cbaines.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2a01:7e00:e000:2f8:fd4d:b5c7:13fb:3d27; envelope-from=mail@cbaines.net; helo=mira.cbaines.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -4.46 Authentication-Results: aspmx1.migadu.com; dkim=none; 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: 315649402A2 X-Spam-Score: -4.46 X-Migadu-Scanner: scn1.migadu.com X-TUID: oCnb7iUO8JRC --=-=-= Content-Type: text/plain Ryan Prior writes: > However, I'm still thinking about how to attack Guix users. Somebody who > adds an internal channel for their own packages could still be > vulnerable to a dependency confusion attack via a compromised or > manipulated Guix maintainer. The target of the attack could install > packages they believed would be provided by their internal channel but > actually get another package provided upstream. > > The degree of vulnerability increases further with each channel used, > with each channel maintainer becoming another potential vector of > compromise. How can we make this kind of attack even more difficult? > > What comes to my mind is that we should encourage (require?) people to > specify the channel name a package belongs to, if it's not the "guix" > channel. So instead of referring to "python-beautifulsoup4" (ambiguous: > is this from my channel or upstream Guix?) we say that "python- > beautifulsoup4" always means that package from the "guix" channel and a > version provided by my channel called "internal" needs to be called for > explicitly, like "@internal/python-beautifulsoup4". I'm not sure you can escape trusting the collection of channels you're using. Because channels are code that's expected to interact, I'm not sure it's easy to target a single package from a specific channel, and expect that this provides some security. A malicious channel could simply reach out and modify the state in modules from a different channel, which would circumvent the protection you're suggesting. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmAjkHtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh aW5lcy5uZXQACgkQXiijOwuE9XflhQ//Y1z6HveesXyYS3yPBJsluepINPknGngM H22KXzKPWcSuUbWYDzCPrH5zqINepUY9UBX7ULRlHzGLDybFUheYbJddWImAvTZX /AI5XO+xWllPHuwoxHjrhIq0LDCtDbRnaF0eJC3knGY7Yf17w41fpTUugYpRT56f N04DYb/aLjZA2YGKw7ACiN3dMR18dqhVOaZSdp3lwczzJCoV73v70ayOkxICBzyt VnP4B37V2BBB3Xwztt/4DeIV5u8M2PPOmTyGt8zqLnV+oyt9bBk65cBro2fFab8F u9UgPcnGoNzXaocAZl4xMykH3nidqR2tj0R0Pv+Czg3y5pa7tsnV+ksgIARnGg3T gvBpaGJc7XXkHnwY6dCAsqG0k7mvnRbc6QqPXUbZ0spgQgrXZDl7gAPqm+zNCJiQ fw13cRkkvyewrW7qJco1U6G5PHV5wFm4RkzAN6L6yJ147RWalqHpADr7D89V4bPZ KHidgMC6+nnvfelk82VnROmtG4Mz0i9ReLrGQM9geqxeoK2HxeQ0umdP2cuAMxdV aKfHMLqXS8I3ua0NKBAkRgRKjRJVxvdCpdo1dxBvswsgX0drs0StaD17nTa/eT8T xijWhZjAM3JEZNFqnDzm9EF8QurTmmjhlfAcrgxp59S8f0jXvpr805JlHWKpAA4N 3J7GITyFRYs= =kATM -----END PGP SIGNATURE----- --=-=-=--