Re: Requirements of the tool (dpkg) support for signed packages
This message is going to be very detailed but not particularly
complete. See also my other message.
So far I've seen three very distinct kinds of aim:
(a) Expert user has a .deb and knows which maintainers to trust, and
just wants to check the signature somehow. This is an easy problem to
solve, but I don't think it buys us very much. For example, they
could just archive debian-[devel-]changes and use the .changes file.
(b) `Automatic' signature checking to provide package integrity for
users who don't want to get into details of security checking. I.e.,
the system automatically decides whether a .deb is OK to install.
(c) Preventing attacks by corrupted mirrors (either attacks where you
install a wrong package, or just random corruption).
I think we should aim for (b) and (c).
(c) is moderately straightforward: we just have a key which is owned
by the maintenance scripts on master which we sign the various output
files with. I think it's clearly a good idea and at least the signing
can be implemented quickly and easily. Checking at package install
time is much harder (see below). Better perhaps to do the check when
you build a local mirror.
(b) is harder. There are a number of problems, some of them related:
* We have no policy about (let alone formal record of) who may upload
a particular package.
* At least some developers' machines will be easy to crack. We want
to confine the effects of these compromises: we must both limit the
effects to users who install the relevant packages, and also limit the
effect in time.
* Often forcing a user to install a genuine but outdated .deb is
pretty much as effective an attack as providing a completely bogus
replacement package. We must prevent an attacker from rolling back
the user's view of the system.
* CD-ROMs need to keep working basically forever.
* We don't have any good central place to keep our master keys secure.
* master is very accessible - not the softest of targets on the net,
but we don't want to make attacking it very fruitful.
Based on this I think that to automatically install a package we need
to provide certification of at least the following facts:
(i) The developer issued the package.
(ii) The developer was a developer, and their key wasn't (yet)
compromised, when they issued the package.
(iii) The developer is authorised to upload that package somehow.
(iv) The FTP site management systems accepted the package into the
archive and haven't accepted any later version since.
(v) In the case of a release (most important case), the release
contained _this version_ of the package.
I think that leads to something like the following:
Local hard disk contains root keys
At setup of whole system:
root key is actually 5 keys, of which any 3 are considered `valid'
root certifies KR-maint
certifies dinstall
certifies mastercron (for indices like md5sums)
certifies [N]MU-approval (a team to approve NMUs)
certifies RA (for revocation)
When a developer is enrolled:
KR-maint certifies Developer
When developer acquires package, or their intent to NMU is approved
somehow:
[N]MU-approval certifies Developer + package-name + expiry
When new version of a package is ready:
Developer certifies .deb
and attaches certs from KR-maint and [N]MU-approval
(and submits RA cert req to RA when uploading)
RA certifies Developer unrevoked
RA certifies [N]MU-approval cert unrevoked
(and sends these into upload queue)
Daily
RA certifies dinstall unrevoked
RA certifies mastercron unrevoked
When all parts ready in upload queue and approved by dinstall:
dinstall certifies .deb
attaches its own daily RA cert
Daily
mastercron scripts verify .deb signatures in passing
mastercron scripts sign their output and attach own RA cert
When a developer or dinstall or mastercron lose their key, the RA is
informed.
When a root key is lost, or the set of root key holders changes,
a new set of root keys is generated. The old root keys are used once
to certify the new set, and are then destroyed.
During install, I think that the user will have to be presented with
the release date on screen, eg:
Security - Up-To-Date Check
---------------------------
This Debian release was made at 18:00 UTC on 30th February 1976.
This was approximately 24 years ago.
Please confirm that this is what you expected.
If this release is older than you expected it may be because
(a) the mirror or CD you are installing from is out of date, or
(b) someone is trying to break into your computer.
In either of these cases you should NOT continue the install. Please
find a more up to date and reliable source for your installation.
<OK> <Abort> <OK and never ask again - very unwise!>
Or, alternatively
Security - Unreleased Distribution Warning and Date Check
---------------------------------------------------------
You are installing from an UNRELEASED Debian distribution.
The files you will be installing are those which were on the main
Debian master site at 18:00 UTC on 30th February 1976.
This was approximately 24 years ago.
Please confirm that this is what you expected. If it is not you
should abort the installation and find a more up to date source.
Note that it is not possible to do a complete set of security checks
on packages from unreleased distributions.
<OK> <Abort> <OK and never ask again - very unwise!>
Then old CDs will continue to work.
Ian.
Reply to: