Re: [gentoo-dev] 2004.1 will not include a secure portage.

[Chris Bainbridge]

On Thursday 25 March 2004 12:14, Paul de Vrieze wrote:
>
> What if the old ACL on the system is so old that the people signing the
> new ACL were not in the old ACL. I don't think forward signing is a good
> (or secure idea). The parent dir system would require all devs to be in
> the /usr/portage ACL anyway so still complicating things.

Yes, this system requires regular updates, as does any security system.
Does every dev to be able to create/modify any package?

> We want to be able to implement ebuild signing fast (mainly to combat
> rsync mirror compromise). Changing procedures beyond what is absolutely
> necessary (entering your passphrase) would be a big impediment to doing
> so.

There is no difference from a normal developers viewpoint between this and 
your signing proposal. For the vast majority of packages it is not necessary 
to have more than one trusted developer!

> The problem is that a manifest changes for any change in ebuilds or
> patches. That means that for adding a keyword to a package one needs to
> resign the manifest.

Yes, a new release requires resigning. How does this differ from your 
proposal?

> > > ps. Based on one public key on a single trusted source (A CD), how
> > > do you ensure that the whole tree is uncompromised.
> >
> > You can't. Its an old tree which has already been signed. Trust it, or
> > update to a new tree.
>
> As it is possible to have an approach that does offer such security, this
> solution is inferior.

You have an old copy of a signed tree. Without updating it is impossible to 
ensure that a compromise has not been discovered since then. Your solution is 
the same in this respect.

> > > pps. How do you ensure that at a compromise of a key / or a rogue
> > > developer this key is invalidated even when revocation is not
> > > possible (like with a rogue developer)
> >
> > Remove the key from the ACL.
>
> Ok, how do you ensure that the ACL is updated? From what I understand it
> would be easy to prevent the ACL from being updated just by generating
> an invalid ACL.

Thats the whole point. If the new ACL is invalid it won't be updated. If the 
new key is valid it will be updated.


Some criticisms of your proposal:

You are making the assumption that rsync servers are unsecure, whilst the 
computers of all gentoo developers are implicitly trusted. This is a basic 
security flaw, and probably an invalid assumption. There are more gentoo 
developers than rsync servers. Rsync servers are less vulnerable  - they 
perform only one function, they don't read email, they don't browse the web. 
Why do you assume that rsync servers are more vulnerable, and that this 
problem needs to be addressed more urgently than the compromised developer 
problem?

What do you do if the master key is compromised?

Signing of daily keys by the master key will be automated. Once an attacker 
has compromised the gentoo server he can submit a rogue daily key to be 
signed. An attacker compromising this system could generate daily keys for 
every day in the next 100 years, thus totally compromising the system.

Points of weakness in my proposal:

You have to trust that an initial fetch of the tree hasn't been compromised.
Single packages can be altered by >n devs compromised
New packages can be created by >n devs compromised
n==1 is possible, a single point of compromise 
If you don't update the tree regularly you may find that the new ACL hasn't 
been signed by enough people on the old ACL, if the ACL has changed enough.
Compromised keys are only removed when user updates

Points of weakness in your proposal:

You have to trust that an initial fetch of the tree hasn't been compromised.
You have to trust that every developer hasn't been compromised
Single point of global failure - if gentoo server is compromised, master key 
is compromised, and attacker can do anything to any gentoo system.
If signing server goes down it affects everybody
Compromised keys are only removed when user updates

Points of resilience in my proposal:

Compromise of n devs is unlikely
Distributed failure - compromise only effects small bits of the portage tree
Distributed system - failure of one server doesn't affect operation of the 
rest of the system

Points of resilience in your proposal:

Master key can be held offline in a safe. But any signing key used day to day 
is vulnerable.

Implementation details of my proposal:

Requires simple post-check of emerge sync changes
Developers must sign manifests
Requires one file to be created in each directory saying which devs have 
access to that dir, and how many are required to agree on changes

Implementation details of your proposal:

Requires simple post-check of emerge sync changes
Developers must sign manifests
Requires establishment of secure infrastructure for global key, daily key 
signing, and submission of updates to developer list to this infrastructure 

My proposal does try to fix two problems at once. If the basic assumption that 
rsync servers are less secure than developers can't be trusted, then there is 
no point in fixing the former and not the latter. When the two subjects are 
so closely linked what is wrong with trying to create a combined solution?

Regards,
Chris

--
gentoo-dev@g.o mailing list