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