On Mon, Mar 27, 2000 at 12:17:47PM +0200, Robert Bihlmeyer wrote:
> Anthony Towns <aj@azure.humbug.org.au> writes:
> > 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.
> That's just the point: the security of a singly-signed Packages.gz
> would not be much higher than that of the ftp sites themselves.
> Nothing to win, here.
Pay attention.
There is an existing single-point vulnerability in *every*
mirror. Compromise the mirror and you can compromise every single Debian
user who upgrades from that mirror. You don't even have to try touching
anything at *.debian.org.
That is the vulnerability being addressed, not anything else.
And note that the vulnerability you quoted above is decidedly difficult to
avoid. For example, if you compromise master, you can pretend to just be
the new-maintainer team and surreptitiously add yourself as a maintainer.
Or you can pretend to be on the ftp team, and surreptitiously add or
change existing package, and replace someone else's key with your own,
say.
So let's run through that again: having a `dinstall' key used to automatically
sign Packages.gz:
* doesn't solve the insoluble
* plugs the main vulnerability
* is relatively easy to setup and maintain
* is easy to fix, should it be exploited
> > > Packages should come with their *.changes file, and dpkg should have an
> > > option to verify the signature of individual packages.
> > Note that this makes debian-keyring a more or less standard package.
> Either that, or just let dpkg Recommend it. If it is not installed,
> package verification is not available.
Let me rephrase that. This makes debian-keyring a base package, since
if you want to verify the packages you download, you really want to do
it right from the word "go", rather than just some time later.
This isn't necessarily a bad thing, but it's worth noting since it adds
about half a floppy to base.
> > Note that it requires you to trust everyone in that keyring with
> > every aspect of your system.
> That's already the case, isn't it? Signed packages give you the
> benefit, that you'll *only* have to trust the maintainers you install
> packages from - not every man-in-the-middle.
It's currently the case, yes, but it *could* be changed. You could,
for example setup dinstall so that it wouldn't accept NMUs of certain
important packages (such as gnupg).
> > 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.
> Indeed. But I am sure that this fact will get big coverage on the
> lists and the websites.
And, equally, a deliberately compromised package would probably get a
fair bit of coverage too. It'd be nice not have to rely on staying up to
date with slashdot and the mailing lists and IRC before doing an apt-get
dist-upgrade though.
> Debian has handled security leaks in other
> packages well - this is just a leak in the package system that
> updating debian-keyring will plug, nothing else.
The *reason* Debian handles security bugs (security leaks?) in packages
well is that we have a mechanism for handling bugs, and we make use of
it. The best way to ensure that we always have mechanisms for fixing
things is to think about it first, not just handwave it away and say
"She'll be right, mate".
> > 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.
> No, see below.
...where you add extra complexity to the security model. The originally
stated model does have this problem.
> > 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. (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)
> The solution is to have one master key (in the hands of a highly
> trusted person)
The phrase is "A solution".
The highly trusted person you're referring to here is eash member of the
new-maintainer team, by the way.
> that is treated like your single key (published
> everywhere). Every developer's key has to be signed by at least by
> this key.
And if a developer gets kicked out? You can't revoke a signature (PGP
signatures are designed to certify identity, not trustworthyness), so
instead you have to revoke the key, and sign everyone else again. Revoke
n people, and you have n signatures on every key in the keyring. How
elegant. And note that this makes revocation a standard (although
hopefully very infrequent) operation, rather than just one that happens
regularly (once a year?) or in highly exceptional circumstances (the
key is compromised). Note that the latter circumstances are those for
which key revocation was designed.
And again you have the usual problems if someone compromises one of the
machines with this `super key' on it.
> Corrupting the debian-keyring package is useless, since the attacker
> will not be able to put valid (signed by master) keys into it.
And if they corrupt this master key as well?
(Actually the exploit needs to be smarter than this: you'll be verifying
with your *existing* copy of the master key, not the one on the ftp
site. I believe it's avoidable as long as master key's are signed
by the previous master key, and by some independent keys, such as the
new-maintainer or ftp people)
Again, all these complicated distributed methods are great and all, but
they *aren't* actually particularly more secure, and nor are they more
convenient. In some vague academic sense, they're harder to compromise
*completely*, but I don't think that makes any particular exploits any
harder to perform, practically speaking.
Cheers,
aj
--
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:
pgptD3VsjL5AL.pgp
Description: PGP signature