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