Re: Signing Packages.gz

[Robert Bihlmeyer <robbe@orcus.priv.at>]

Anthony Towns <aj@azure.humbug.org.au> writes:

> 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.

Yes, and I'd very much see this vulnerability fixed. I just advocate
that we could go the whole way, and make ourselves independent from
the security of master, too. I think that is possible, but perhaps you
can prove me wrong.

> 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.

I still won't get paranoid characters to trust my key.

> 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.

That's to decide. This kind of security is optional. But yes, I'd
recommend people to get the security-enabled base distribution.

One problem here is that (depending on the
US-export-regulations-du-jour) this base would qualify for non-US. Not
very good. Of course some more complicated scheme could be built,
which had base download and verify (by MD5) a corresponding
base-secure addendum. More work.

> 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).

A good idea. Still: with package-granularity, this decision is made by
the users, not the Debian administrators.

> 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.

If you trust the debian-keyring maintainer, there is no problem for
you: your keyring will get updated (to a version w/o the bad guy's
key) and then any other packages get upgraded. People will probably
also quickly updated packages compromised by this guy with fixed
versions.

> 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".

I don't see how this doesn't apply to the "bad maintainer" scenario.
If someone discovers a security bug in a package that has probably
been put in deliberately, she should:

1) file a critical report against the package
2) Cc or otherwise inform this list, and state her suspicions

If there is consensus that the maintainer put a backdoor in on
purpose, he will get kicked, a new version of debian-keyring will be
produced, and the situation is repaired.

> The highly trusted person you're referring to here is eash member of the
> new-maintainer team, by the way.

This is a possibility, not a requirement.

> And if a developer gets kicked out? You can't revoke a signature (PGP
> signatures are designed to certify identity, not trustworthyness),
> [...]

GPG can revoke signatures, so your conclusions do not apply.

> And again you have the usual problems if someone compromises one of the
> machines with this `super key' on it.

Indeed. But this machine could be made more secure than the debian
main machines could ever get (there's no need for people other than
the signer being root, etc.)

> > Corrupting the debian-keyring package is useless, 
[...]
> And if they corrupt this master key as well?

Then we have a problem. Perhaps it's no use to put in another level of
signing. Let's for now forget about the super-key, and make the
debian-keyring package the thing to use.

> Again, all these complicated distributed methods are great and all, but
> they *aren't* actually particularly more secure, and nor are they more
> convenient.

I don't think it would more complicated for developers. Perhaps one
additional entering of their passphrase, while building the .changes
file, but that's it.

Users could choose their paranoia level. From trusting (same as now)
to paranoid (only trust packages signed by a key which is signed by my
own key). 

> 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.

I partly concur. Even if the developer->user channel was completely
secured by signatures et al, we would still have the problem of an
attacker gaining very much by breaking into a single developer's
machine. You're netbase package is a good example: it contains a
couple of programs usually started as root. If your developing machine
is compromised, and your copy of the source modified, the evil guy may
gain entry into a large number of Debian boxen.

-- 
Robbe