On Sat, Apr 01, 2000 at 01:24:03AM +0200, Marcus Brinkmann 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.
`is not secure' is out and out FUD.
It's no less secure, for example, than saying `hey, this public key up on
www.debian.org is canonical for the keyring! check it!' because, hey, all
you have to do to compromise it is to replace it with your own, which just
involves hacking some .debian.org machine.
If you want to just say `oh, I just trust every maintainer's secret key'
you need to trust that *every* machine owned by *every* developer isn't
equally compromised. If you want to just say `oh, I trust James' signature',
you have to trust that *his* machine isn't compromised.
I should probably add: these two options (signing Packages files automatically,
and including a signature of the control and data portions of a .deb in with
the .deb) don't have to be mutually exclusive at all.
>>>> 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.
> So you agree with me. What exactly do you think is "nonsense"?
The risk isn't nonsense, it's the implication that the risk is so
completely abhorrent that we should thus continue with our current
more-or-less lack of security instead, because it's better for our soul
or something that's 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.
Which is a good reason to have both available.
Note that in most cases dinstall will simply agree with your local tests.
If the .deb's made by some creep, you won't know his signature, but he
won' t have been able to upload to master anyway.
What else might happen?
* Someone resigned from Debian, and you've already done a
partial upgrade and lost his key from debian-keyring, and
want to install a new package from your out-of-date stable
CD. Dinstall is better, because you can easily verify that
at the time, this was legitimate.
* Someone was kicked out of Debian and you're using an
out of date keyring. Dinstall is better. (You're doing a
partial upgrade, say. Ooops. Always remember to upgrade
debian-keyring first)
* James resigns. Someone else takes over debian-keyring.
Dinstall is better. (Well, depending on whether its James
you trust for signing things, or any developer in general.
Also consider what would happen on a hamm->potato upgrade if
James quit during potato, and the new debian-keyring maintainer
only appeared during slink)
* Someone cracks master, adds a package signed by them, adds
their key to debian-keyring, and lets dinstall sign stuff.
(Just checking dinstall is consistent, you're stuffed. Checking
debian-keyring is signed by an existing developer, or signed
by James himself, fails, and you're happy)
* Someone cracks both a mirror, and a developer's key, and starts
"maintaining" a .deb on that mirror, and stops debian-keyring
from being updated. Dinstall is better. (with dinstall, they
can only stop a mirror from being updated in its entirety,
with debian-keyring, they can keep making new updates to
whoever's packages, and no one need be any the wiser).
Other things, like if someone cracks James' key while he's asleep, can
be equally painful in both cases, of course.
> > 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.
And this is out-and-out *wrong*. With the trusted-dinstall-key, people
can't compromise mirrors and thus wreck everyone's system who uses
that mirror. They can, with some difficulty, now. They can, with even
more difficulty, under the just-trust-the-keyring scheme. Cracking any
one mirror is "reduced" to having to crack master with the dinstall
scheme. And, it requires basically byzantine control of Debian entirely
to do so with both schemes.
> 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.
As is the dinstall scheme.
This is what I don't get. I explain a real, practical, vulnerability in
the current system, and explain how giving dinstall a key completely
solves this. And then get told that a dinstall key just isn't an
improvement.
I don't understand this at all.
No, it's not *perfect*. Yes, there are still vulnerabilities. Yes,
there are other ways of removing those vulnerabilities. Fine. But it
*is* an improvement over the current system, and it's even better in
some respects than the debs-with-their-own-signatures method.
> > 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.
Huh?
This isn't a computer science class. We've got x-thousand people regularly
updating of Debian mirrors. I'm sure practical security matters too.
And theoretically perfect security only happens when you neglect to
consider some avenues of attack, like rubber-hose cryptanalysis [0],
or poor key generation in the first place, or whatever's inconvenient to
analysise. It's not really all that relevant in a particular practical
situation.
>>>> 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.
Which, presumably, everyone does? And, presumably, everyone would make use
of any automated security apt could provide, presuming it was reasonably
automated?
And I should've called this a "base" package, since for it to be really
useful, you should get it at the same time as when you do your very
first install.
I don't consider this a particularly bad thing.
> > 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).
Note that i'm more considering the case where a mirror is compromised
too; updates, no matter how loudly shouted don't *have* to reach the
idle apt-get upgrader. OTOH, we can, to some extent, assure that if you
don't get told about the updates to one package (debian-keyring), you
don't get updates to any of them. This can be a pretty effective guard
against some attacks.
> 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.
That's not a bug, that's a feature! :) In particular, almost all of
the Packages out there that that maintainer made are probably perfectly
reasonable, so *ought* to be installed, especially if they're from, eg,
a stable CD.
A few won't be, of course, but you (obviously, I should think) can't have
any way of knowing about that without going to an up-to-date mirror. If
you do do that, instead of downloading a new debian-keyring, you can
just download the up-to-date version of whatever package.
You can differentiated probably good but outdated old packages, and probably
bad but outdated old packages, no. On the upside, you can still verify that
once upon a time they *were* trusted.
And note that the dinstall-key model is only a problem with consistently
outdated archives. The above issue is a problem with seemingly current
archives. Personally, the latter seems liable to do more damage to more
people to me.
> > 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).
The chicken-and-egg problem is just the `who do you trust' thing. For example,
you could always compromise any mirror, write your own boot-floppies and
gpg, and make everything both broken, but consistent as far as the eye can
see. If you decide to just trust that mirror, you're stuffed.
In your model, you have to trust every developer or your local ftp site.
You have to trust them not to be cracked, or bribed, or threatened,
or go insane, or whatever, not just trust them to pay back $5 if you
give them a loan. In mine, you have to trust master. (In both cases,
you also need to trust the Cabal and in particular James)
The former is good because you've got two points of failure that both
have to be compromised. It's bad, because you've got a *lot* of choice
for both of them, so you can choose two easy targets. It's good, because
it's limited in scope: both to packages that developer maintains (or NMUs,
which could be anything but debian-keyring), and to people who actually
use that mirror.
The latter is bad because you've got a single point of failure. It's good,
because that single point of failure can have a lot of effort put into
securing it. It's bad, because a compromise affects everyone.
Note, again, that both're still a lot better than the current situation,
where there are many single-points of failure (James's key, my key,
master, mirrors, etc).
> > 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.
Erm.
A weaker assumption would be that a *single* maintainer out of all of them
keeps their key secret.
Requiring every maintainer to keep their key secret is a stronger assumption
(or an equivalent one, depending on your point of view).
> 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).
This is a definite plus. I disagree with the `probably'; I think you'll
find a huge majority, in the order of 99.99% of upgrades are done via Apt,
and thus *do* have the Packages file about.
> * 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).
This is meaningless. Security isn't a single-dimension variable that
is directly proportional to stuff. Pretending it is, is, as I've said,
complete nonsense.
The advantage here is that you don't have to trust master. The
corresponding disadvantage is that you do have to trust your mirror and
all the developers.
> * Packages can be revoked on a per-maintainer base, while a Packages file
> can only affect packages from a specific date on.
Huh? Packages files affect files on a specific date. On the next date
there's a new Packages file.
> No disadvantage you could come up so far is not existant in PGP and is not
> existant in your model.
PGP isn't relevant. If we can do better than PGP, how is that a problem?
> 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).
This isn't the case.
> 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.
A revocation certificate is just a specially signed message. The only
strength is that you can tell it to people, and they'll legitimately
think you've revoked your key.
> 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).
Redundancy is good, of course. If you can trust either foo, or bar, and
you're pretty sure you do, that's a lot better than *having* to always
trust foo. (It may or may not be better than having to always trust baz,
though, which is my point above)
> 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.)
Which, again *IS NOT THE CASE*.
I'm not sure why this isn't getting through. Automatically, cavalierly
signing Packages.gz on master *HAS DEFINITE GAINS OVER THE PRESENT WAY
OF DOING THINGS*.
Why is this so hard to accept?
Let me be somewhat linear for a moment. This is what I'm claiming:
current-system < dinstall-key, signed-debs < dinstall-key & signed-debs
The relationship between dinstall-key and signed-debs is less clear,
and probably doesn't particularly matter, since they're not mutually
exclusive options.
What you keep asserting is that:
dinstall-key <= current-system < signed-debs
Do you really believe this? Do you *really* think it'd be easier to hax0r
Debian *with* signed packages files than without?
Cheers,
aj
[0] Beating the owner of a key with a rubber hose until s/he gives it
to you. See Schneier.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpjT5KCH1gFX.pgp
Description: PGP signature