Bug#203741: apt sigcheck patches
On Thu, 2003-08-21 at 10:16, Matt Zimmerman wrote:
> Why should it be necessary to modify sources.list to specify the vendor? I
> would have either expected this to be determined from the Release file, or
> to have a list of trusted vendors and not care which source corresponds to
> which vendor.
Well, first because you need to have some way to specify whether or not
the source is secured. You can't take the absence of the Release file
to mean it's not, for obvious reasons. And a lot of personal-type apt
sources aren't secured, and aren't likely to be anytime soon.
Secondly, because you don't want someone to be able to replace one valid
archive with another, such as replacing Debian stable (and presumably no
security holes) with Debian unstable (and presumably some nonempty set
of holes).
> It would be nice if we could do this without changing the
> syntax of sources.list, so that older apts are forward compatible.
Well, older apts are forwards compatible - they at least don't barf on
the [...] because it's been parsed by sourcelist.cc (and ignored) since
before woody.
> > I'd also like to try merging the documentation we have into the apt docs
> > at some point.
>
> That would be great; feel free to send me whatever you have.
Attached is a copy of the Docbook XML we were using for the website.
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd";[
<!ENTITY aptSecure "<application>APT Secure</application>">
]>
<article>
<articleinfo>
<title>APT Secure</title>
<author>
<firstname>Isaac</firstname>
<surname>Jones</surname>
<affiliation>
<address>ijones@syntaxpolice.org</address>
</affiliation>
</author>
<author>
<firstname>Colin</firstname>
<surname>Walters</surname>
<affiliation>
<address>walters@debian.org</address>
</affiliation>
</author>
</articleinfo>
<sect1><title>Introduction</title>
<para>&aptSecure is the working name of a project to add to <ulink
url="http://packages.debian.org/apt";>APT</ulink> the ability to
verify the authenticity of Debian packages.</para>
<para>The current version of APT and its surrounding infrastructure contain
a chain of trust which is never verified by the installing machine.
&aptSecure; fixes that problem.</para>
</sect1>
<sect1><title>Status</title>
<para>This project seems to work for simple cases, and we are providing
you with code to try it out. We'd like the community to give us
feedback about how it works and to help test and debug it. There are
certain cases which make this pre-alpha version unhappy, but we expect
it to work for most people. If it doesn't work for you, please verify
that you are, in fact, a person, and if so, contact the authors (see
below) to tell us the problem.</para>
<para>The cases where it is known to work are for the canonical
Debian <literal>sid</literal> and <literal>woody</literal> entries
for <filename>/etc/apt/sources.list</filename>. It is
known <emphasis>not</emphasis> to work currently for two-part URIs,
the <literal>experimental</literal> distribution, nor <literal>non-US</literal> or
the woody security updates.</para>
<para>Hopefully, this code will be integrated into the APT CVS
repository soon.</para>
<para>This document assumes that you have some familiarity with gpg and
encryption and stuff like that. If you don't, then you probably
shouldn't bother with this pre-alpha program, or you should read up a
little bit before bothering with it, or most importantly, before
bothering us ;)</para>
<para>Also, we should warn you that there are still some policy decisions to
be made. Correctness of policy is, of course, at least as important
as correctness of code. Some of the stuff below might change.</para>
</sect1>
<sect1><title>The Chain of Trust</title>
<para>The chain starts with the maintainer who signs and uploads her
packages. That signature is checked against the key that she uploaded
when she became an official Debian developer, which was itself
verified personally by other Debian developers.</para>
<para>Once the uploaded package is verified as having been signed
by the maintainer, an MD5 sum of the package is computed and put
in the Packages file. The MD5 sum of all of the packages files
are then computed and put into the Release file. The Release
file is then signed by the <ulink url="http">archive key</ulink>
which is created once a year and distributed by the FTP server.
This key is also on the Debian keyring.</para>
<para>In theory, therefore, the end user, having added the archive
key to his keyring, can check that
the <filename>Release</filename> file was signed by the proper
key, can check the MD5 sums of all
the <filename>Packages</filename> files, and can check the MD5
sums of all the Debian packages. The current version of APT
does in fact check the MD5 sums of the Debian packages against
those in the <filename>Packages</filename> file, but it goes no
further up the chain of trust.</para>
<para>In theory, this makes APT vulnerable to a variety of
attacks. Suffice it to say that if a malicious person can alter
any packages, then they can gain full access to the installing
machine.</para>
</sect1>
<sect1><title>Where APT Secure Comes In</title>
<para>&aptSecure; is an alteration to APT to complete this chain of
trust. With it, you can add a set of keys that you trust to
your keyring, and alter
your <filename>/etc/apt/sources.list</filename> file
accordingly. Then when you run a command
like <userinput>apt-get update</userinput>, APT will walk back
along the chain of trust for you, and freak out if something
looks suspicious. (You, in turn will freak out, and do your
best to freak out the next link in the chain.)</para>
</sect1>
<sect1><title>How it Works</title>
<para>Step zero is, of course, to install &aptSecure; (see below).</para>
<para>We'll assume that you're using Debian's official packages (and
therefore Debian's official archive key), though a similar method will
work for other sources that APT might use.</para>
<para>First, you should get Debian's <ulink url="http://ftp-master.debian.org/";>archive key</ulink>.
Import this key into a keyring at <filename>/etc/apt/trusted.gpg</filename>.
So for instance:</para>
<screen>
$ wget http://ftp-master.debian.org/ziyi_key_2003.asc
$ gpg --no-default-keyring --keyring=/etc/apt/trusted.gpg --import ziyi_key_2003.asc
</screen>
<para>Now you need a way to associate your newly imported key
with the source that you download your packages from. This is
accomplished with the help of a new file,
vendors.list<footnote><para>See <userinput>man
vendors.list</userinput> for more information.</para></footnote>. In
this file, you will be able to put the fingerprint of any keys
that you will be using to verify
the <filename>Release</filename> files. For instance,
in <filename>/etc/apt/vendors.list</filename>, you might
have:</para>
<programlisting>
simple-key "debian"
{
Fingerprint "EB2FA2AF170D235926A77BF3B629A24C38C6029A";
Name "Debian Archive Automatic Signing Key (2003) <ftpmaster@debian.org>";
}
</programlisting>
<para>The <literal>debian</literal> bit
after <literal>simple-key</literal> is like a nickname for the
key, we'll use this later. You can get the fingerprint for the newly
imported key using a command like this:</para>
<screen>
$ gpg --no-default-keyring --keyring=/etc/apt/trusted.gpg --fingerprint ftpmaster@debian.org
</screen>
<para>But get rid of the whitespace in the "Key fingerprint" output.</para>
<para>Now that you've created your <filename>vendors.list</filename> file, you
can associate this key with a particular apt source. Open up your
<filename>/etc/apt/sources.list</filename> file and change lines that
look like this:</para>
<programlisting>
deb http://ftp.debian.org/debian sid main
</programlisting>
<para>to instead look like this:</para>
<programlisting>
deb [debian] http://ftp.debian.org/debian sid main
</programlisting>
<para>That <literal>[debian]</literal> part maps to the key nickname
that we mentioned above. This source
(<literal>ftp.debian.org</literal>) will now be authenticated with APT
Secure, to your unending joy. Sources which aren't prefixed by a key
identifier will not be authenticated. So if you do not change
your <filename>sources.list</filename> file, then Secure APT should
behave pretty much like APT.</para>
<para>Did I mention that you have to install &aptSecure;?</para>
</sect1>
<sect1><title>Installation</title>
<para>Patched Debian <literal>apt</literal> packages can be
acquired by adding the following to your
<filename>/etc/apt/sources.list</filename>:</para>
<programlisting>
deb http://monk.debian.net/debian/ unstable/
</programlisting>
<para>Or if you're running woody:</para>
<programlisting>
deb http://monk.debian.net/debian/ woody/
</programlisting>
<para>
Since this will replace your current <literal>apt</literal> packages,
you may want to keep the older packages around.
</para>
<para>
If you're just interested in the patches, you can download
them <ulink url="http://monk.debian.net/apt-secure/patches/";>here</ulink>.
</para>
</sect1>
<sect1><title>What does this mean for people who distribute packages?</title>
<para>This will require no change for Debian maintainers. They've already
done their bit by getting their keys into Debian's keyring.</para>
<para>For now, even those who want to create their own apt sources don't
have to change anything until you want your sources to be
authenticated, in which case you'll have to generate and sign Release
files, and find a secure way to distribute your key. Someday, APT
might force all sources to be verified, but those kinds of policy
decisions have not yet been made.</para>
</sect1>
<sect1><title>Authors</title>
<para>This code is a smallish change to a largeish program, so of course the
original authors deserve credit. Also, a similar thing has been
implemented by Connectiva in their fork of APT, and we used a small
amount of their code.</para>
<para>Having said that, the current version of &aptSecure; was implemented by
<ulink url="mailto:walters@debian.org";>Colin Walters</ulink> and
<ulink url="mailto:ijones@syntaxpolice.org";>Isaac Jones</ulink>.</para>
</sect1>
</article>
Reply to: