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