On Sun, Apr 02, 2000 at 06:52:37PM +0200, Robert Bihlmeyer wrote: > > 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.
Users don't have enough information to make such a decision, however.
How do they know if James allowed a particular NMU to be made, because
not only did he not have time to make the upload himself, but because
there was a huge nefarious vulnerability there that made gpg accidently
distribute the user's private key along with every signed message?
Debian *can* make this decision, because we know each other. Most users
can only go `James who?'.
> > 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.
And if he's already compromised your local mirror, and decides that no
one needs an updated debian-keyring, or any of those irritating bugfree
packages?
To reiterate: signed .debs don't cope with any of the following attacks:
* Past/current developers doing nefarious things, especially if
they also manage to compromise your local link in the distribution
network.
* Vandalism against Packages files
* Maliciously distributing the worst possible selection of valid
packages
These attacks are all based on the fact that sometimes it's Debian as a whole
acting in concert that you trust, not any and all particular developers.
Signed Packages.gz don't cope with master being compromised, or similar.
That is, if you trust Debian as a whole, that's a single point of
vulnerability.
Note that signed .debs also don't cope easily with Debian being
compromised for new users, who don't have an existing copy of James key
or the entire keyring to check against. Sometimes it *is* Debian that
you trust, not arbitrary maintainers.
> 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.
And if he's doing this on purpose, he'll likely go and compromise some
other systems, like, say, some downstream mirrors.
> > 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.
Huh, so it can. Having x signatures on every maintainer key, where x-1 of
them have been revoked still seems thoroughly inelegant, however.
> > 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.)
Hmmm? The `signer' in this case is `Debian'. There should really be
no need for non-Debian people to have root on master. To some extent
sponsors are Debian people, too.
> > 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.
Mmm? One per .deb, YM? That's somewhere around 40 or 50 for each X upload.
(each .deb has to be signed separately, no matter which way you do 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).
This is very cliquey. Not everyone knows everyone else, even within Debian,
let alone thinking about people who've never met a Debian developer in
their lives.
So afaics, users can really only choose exactly one paranoia level:
allow everything in every package to be uploaded by anyone. I'm yet to
see a reasonable method of restricting even uploads of debian-keyring
that also allows James to resign.
> > 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.
The preinst and postinst scripts of every package are also run as root.
All you need to do is compromise the machine of one of the 60 or so
maintainers that maintain a standard or better package, or any of the
maintainers who could do an NMU of such a package, and you've got root.
Securing the way Debian distributes its software is a *long* way from
making it impossible for an attacker to compromise huge numbers of
Debian boxen.
I probably should add a rider that it's already quite difficult to do
this; developers machines aren't your regular `let's install RedHat
5.0 and leave all the default servers running', nor are most mirrors,
and certainly most popular mirrors. And even if a mirror is compromised,
an attacker has to keep their grip on it, otherwise the regular updates
to Debian will make their attack fairly minimal.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <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
pgpRklcR0pQOg.pgp
Description: PGP signature
