From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#22883: Discussion of TUF in the context of Git checkout authentication Date: Wed, 01 Jun 2016 18:47:06 +0200 Message-ID: <87a8j4hn5h.fsf_-_@gnu.org> References: <87io14sqoa.fsf@dustycloud.org> <87h9ep8gxk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b89JP-0005Sb-4i for bug-guix@gnu.org; Wed, 01 Jun 2016 12:48:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b89JK-0001Ng-5g for bug-guix@gnu.org; Wed, 01 Jun 2016 12:48:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:37739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b89JK-0001NV-2i for bug-guix@gnu.org; Wed, 01 Jun 2016 12:48:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87h9ep8gxk.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Tue, 26 Apr 2016 00:25:11 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: 22883@debbugs.gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello! Here are some (somewhat unstructured!) thoughts about what it means to deliver secure updates to Guix users, and how The Update Framework (TUF) and related ideas can help us. To summarize, the problem we=E2=80=99re trying to solve is the =E2=80=9Csec= ure=E2=80=9D update of Git checkouts. That=E2=80=99s because Guix is a set of recipes and code= that is delivered to users/developers using Git. More specifically, we share most of the security goals listed in Sections 1.5.2 and 1.5.3 of the TUF spec=C2=B9. TUF is biased towards repositories of binary packages and associated meta-data, whereas we=E2=80=99re (1) using Git, and (2) concerned with sour= ce code authentication. Thus, some of the goals in 1.5.2 are not applicable, as we will see, and some of the roles in 2.1 are not applicable either. The OPAM folks came up with a variant of TUF=C2=B2 that takes advantage of the fact that the OPAM package repository is in a Git repo=C2=B3 (this desi= gn is not currently used by opam-repository, AFAICS). Their scheme uses detached signature files for package meta-data instead of signed commits; thus, it is not concerned with Git checkout authentication in general, but with the authentication of individual files in the repo (see the discussion of =E2=80=9Ctarget files=E2=80=9D below). Yet, there a= re good ideas applicable to our Git repo, such as the =E2=80=98signed=E2=80=99 tag create= d by a =E2=80=9Csignature bot=E2=80=9D and that clients can use to check whether t= hey get the latest version of opam-repository. The Qubes folks have their own process=E2=81=B4, not inspired by TUF. They= push signed Git tags (instead of signing commits), with roughly one signed tag every time a bunch of commits is pushed=E2=81=B5. AIUI, Qubes uses the OpenPGP web of trust to determine which keys are authorized keys: a key signed by the Qubes master key is considered authorized. IMO this is a misuse of OpenPGP, where a signature on a key is a statement of trust in (certification of) the key/email and possibly key/name bindings=E2=81=B6, a= nd has nothing to do with authorization. At the very least, it=E2=80=99s clear that: 1. Guix clients, whether =E2=80=98guix pull=E2=80=99 or =E2=80=98git pull= =E2=80=99, must be able to authenticate the history of their checkout; this is why we started signing commits. 2. We must use a mechanism such as the =E2=80=98signed=E2=80=99 Git tag d= escribed in the OPAM document so that clients can know what the latest Guix commit is. 3. We must follow the key management practices developed in TUF. Let=E2=80=99s go back to the =E2=80=9Cgoals for specific attacks to protect= against=E2=80=9D in Section 1.5.2 of the TUF spec, and see how they apply to the distribution of Guix=E2=80=99s source tree: 1. =E2=80=9CRollback attacks. Attackers should not be able to trick clie= nts into installing software that is older than that which the client previously knew to be available.=E2=80=9D As explained in the OPAM document, Git gives us linearity guarantees (=E2=80=98git pull=E2=80=99 makes sure we move forward), so= clients can be sure they move forward in Guix history. We expect clients to authenticate the Git history, making sure all the commits are signed by authorized Guix committers. To perform such an attack, an attacker would need to get access to the private key of one of the authorized committers. We can probably consider it beyond the scope of our threat model, because at this point, the attacker could do anything (like the 2nd paragraph of TUF Section 2.2 suggests) and the version string of packages is really a detail. 2. =E2=80=9CIndefinite freeze attacks. Attackers should not be able to respond to client requests with the same, outdated metadata without the client being aware of the problem.=E2=80=9D 3. =E2=80=9CEndless data attacks=E2=80=9D and =E2=80=9CSlow retrieval att= acks=E2=80=9D seem to be beyond the scope of our interests here; TUF does not seem to address them either. 4. =E2=80=9CExtraneous dependencies attacks. Attackers should not be abl= e to cause clients to download or install software dependencies that are not the intended dependencies.=E2=80=9D Not applicable: we=E2=80=99re distributing a Git source tree, not build artifacts. 5. =E2=80=9CMix-and-match attacks. Attackers should not be able to trick= clients into using a combination of metadata that never existed together on the repository at the same time.=E2=80=9D Not applicable, for the same reaons. 6. =E2=80=9CMalicious repository mirrors should not be able to prevent up= dates from good mirrors.=E2=80=9D Clients should check the age of the =E2=80=98signed=E2=80=99 tag, and = thus detect outdated mirrors. Section 2 of the TUF spec defines the notion of =E2=80=9Ctarget files=E2=80= =9D and discusses roles and the PKI. =E2=80=9CTarget files=E2=80=9D are defined as files distributed by the syst= em as commonly found in =E2=80=9Ctraditional=E2=80=9D package repos (e.g., binary= packages and associated meta-data); they are the unit of authenticable data. In Guix we want to authenticate whole checkouts, so the notion of =E2=80=9Ctarget file=E2=80=9D seems to make little sense. For instance, it= wouldn=E2=80=99t make sense to sign each gnu/packages/*.scm file individually, because the meaning of these files depends not only on the surrounding files, but also on the core of Guix, such as the (guix packages) module, which defines the very notion of =E2=80=9Cpackage=E2=80=9D. The PKI and roles described in TUF, with separate responsibilities and the ability to delegate, make a lot of sense (it=E2=80=99s similar in spiri= t to SPKI=E2=81=B7, but more limited in scope.) Some of the roles do not seem t= o be applicable to secure Git update delivery: =E2=80=A2 the =E2=80=9Ctargets=E2=80=9D role is not applicable, at least = not to individual source files; =E2=80=A2 the =E2=80=9Csnapshot=E2=80=9D role does not seem applicable (a= Git commit *is* a complete snapshot); the =E2=80=9Ctimestamp=E2=80=9D role, though, corre= sponds to the signature bot described in the OPAM document; =E2=80=A2 the optional =E2=80=9Cmirrors=E2=80=9D role doesn=E2=80=99t see= m very useful, as acknowledged by Section 2.1.5 of the TUF spec. With that in mind, we now need to see how to map the relevant bits of TUF to Guix! Comments welcome! Ludo=E2=80=99. =C2=B9 https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec= .txt =C2=B2 http://opam.ocaml.org/blog/Signing-the-opam-repository/ =C2=B3 https://github.com/ocaml/opam-repository =E2=81=B4 https://www.qubes-os.org/doc/verifying-signatures/ =E2=81=B5 See for example all the =E2=80=98mm_XXX=E2=80=99 tags at . =E2=81=B6 https://tools.ietf.org/html/rfc4880#section-5.2 =E2=81=B7 http://theworld.com/~cme/spki.txt --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXTxGPAAoJEAkLEZk9muu1If0P/iQNEwbEgwGAnYXHM00l/IZA fBDGe6AFPkbZpFOmr9r1Ww9khVa8ZlRymrvCCm74YX1nuPvU70e4/7QR+8eboQK6 3NieQKdNN9uXdBaup9snkWcVimf7ePuW4x2u0lSAbCKy25oiR/ZZOwGhK1cmiYcH ZHNv8W8Cai6V45mjlDeOdcdqp9mF0vZ/PgVUaW1EEknSGpyJmkRo2ipdkeuaPdGz PQfT3T5P5FSvExCryeXGWv5eP/RJdJKqmaK8fvAKO5YZR3xQodH9zCfL9s8NCI9c Jv0+sJp4Avi3axZFunJPocim7kzWXItk81g3uEgFAWC/cu2+6OOwfm50dB/BAZmw RFO6rA6hYP2crtrwhDZ8k2SMuQejN0fdCDA2e5aLJSDIOcQ1I0isLI5DeF9e7n5Q /DKJM8Iz50dtfDJdHRxO2yNE0o28X41YliRGYPX1FqSBadyJAOA4YJ05jMZmhaJt 7DmcW+qt94a7bMwH6B8mfj8VMTt0a7vowCGd3LzjZslTv588SIfHbMLObE4Z13wk H1JOoIz5OmN41x/FrpQ4W2sRCqdulhbl0hic2pDGWaVsYkDK5PYipTPgISz04dhq YmqjKddGqY1gkYw7/YgGpNAwqJCMVZndWjsx5lCHcg6nqDTy6yurceDLgVaVdHQV PKLcerMvIIwaglaylPGj =PM0h -----END PGP SIGNATURE----- --=-=-=--