Re: Signing Packages.gz
Hi Anthony,
On Mon, Mar 27, 2000 at 08:37:10AM +1000, Anthony Towns wrote:
> On Sun, Mar 26, 2000 at 04:02:20PM +0200, Marcus Brinkmann wrote:
> > On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote:
> > > The whole file --- verifying each entry would take at least three minutes
> > > on my hardware, and god knows how long on anything moderately old or
> > > outdated. I certainly wouldn't want to try it on m68k on a regular basis,
> > > eg. (If doing something just once takes a second; doing it 4000 times
> > > takes a bit over an hour)
> > I don't think it is useful to sign the Packages file, because:
>
> A signature authenticates the source of a document. That's worthwhile,
> since verifying the source of a Packages file lets you transitively
> verify the source of all the packages in a distribution.
This is true if the signature is made in a secure manner. Storing the key on
a medium that is available by dinstall is not secure, because a compromise
of dinstall or higher instances (master etc) will reveal the secret key.
> > > Whose key should be used? Probably a special one just for dinstall,
> > > that's kept fairly securely by the Novare and -admin folks, and revoked
> > > regularly.
> > Any such key would have to be considered insecure, no matter how soon you
> > revoke it. So the paranoid people still don't trust it, and the other don't
> > care (probably).
>
> Nonsense.
>
> The only reason not to trust a key dinstall uses explicitly for signing
> Packages is if you believe dinstall is compromised. If you believe that,
> then you shouldn't be downloading .deb's *ever*, because you're immediately
> running *untrusted* scripts as root on your systems.
So you agree with me. What exactly do you think is "nonsense"?
> If dinstall *isn't* compromised, it's still possible that your favourite
> FTP site is, in which case all they need to do to compromise your machine
> is replace a .deb with their own hacked version and let you download it.
Yes, and I can decide if I should trust this package at installation time.
I can base this decision on the keys in the Debian keyring package, and further
information I get from the Debian web site etc.
In your model, I can not perform these further tests. I would have to trust
dinstall (and higher instances) completely, or loose.
> Automatically signing things is less secure than manually signing things,
It is only as secure as dinstall/master is, so we gain nothing at all by your
suggestion. Here is a huge difference between your and my suggestion. What I
proposed has problems (and I will address the problems you raised below),
but it is a real improvement at least.
> and you need to do some extra stuff to not have gaping security holes
> when automatically signing things, but sometimes there isn't that much
> of a choice.
There is in this case.
> All this FUD about "no, no, we can't do that, it's not
> secure!" is, well, just that. *Nothing* is absolutely `secure', some
> things just have fewer or different exploits than others.
Wrong. The issue is not the degree of secureness in real life, where
you "hope" that the few exploits won't be found. What we should be concerned
about is theoretical secureness. Security models matter.
> > > There doesn't really seem a huge amount of choice here, to me.
> > Packages should come with their *.changes file, and dpkg should have an
> > option to verify the signature of individual packages. There was some
> > discussion about this in the past. The trick is that security should be
> > implemented in dpkg(-dev), not somewhere else. This has the advantage that
> > it works also with individual packages you don't get from an archive source.
> > It cuold also be used to verify the origin of the package.
>
> Note that this makes debian-keyring a more or less standard package.
Only if you care about security.
> Note
> that it requires you to trust everyone in that keyring with every aspect
> of your system.
Well, this is already the case, and can't be prevented for a binary
distribution. However, a little bit more exact is that you trust everyone in
that keyring with every aspect of the package I install from a single person
(if I don't trust someone, I can simply choose not to install the packages
from this origin.). Of course, one package, however small, can ruin the
whole system in its scripts, binaries etc.
> Note that this doesn't help with revoking signatures: if some idiot
> decides that being a Debian maintainer should give him the right to 0wn
> all the machines that use his package; then gets thrown out; he can still
> use his key to sign packages that'll be happily installed by anyone with
> an out of date debian-keyring.
This is a valid concern, and it is directly inherited from the PGP security
model. There is no way to avoid it, but it can be made small: In such cases,
the new debian keyring should be advocated widely and added to the stable
release as a security update (and appear on the web pages of course).
BTW, there is an analogue concern in your model, and it is worse: There is no
way to revoke past packages from this maintainer in your model, because all
past Packages files (old mirrors, private copies) will remain valid.
> If he can gain control of an ftp mirror,
> he can keep updating the debian-keyring.deb to include his key, and
> keep "maintaining" any packages he likes.
Only if you trust the debian-keyring package. Anyone who is concerned about
security, should especially watch out when updating the debian-keyring
package, and verify that he trusts the maintainer. A trusted key for the
debian-keyring package (the maintainers key) can be placed on the web pages
and other places to avoid the chicken-and-egg problem (which is also
inherited from PGP, btw).
> With a dinstall key, the only
> way he can do this is if he's a member of the ftp team or debian-admin.
As long as dinstall is not compromised. This is a strong assumption, if
compared with my weak assumption, that every maintainer keeps his secret key
secret.
> It also leads to something of a chicken-and-egg situation. It's much
> easier to verify a *single* key than that every one of five-hundred of
> the things is uncompromised.
As I said above, this single key can be the key of the maintainer of the
debian-keyring package in my model.
> (It can be signed by previous versions of
> itself, it can be widely published in Debian books, it can be signed by
> the ftp team, etc)
All of this applies to this key as well.
Let me summarize the advantages of the per-package-model:
* Individual packages can be verified, regardless of the source.
Especially I don't need a signed Packages file (which is probably missing,
or huge).
* Security is as high as PGP, and not as low as dinstall/master (which is
much less secure, because any part of the operating system could make it
insecure, while pgp is widely tested in design and implementation).
* Packages can be revoked on a per-maintainer base, while a Packages file
can only affect packages from a specific date on.
No disadvantage you could come up so far is not existant in PGP and is not
existant in your model. Also, they can be avoided in all three cases by
verifying one key very carefully (in your model: dinstall key, in my model:
debian-keyring maintainer key).
BTW, there may be further improvements possible, however, with higher
complexity. For example, Debian could request that everybody creates a
special Debian key and sends a revocation certificate along with the
application. This would make it possible for Debian to revoke the key
officially. I don't know if knowing a revocation certificate weakens the
secret key, though. Note that this would not have a theoretic advantage,
because the user would still have to update his information about trusted
keys from some other site (pgp key server). It would just add some
redundancy to the process (and make it easier for everyone to catch known
black sheeps).
However, even the simplest approach that is based on per-package-signing has
a positive effect on package security (bumps it from currently zero to some
positiv value), while the signed Package file gains nothing. (It would, but
ONLY if the admins sign it manually, on their local machines.)
Please think about it.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de, marcus@gnu.org PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ brinkmd@debian.org
Reply to: