On Sun, Apr 02, 2000 at 02:57:06PM +0200, Marcus Brinkmann wrote:
> > > As dinstall verifies the keys on the packages (which already exist, btw,
> > > they are just not propagated), it puts itself in the middle of the chain:
> > Well, as Jason points out, they are propogated: by the -devel-changes
> > list.
> They are not delivered to the user when he is downloading a deb, with no
> dselect method, and not with apt, and espcially not when downloading the
> package manually.
But they could be, with minimal changes. Stick the latest .changes files
in debian/changes somewhere and add some code to apt to get it.
I'd be interested in seeing some code for this. You keep throwing around the
word `easy', as though it *is* just as plausible to implement this method.
Please, at least write some pseudocode for it.
Make sure you consider the necessity of keeping debian-keyring up-to-date
in case of compromised keys. Make sure you either explicitly do use a
`single key' that's easy to verify, or not. If you do, make sure you allow
some way of coping with James' key being updated, or James retiring and
someone else taking over the job; and make sure you cope with upgrades
that possibly skip the generation where this happens.
>> I'm sorry, but that's a matter of opinion. If you're really *hugely* worried
>> about the security of master, then please, show us your scripts that you've
>> already had to write to cope with the fact that master's so insecure it's
>> probably already compromised.
> If you compare the security of PGP with the security of any linux machine,
> you will easily see the difference.
Right. Now compare the security of one particular linux machine, namely
master, with the security of the weakest machine used by a developer. You
ought to be able to see the difference there, too.
> > Yes, it's a problem, but one you seem to be vastly overrating.
> Are we talking about security, or are we talking about belief?
If we're talking about trust, which we are, then we're immediately talking
about belief. Belief is quite fundamental to security analysis, it's the
fundamental unit in BAN logic, eg.
> I am very irritated that people who want to propose and implement a security
> measure for Debian packages are building on likeliness and probablility, and
> on the fact that "master is quite secure".
We've got a choice: do we trust master, or do we trust that mirrors won't be
compromised by developers? How do we choose? Liklihood, probability, how
easy the weakest choices can be compromised.
> What about all the packages on other systems? Third party packages? Packages
> I build locally? There is a solution which covers individual debs even,
> where I don't know any more where they come from.
Packages you build locally? Huh? If someone's already compromised your local
machine, what security is adding signatures going to give you?
For third party packages, you have a point. Most third party packages are
distributed in an apt-able way these days, though, in which case most of
them have a Packages file that can be signed. If you want Apt to verify
and trust the signature, you'll probably have to move the appropriate public
key into an apt configuration file somewhere first, though.
Jason: I'm thinking, probably, something like:
Gpg::KeyRing {"/etc/apt/apt-keys.gpg";}
Gpg::Origin
{
Name {"Debian";};
KeyID {"0x12345678";};
}
Gpg::Origin
{
Name {"IPv6-staging";};
KeyID {"0xabcd9876";};
}
where the Gpg::Origin::Name's match the Origin field in the Release files.
I'm not quite comforable with the `KeyID' stuff. It's very easy to make a
key with the same KeyID as another, so as identifying information, that's
pretty weak. OTOH, to actually get it installed, you'd have to overwrite
the Apt keyring, so anyone whose going to compromise your system has to
have already compromised it, which isn't too bad, I guess. I wonder, though
if it mightn't be better to also specify a fingerprint, which apt can
check for itself.
This is also somewhat difficult to verify if you want to allow updates.
You could probably do it if you had a different .gpg directory (with
separate gpg keyrings and separate trustdbs) for each Origin. That'd
be pretty ugly though. Possibly a `--check-trusted-by <keyid> <keyid>'
option needs to be added to gpg, so you can check that whatever key was
used to sign a Packages.gz file from Debian is at least certified by the
key you verified by hand yourself. Alternatively, you could just say
"Aieee! The Debian/unstable key has changed again! Please verify this
by hand and update your apt.conf!" which could get tiresome.
Marcus: How would dpkg with debian-keyring handle all this?
> > > signed packages --> dinstall
> > > \ 1
> > > \--> user
> > > 1
> >
> > Really, what we have is:
> >
> > maintainers ---------3---------.
> > | V
> > 1 users
> > | ^
> > `--------->debian--2-------'
> >
> > The first link is already checked completely. Debian knows that all the
> > packages it distributes are created by developers.
>
> Yes, almost. It knows that all packages it accepts are created by
> developers. If the current packages in the archive are the one we uploaded,
> I can't know without messing around with the devel-changes archive :)
Debian knows this, but Debian might be insane, yes. You, as an individual,
don't have any way of assuring yourself of this. You also don't have any
particular assurance that James or my machine haven't been compromised.
Yes, you can find ways of assuring yourself that master hasn't been
compromised. Practically, though, this doesn't buy you anything
significant: developers machines are at least as easy to compromise,
for similar amounts of damage; and if master is compromised, it's only
*existing* users that can verify this for themselves, new users can't.
> > Link 2, which could be accurately implemented by signing Packages files
> > and nothing more (and is hence really easy to do, really easy to automate
> > and adds next to no overhead at all), allows a user to confidently say
> > "This distribution is Debian's." Hence, if Debian (ie, all our servers,
> > some of our important people, whatever) gets compromised, they're stuffed,
> > yes.
> Yes. Does this not worry you?
No, it doesn't. Nor does the possibility that a huge asteroid might've
evaded all our astronomers and be hurtling towards the Earth at this very
moment. There are other dangers that are both more probable and that I
can actually do something about. Those are the ones that I'll worry about.
And note that saying `This distribution is Debian' is different to
saying `This distribution is made up of stuff put together by Debian
maintainers.' The latter could be put together for a special series of
`When Packages Attack!' and include all the best security holes ever
distributed by Debian.
Actually, you could make up such a collection just by compromising
a single mirror, and being studious. It wouldn't give you *complete*
freedom in compromising any hosts that use that mirror, and you'd only
get the ones that didn't independently verify that they've got their
security updates, but you'd get a fair number of vulnerabilities. How
would you avoid this just with signed .debs? With signed Packages files,
the worst an attacker would be able to do would be to keep an outdated
mirror about, which would have fairly limited vulnerabilities (there
aren't as many vulnerabilities at any particular time, compared to being
able to collect all vulnerabilities since the epoch), and would be fairly
easy to notice, when apt consistently says "there aren't any updates"
every time you run it.
So, yes, I do think that being able to say `This distribution is Debian'
is more meaningful and interesting and in many cases more reliable than
just `All these packages were at one time or another put together by
current maintainers'. That's not to say we shouldn't be able to say both,
though.
YMMV, of course.
> > Do think about that though: Debian gets compromised. That's not some J.
> > Random Event that happens every day, every month, or every year. It's not
> > something you can just blithely work around, either. People installing
> > for the first time might be willing to trust www.debian.org to be controlled
> > by Debian, but they're not going to have any other way of verifying the
> > whole debian-keyring. If www.debian.org is compromised, there's no reason
> > for them not to accept some bizarrely wrong keyring as gospel.
> The debian-keyring signature is verified exactly in the same way as the
> dinstall key on the Packages file. Only that the debian-keyring keys secret
> key is stored securely on James machine (I hope), while the dinstall key is
> on a net connected machien and revealed to the attacker "for free".
What's with this `net connected' boogey man and the `for free' junk? If
you'd like to assert that it's orders of magnitude easier to get
information off master than to get it off James' box, please at least
provide *some* evidence. If not, then please *stop* asserting it.
> > Link 3, allows you to verify for yourself who built a particular package
> > that Debian distributes. Or at least, allows you to verify the key
> > they used. Verifying that they're an actual person, that they're really
> > someone you have a reason to trust, and that they themselves haven't been
> > compromised, is less trivial. (This is asserted by `Debian', but hey,
> > like you say, Debian could be compromised. Who'd wanna trust them?)
> Debian is compromised, but you had to compromise James to get a fake key in.
> You are correct about the trust analysis.
This only works if you know James personally, and have verified
his key. If you don't, then you're just trusting that the key whose
fingerprints on the Debian webpages actually is James. That fingerprint
could've trivially been compromised along with master.
>>> In this situation, I don't have to trust anyone except the Debian developer.
>>> Not the admin team, not the security team, not master, not dinstall. Can't
>>> you see that this is a crucial advantage?
> > Can't you see that it's a crucial *flaw*? You have to trust *every*
> > person who's a developer. And guess what. That means you have to trust
> > the admin team and the security team. It means you have to assume that
> > every machine every developer stores a secret key on is maintained as or
> > more securely than master.
> Only for individual packages. In the signed packages case, you have to trust
> everyone and their dog, *and* the security of master, *and* the admin team
> etc.
No, you have to trust Debian, and let that trust flow on. You don't have to
take care of correctly updating your debian-keyring, and correctly verifying
that its not being NMUed by someone, or replaced somehow else, you just have
to trust a single signature, which you can easily verify with some PGP gui
on Windows, or wherever.
*shrug* If you're allowed to have your "OMG! it's
net-connected!" boogey-men, I'll keep my "why should I have to verify
many signatures, when i can need only verify just one" boogey-man.
> This is exactly what I find irritating. You are trying to convince me that
> my proposal is flawed because you need to trust anyone.
No, because you have to explicitly, personally, trust *everyone*. Not
just one person, not just a couple, but you have to manually, personally,
accept everything by *everyone in the keyring*.
> The only way to look at it where you get more keys to trust is the
> out-of-date keyring issue. But those are seperate things. I have to be
> careful manually when upgrading the keyring. The rest can then be automated,
> just as dinstall is.
This is acceptable right now, but I remain confident that new-maintainer will
actually one day reopen. Having the debian-keyring not be automatically
updatable is horrible.
I /think/ under your model it can still be automatically updated,
but I may be wrong. What particular care do you have to take that's
not automatable?
>>> If you also want a link 2 from dinstall to the user, I don't care. But don't
>>> tell the users that link 2 asserts that all packages come from Debian
>>> developers, it doesn't.
>> No, it asserts that all packages come from *Debian*. Debian itself states
> that they'll only distribute packages that come from developers listed in
>> the keyring; and yes, it might turn out that Debian as an organisation has
>> been compromised, or hacked, or is just lying.
> Yes. I don't know how one can come to the conclusion that this is
> acceptable, though. Especially if there is a better solution, that is not
> much harder to implement.
Please provide at least pseudocode, then.
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:
pgpud_COmAaJW.pgp
Description: PGP signature