Revival of the signed debs discussion
Hi,
after the compromise of the Debian systems verifying the archive
against compromises has been a hot topic. In this mail I will suggest
a changes that would allow any willing user to verify the debian
archive (or his local mirror thereof) against compromised files. I
will outline some means of implementing it and drawbacks that come to
mind.
A related discussion was posted in 2000 on debian-devel:
http://lists.debian.org/debian-devel/2000/debian-devel-200004/msg00245.html
So here we go, first summarizing what we have and then suggesting things.
----------------------------------------------------------------------
Currently there are three trust mechanisms at work in the Debian archive:
1. sources are signed in the dsc file and kept in pool
2. binary uploads are signed in the changes file, mailed out and
forgotten
3. Release.gpg -> Release -> Packages/Sources -> file chain of trust
I will assume gpg is secure, DDs act responsible, the user has a
trused debian keyring from somwhere (the CD he bought) and apt-secure
or similar tool is actually used to verify things. Assuming this
Debian provides some security:
- 1 and 2 ensures only a DD can upload something. Uploads are as
secure as the maintainers (also meaning buildd + buildd admin) system.
- 1 allows every user to verify the source comes from a Debian
developer.
- 3 prevents mirror-in-the-middle attack, the user can verify he gets
the files Debian released.
We have no continous trust chain going from the maintainer (also
meaning buildd + admin), ftp-master.d.o, mirrors to the user. A
compromised dinstall on master could replace binary uploads with
trojan versions without any user being able to detect it.
----------------------------------------------------------------------
Can we make a trust chain going from the source to the finished deb?
One can't proof that a binary was cleanly build from a certain source
without any compromised toolchain introducing trojans so I won't even
think about trying to make an unbroken trust chain from the source to
the deb. But every deb is signed by a DD showing that to the best of
his knowledge the build was done cleanly. That information, stored in
the changes file, would act as a per deb signature but is not
preserved in any easily accessible way.
----------------------------------------------------------------------
Deb signatures method A:
Every deb is signed through the .changes file. This information could
be kept in /pool/ along with each deb so its easily accessible and
available even if debian servers get compromised.
We are talking about 8000 packages for 11 architectures and say 2
versions of each package (stable, testing, unstable but some are the
same) with a 4K changes file each (assume 4K blocks on the FS), thats
~175K files and ~700MB data.
The huge amounts of files alone is a drawback, ftp mirrors won't like
the delay for all the small files and in general the space used on
disk will be much greater. Compression of the changes file won't help
since they still take one 4K block each.
----------------------------------------------------------------------
Deb signatures method B:
Every deb is signed through the .changes file. But instead of keeping
each changes file on its own all changes files for a source package
are tar'ed ot cat'ed together into one file.
Again using 8000 packages, 11 archs and 2 versions and a 2K changes
file each, thats 8000 files of 44Kb and ~350Mb uncompressed
data. Compressing the files would help a lot here. The changes files
of even greater groups could be cat'ed together (e.g. all sources
starting with a) but then the file would be big change very often
causing way more traffic.
This method doesn't have the drawback of method A (or not so much of
it). But managing the cat'ed changes files becomes harder. The real
chnages file could be kept and cat'ed together every time a new upload
appears for a package. Or the cat'ed file could be split and cat'ed
back together. The other drawback is that there is only one file for
each source package for stable, testing and unstable. Someone just
intrested in stable would see a lot of changes to the changes files
that don't concern him. Keeping seperate changes files for stable,
testing and unstable would solve that but tripple the number of files
and increase the waste due to blocksize noticably.
----------------------------------------------------------------------
Deb signatures method C:
And now for something completly different. A man with 3 noses. :)
Instead of keeping extra files with the signature of the deb the
information could be stored inside the deb itself. Of cause the
signature can't be contained in the thing being signed. Instead the
signature would be added to the end or the ar archive and contain
signatures for all the files (uncompressed?) before it in the archive.
>From other mails found through google it looks like adding a file like
"_deb_signature" to the end of a deb won't even break potatos dpkg.
Older debian systems would just ignore the file (consider this
hear-say, I haven't actually tried it).
The size increase would be ~1K for each deb. I guess that would mean
500-2000MB size increase. That sounds huge but, given a 25% chance of
fitting the 1K data into the last FS block, actual disk size could
increas as "little" as 125-500MB.
One drawback of this method would be the more frequent need to type
the passphrase, e.g. mozilla would need 15 signatures for an
upload. The signing program could store the passphrase for the
duration of the signing so only once per build would suffice.
Advantages of this method are that each deb is selfcontained. You can
download it from anywhere or pull it out of your apt cache and verify
it was build by the person owning the gpg key and passphrase and not
changed since. This method would also allow for multiple signatures,
i.e. a new-maintainer signed the debs and the sponsor adds his
signature after that. Also the signature can't get lost, an attacker
can't delete the changes files and let debian wonder if the debs are
untouched as with methods A and B.
The way to implement this feature would be to change debsign to add a
signature to each deb and change the .changes file acordingly before
signing that too. Changing the .changes file is neccessary to keep
existing software accepting them. debsign would ask more often for the
passphrase and the -r (remote) option would download the deb files
along with the changes and dsc files. Apart from debsign no other
software should be affected.
----------------------------------------------------------------------
What can we do with deb signatures?
For our current problem, the integrity of the debian archive being
questioned, the procedure would be easy and available to every user:
1. get any clean Debian keyring (or just the key signing the keyring)
2. verify the latest Debian keyring
3. verify that each deb was signed by a DD and the signature fits
Of cause some verification software would have to be written to
implement various verification and trust schemes (see the related
discussion above for some ideas). It would be good to know the
maintainer(s) of each package (read the admin of each buildd). Packages
signed by an unusual person (neither maintainer nor buildd admin)
could be flaged suspicious. Paranoid people could then refuse binaries
of NMUs and rather read the diff and build them locally.
----------------------------------------------------------------------
Overall signed debs would add a transparency to verifying the debian
archive that we currently don't have. Many people have asked about how
the archive was/is veryfied after the compromise and pointing them to
"apt-get install dpkg-verify; less /usr/share/doc/dpkg-verify/README"
would be a simple solution for the next time. Apt hooks could be used
by the paranoid to verify every deb before installing it to avoid a
compromised dinstall causing trojans to get installed.
But the normal user shouldn't be bothered with the signature. Testing
the Release.gpg should be(come) the default trust mechanism used to
verify downloads. Individual deb signatures would be for the parnoid
and when the next compromise arises.
Comments, suggestions, flames?
MfG
Goswin
PS: I favour method C and would esspecially like some feedback on the
technical aspect. Can a "_deb_signature" file be savely added to the
end of a deb without breaking existing tools (apt/dpkg/dinstall)?
Reply to: