On Sat, Apr 14, 2001 at 03:06:09PM +0200, J.A. Bezemer wrote:
> That's because APT (and ONLY apt) is effectively changing the very definition
> of "Packages file". Up to this moment:
> Packages = file that is an index to all packages (virtually) available
> in&under current directory
> But you want to change that into:
> Packages = file that contains security information on packages that either
> are, or are not, available in&under current directory
This isn't quite accurate.
The Packages file authenticates a set of .debs: that's why it includes
a bunch of md5sums. If you trust a Packages file appropriately, you can
extend that trust to the .debs it references.
It's important to be able to trust Packages files because you'll use the
information in them to decide what sort of things you'll install on your
system. If the Packages file says dpkg and gnome conflict, then you won't
try to install them whether they really conflict or not. So it's important
to be able to trust Packages files.
Unfortunately, it's difficult to work out if you can trust a Packages
file. At the moment you have to trust that ftp-master.d.o hasn't been
hacked since the last official release was made, that none of the mirrors
between you and ftp-master are malicious, and that your network hasn't
been subverted and that you are actually downloading from the mirror
you think you are.
Looking at things from the other end, most people using Debian are
probably willing to trust "Debian" as a whole, as represented by, say,
the RM and the security team. So we can probably setup some well known
public keys, with a private key known to the RM and a private key known
to someone on the security team, and we can then use these keys to
authenticate all the copious Packages files we have.
At a minimum, the RM will have to look over the entire distribution,
content himself that's it's as good as he likes, and then sign all the
Packages files in it. That's not particularly easy, but it's something the
RM has to do anyway as the distro gets frozen and stabilised for release.
The Release file format is essentially straight from Conectiva's RPM port
of Apt, with some extra comments added in, describing the release a whole
so that the meaning of the signature can be verified.
That's what we've got at the minute, and it's enough for a user installing
over the net who trusts the RM signature to extend that trust to every
.deb in the stable release. It's managable, it's reliable (ttbomk), and
doesn't put much of a burden on anyone.
What would be nice is to automatically extend this to supporting CDs as
well. It's undesirable to increase the RM's workload (by making him have to
look at CD's when they're half built to verify the Packages are correct),
and doesn't seem desirable to require people to have to trust the people
who're doing the CD builds if it can possibly be avoided.
What we'd like is effortless end to end security.
> > You'll have to fiddle around and switch it
> > off via some-means-not-yet-determined.
> You haven't even thought of that aspect, have you? I'm starting to think that
> you didn't think of _any_ aspect carefully enough.
Anne, take a pill.
> Generalizing: I think the autentication sequence should be like this for
> _any_ medium (cdrom,file,ftp,http,whatever):
> Release/Release.gpg
> |
> Packages.complete
> |
> Packages
> |
> .deb file
Instead of changing the name of the Packages file, how about we try something
completely different?
If you structure the CDs something like this:
pool/ ...
(as you'd think)
dists/ woody/
binary-i386/
Packages
Packages.gz
Release
(generated as you do now, with a Release file generated based
on the file in the archive, with the MD5Sums removed and
replaced by the md5sums of the Packages/Sources files on
the CD)
dists/ woody-secured/
binary-i386/
Packages
Packages.gz
Release
(copied straight from the archive, verbatim; the Packages
file should safely reference .debs in either pool/ or
dists/woody (or dists/potato, maybe), so this directory
should just be a couple of extra MB, and not affect anyone
else at all)
That should be pretty easy to do right now, and shouldn't cause any
problems to anyone, right? All you're doing is creating a new directory
that no one has to look at, and adding a Release file in dists/woody/
that'll make debootstrap work.
Does that sound plausible? We (well, you :) can probably do the above,
and we can postpone the rest of this at least until we can demonstrate
that apt-cdrom works properly, and see what other stuff is worth doing.
Eventually, we might consider switching it to:
dists/ woody/ (copied from archive)
dists/ woody-cd#1/ (w/ Packages files generated by the CD scripts)
But we don't need to decide on that now.
> with the special case that Packages.complete may be omitted if it is
> exactly the same as Packages. I know this is a "radically" different way to
> view things, but if you had looked at it this way from the very beginning,
> there wouldn't have been any problem, would there?
Like I said elsewhere, that suggestion would've made the CDs and the
mirrors different from a security standpoint, which is probably as bad
as having them different from a usability standpoint.
> (Except for the filenames, that as I said, don't matter. I even wonder why the
> Packages.gz-s are mentioned in the Release file, because it's the _contents_
> that matter and not the unzipped/gzip/bzip2/Xzip -1...-9 format it's
> distributed in.)
The filenames listed in the Release file should at least match the real
filenames. Whether they match them before or after any encoding we might
do doesn't really matter so much, afaict. That MD5sums of the ungzipped
stuff is slightly harder to generate is the only reason it's as it is.
> > > And lastly, anyone with hostile intentions can easily make/ship a CD which
> > > contains a modified apt that doesn't check signatures at all. End-to-end
> > There is a fairly direct means to validate the CD against the web-of-trust
> Yes of course there is. What I said was that a piece (or collection) of
> software fundamentally CANNOT authenticate itself. It must be authenticated by
> the user doing every algorithm manually, or using trusted programs that do NOT
> come from the software(collection) that is to be checked.
Right, which is why we want the algorithm to be as simple as possible.
Step 0: verify to your satisfaction that your system hasn't been rooted.
Step 1: check your Release.gpg signature matches your Release file.
Step 2: point apt at your Release file install stuff
Or, alternatively (if you don't have Debian installed yet):
Step 2: check that the boot-floppies you're about to use match the md5sum
that's hypothetically listed in the Release file
Step 3: boot from the boot-floppies, rely on them to not trust anything
until they've verified it based on the Release file they're seeing
> This essentially means that APT checking authentication provides a _false_
> sence of security.
That's not true, and we're already putting a fair bit of effort into
guarding against it. You do have to take some care, though.
So anyway, how does the above idea (two woody trees in dists),
sound? Workable, or are there other problems?
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpV6tJJzGZwl.pgp
Description: PGP signature