]>
Commit | Line | Data |
---|---|---|
d2793259 MV |
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 | ||
0c1a7101 DK |
8 | <!ENTITY % aptverbatiment SYSTEM "apt-verbatim.ent"> |
9 | %aptverbatiment; | |
10 | ||
d2793259 MV |
11 | ]> |
12 | ||
13 | <refentry> | |
14 | &apt-docinfo; | |
15 | ||
16 | <refmeta> | |
17 | <refentrytitle>apt-secure</refentrytitle> | |
18 | <manvolnum>8</manvolnum> | |
f0599b9c | 19 | <refmiscinfo class="manual">APT</refmiscinfo> |
d2793259 MV |
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 | |
5f4331c4 | 74 | trust the archive maintainer. It's the archive maintainer |
d2793259 MV |
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 | |
5f4331c4 | 100 | once a year) and distributed through the FTP server. This key is |
d2793259 MV |
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 | |
6141cfe0 | 127 | mirror host and modify the files in it to propagate malicious |
d2793259 MV |
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 | |
fe0f7911 DK |
151 | and verify the <filename>InRelease</filename> or <filename>Release.gpg</filename> |
152 | files from the archives you have configured. | |
d2793259 MV |
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> | |
5f4331c4 DK |
163 | <listitem><para><emphasis>Create a toplevel Release |
164 | file</emphasis>, if it does not exist already. You can do this | |
d2793259 | 165 | by running <command>apt-ftparchive release</command> |
e3a1f08d | 166 | (provided in apt-utils).</para></listitem> |
d2793259 | 167 | |
5f4331c4 | 168 | <listitem><para><emphasis>Sign it</emphasis>. You can do this by running |
fe0f7911 | 169 | <command>gpg --clearsign -o InRelease Release</command> and |
d2793259 MV |
170 | <command>gpg -abs -o Release.gpg Release</command>.</para></listitem> |
171 | ||
5f4331c4 | 172 | <listitem><para><emphasis>Publish the key fingerprint</emphasis>, |
d2793259 MV |
173 | that way your users will know what key they need to import in |
174 | order to authenticate the files in the | |
175 | archive.</para></listitem> | |
176 | ||
177 | </itemizedlist> | |
178 | ||
179 | <para>Whenever the contents of the archive changes (new packages | |
180 | are added or removed) the archive maintainer has to follow the | |
181 | first two steps previously outlined.</para> | |
182 | ||
183 | </refsect1> | |
184 | ||
185 | <refsect1><title>See Also</title> | |
186 | <para> | |
2f493cc6 | 187 | &apt-conf;, &apt-get;, &sources-list;, &apt-key;, &apt-ftparchive;, |
d2793259 MV |
188 | &debsign; &debsig-verify;, &gpg; |
189 | </para> | |
190 | ||
e3a1f08d | 191 | <para>For more background information you might want to review the |
d2793259 MV |
192 | <ulink |
193 | url="http://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html">Debian | |
194 | Security Infrastructure</ulink> chapter of the Securing Debian Manual | |
195 | (available also in the harden-doc package) and the | |
196 | <ulink url="http://www.cryptnet.net/fdp/crypto/strong_distro.html" | |
197 | >Strong Distribution HOWTO</ulink> by V. Alex Brennen. </para> | |
198 | ||
199 | </refsect1> | |
200 | ||
201 | &manbugs; | |
202 | &manauthor; | |
203 | ||
c3f389d0 MV |
204 | <refsect1><title>Manpage Authors</title> |
205 | ||
2ac470e1 MV |
206 | <para>This man-page is based on the work of Javier Fernández-Sanguino |
207 | Peña, Isaac Jones, Colin Walters, Florian Weimer and Michael Vogt. | |
c3f389d0 MV |
208 | </para> |
209 | ||
210 | </refsect1> | |
211 | ||
212 | ||
d2793259 MV |
213 | </refentry> |
214 |