| 1 | <?xml version="1.0" encoding="utf-8" standalone="no"?> |
| 2 | <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" |
| 3 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ |
| 4 | <!ENTITY % aptent SYSTEM "apt.ent"> %aptent; |
| 5 | <!ENTITY % aptverbatiment SYSTEM "apt-verbatim.ent"> %aptverbatiment; |
| 6 | <!ENTITY % aptvendor SYSTEM "apt-vendor.ent"> %aptvendor; |
| 7 | ]> |
| 8 | |
| 9 | <refentry> |
| 10 | <refentryinfo> |
| 11 | &apt-author.jgunthorpe; |
| 12 | &apt-author.team; |
| 13 | &apt-email; |
| 14 | &apt-product; |
| 15 | <!-- The last update date --> |
| 16 | <date>2012-06-09T00:00:00Z</date> |
| 17 | </refentryinfo> |
| 18 | |
| 19 | <refmeta> |
| 20 | <refentrytitle>apt-secure</refentrytitle> |
| 21 | <manvolnum>8</manvolnum> |
| 22 | <refmiscinfo class="manual">APT</refmiscinfo> |
| 23 | </refmeta> |
| 24 | |
| 25 | <!-- NOTE: This manpage has been written based on the |
| 26 | Securing Debian Manual ("Debian Security |
| 27 | Infrastructure" chapter) and on documentation |
| 28 | available at the following sites: |
| 29 | http://wiki.debian.net/?apt06 |
| 30 | http://www.syntaxpolice.org/apt-secure/ |
| 31 | http://www.enyo.de/fw/software/apt-secure/ |
| 32 | --> |
| 33 | <!-- TODO: write a more verbose example of how it works with |
| 34 | a sample similar to |
| 35 | http://www.debian-administration.org/articles/174 |
| 36 | ? |
| 37 | --> |
| 38 | |
| 39 | |
| 40 | <!-- Man page title --> |
| 41 | <refnamediv> |
| 42 | <refname>apt-secure</refname> |
| 43 | <refpurpose>Archive authentication support for APT</refpurpose> |
| 44 | </refnamediv> |
| 45 | |
| 46 | <refsect1><title>Description</title> |
| 47 | <para> |
| 48 | Starting with version 0.6, <command>apt</command> contains code |
| 49 | that does signature checking of the Release file for all |
| 50 | archives. This ensures that packages in the archive can't be |
| 51 | modified by people who have no access to the Release file signing |
| 52 | key. |
| 53 | </para> |
| 54 | |
| 55 | <para> |
| 56 | If a package comes from a archive without a signature, or with a |
| 57 | signature that apt does not have a key for, that package is |
| 58 | considered untrusted, and installing it will result in a big |
| 59 | warning. <command>apt-get</command> will currently only warn |
| 60 | for unsigned archives; future releases might force all sources |
| 61 | to be verified before downloading packages from them. |
| 62 | </para> |
| 63 | |
| 64 | <para> |
| 65 | The package frontends &apt-get;, &aptitude; and &synaptic; support this new |
| 66 | authentication feature. |
| 67 | </para> |
| 68 | </refsect1> |
| 69 | |
| 70 | <refsect1><title>Trusted archives</title> |
| 71 | |
| 72 | <para> |
| 73 | The chain of trust from an apt archive to the end user is made up of |
| 74 | several steps. <command>apt-secure</command> is the last step in |
| 75 | this chain; trusting an archive does not mean that you trust its |
| 76 | packages not to contain malicious code, but means that you |
| 77 | trust the archive maintainer. It's the archive maintainer's |
| 78 | responsibility to ensure that the archive's integrity is preserved. |
| 79 | </para> |
| 80 | |
| 81 | <para>apt-secure does not review signatures at a |
| 82 | package level. If you require tools to do this you should look at |
| 83 | <command>debsig-verify</command> and |
| 84 | <command>debsign</command> (provided in the debsig-verify and |
| 85 | devscripts packages respectively).</para> |
| 86 | |
| 87 | <para> |
| 88 | The chain of trust in Debian starts when a maintainer uploads a new |
| 89 | package or a new version of a package to the Debian archive. In |
| 90 | order to become effective, this upload needs to be signed by a key |
| 91 | contained in the Debian Maintainers keyring (available in |
| 92 | the debian-keyring package). Maintainers' keys are signed by |
| 93 | other maintainers following pre-established procedures to |
| 94 | ensure the identity of the key holder. |
| 95 | </para> |
| 96 | |
| 97 | <para> |
| 98 | Once the uploaded package is verified and included in the archive, |
| 99 | the maintainer signature is stripped off, and checksums of the package |
| 100 | are computed and put in the Packages file. The checksums of all of the |
| 101 | Packages files are then computed and put into the Release file. The |
| 102 | Release file is then signed by the archive key for this &keyring-distro; release, |
| 103 | and distributed alongside the packages and the Packages files on |
| 104 | &keyring-distro; mirrors. The keys are in the &keyring-distro; archive keyring |
| 105 | available in the &keyring-package; package. |
| 106 | </para> |
| 107 | |
| 108 | <para> |
| 109 | End users can check the signature of the Release file, extract a checksum |
| 110 | of a package from it and compare it with the checksum of the package |
| 111 | they downloaded by hand - or rely on APT doing this automatically. |
| 112 | </para> |
| 113 | |
| 114 | <para>Notice that this is distinct from checking signatures on a |
| 115 | per package basis. It is designed to prevent two possible attacks: |
| 116 | </para> |
| 117 | |
| 118 | <itemizedlist> |
| 119 | <listitem><para><literal>Network "man in the middle" |
| 120 | attacks</literal>. Without signature checking, malicious |
| 121 | agents can introduce themselves into the package download process and |
| 122 | provide malicious software either by controlling a network |
| 123 | element (router, switch, etc.) or by redirecting traffic to a |
| 124 | rogue server (through ARP or DNS spoofing |
| 125 | attacks).</para></listitem> |
| 126 | |
| 127 | <listitem><para><literal>Mirror network compromise</literal>. |
| 128 | Without signature checking, a malicious agent can compromise a |
| 129 | mirror host and modify the files in it to propagate malicious |
| 130 | software to all users downloading packages from that |
| 131 | host.</para></listitem> |
| 132 | </itemizedlist> |
| 133 | |
| 134 | <para>However, it does not defend against a compromise of the |
| 135 | Debian master server itself (which signs the packages) or against a |
| 136 | compromise of the key used to sign the Release files. In any case, |
| 137 | this mechanism can complement a per-package signature.</para> |
| 138 | </refsect1> |
| 139 | |
| 140 | <refsect1><title>User configuration</title> |
| 141 | <para> |
| 142 | <command>apt-key</command> is the program that manages the list |
| 143 | of keys used by apt. It can be used to add or remove keys, although |
| 144 | an installation of this release will automatically contain the |
| 145 | default Debian archive signing keys used in the Debian package |
| 146 | repositories. |
| 147 | </para> |
| 148 | <para> |
| 149 | In order to add a new key you need to first download it |
| 150 | (you should make sure you are using a trusted communication channel |
| 151 | when retrieving it), add it with <command>apt-key</command> and |
| 152 | then run <command>apt-get update</command> so that apt can download |
| 153 | and verify the <filename>InRelease</filename> or <filename>Release.gpg</filename> |
| 154 | files from the archives you have configured. |
| 155 | </para> |
| 156 | </refsect1> |
| 157 | |
| 158 | <refsect1><title>Archive configuration</title> |
| 159 | <para> |
| 160 | If you want to provide archive signatures in an archive under your |
| 161 | maintenance you have to: |
| 162 | </para> |
| 163 | |
| 164 | <itemizedlist> |
| 165 | <listitem><para><emphasis>Create a toplevel Release |
| 166 | file</emphasis>, if it does not exist already. You can do this |
| 167 | by running <command>apt-ftparchive release</command> |
| 168 | (provided in apt-utils).</para></listitem> |
| 169 | |
| 170 | <listitem><para><emphasis>Sign it</emphasis>. You can do this by running |
| 171 | <command>gpg --clearsign -o InRelease Release</command> and |
| 172 | <command>gpg -abs -o Release.gpg Release</command>.</para></listitem> |
| 173 | |
| 174 | <listitem><para><emphasis>Publish the key fingerprint</emphasis>, |
| 175 | that way your users will know what key they need to import in |
| 176 | order to authenticate the files in the |
| 177 | archive.</para></listitem> |
| 178 | |
| 179 | </itemizedlist> |
| 180 | |
| 181 | <para>Whenever the contents of the archive change (new packages |
| 182 | are added or removed) the archive maintainer has to follow the |
| 183 | first two steps outlined above.</para> |
| 184 | |
| 185 | </refsect1> |
| 186 | |
| 187 | <refsect1><title>See Also</title> |
| 188 | <para> |
| 189 | &apt-conf;, &apt-get;, &sources-list;, &apt-key;, &apt-ftparchive;, |
| 190 | &debsign;, &debsig-verify;, &gpg; |
| 191 | </para> |
| 192 | |
| 193 | <para>For more background information you might want to review the |
| 194 | <ulink |
| 195 | url="http://www.debian.org/doc/manuals/securing-debian-howto/ch7">Debian |
| 196 | Security Infrastructure</ulink> chapter of the Securing Debian Manual |
| 197 | (available also in the harden-doc package) and the |
| 198 | <ulink url="http://www.cryptnet.net/fdp/crypto/strong_distro.html" |
| 199 | >Strong Distribution HOWTO</ulink> by V. Alex Brennen. </para> |
| 200 | |
| 201 | </refsect1> |
| 202 | |
| 203 | &manbugs; |
| 204 | &manauthor; |
| 205 | |
| 206 | <refsect1><title>Manpage Authors</title> |
| 207 | |
| 208 | <para>This man-page is based on the work of Javier Fernández-Sanguino |
| 209 | Peña, Isaac Jones, Colin Walters, Florian Weimer and Michael Vogt. |
| 210 | </para> |
| 211 | |
| 212 | </refsect1> |
| 213 | |
| 214 | |
| 215 | </refentry> |
| 216 | |