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

[Paul de Vrieze]

On Thursday 25 March 2004 15:27, Chris Bainbridge wrote:
> 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?

Currently yes (at least all dev's that have portage tree access, as some 
(mainly documentation developers) do not). If there were reasons we could 
discuss a system that would limit this ability, but this would need to be 
discussed first by the developers and then by the managers.

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

How do you think this affects continuity. Also keep in mind that their are 
only two relevant differences between gcc/glibc and <obscure package that has 
been deprecated because of lack of upstream movement>
- glibc is likely to be present on most if not all systems, while the obscure
  package is not
- Any tampering in glibc is probably noticed within minutes of it being added
  to the cvs (not even rsync) tree, while tampering to the obscure package
  might go unnoticed for an extremely long time (think months)

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

In that I only require one signature.

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

My approach however will block when the list on the rsync mirror is not 
updated. In your idea however it is possible for an attacker to block the 
update of an ACL file when he/she has access to an rsync mirror.

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

No the case is as follows:
- The old ACL is invalid
- The invalidness of the old ACL has been discovered after it has been send to
  the user
- There is a new ACL on the master rsync server that removes the invalid keys
  from the ACL
- The attacker also has access to an rsync mirror
- Now the attacker can prevent the new ACL to be put in place by his access to
  the rsync mirror

Alternatively if the ACL has only one key it is actually imposible to create a 
new valid ACL as your system uses forward signing.

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

Rsync mirrors do perform more functions. Also the rsync mirrors are public 
while developer computers are not necessarilly. Further developer keys should 
be passphrase protected. I do not disagree though that developers are a weak 
spot. I think however that it is very hard to protect against developer 
compromises while it is a lot easier to protect against rsync compromises. 
Say that the chances to a compromise of a developer key are equal to the 
compromise to an rsync mirror I would prefer to protect against explictly 
untrusted rsync mirrors (They are third-party provided, we have very little 
control)

> What do you do if the master key is compromised?

Whine, revoke it and post it to all kinds of security lists. That's why I try 
to keep it very secured with a scheme where it would be accessible only 
fractions of the year (5 * 12 = 1 hour per year max).

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

No, signing uses an intermediate key and signing this intermediate key (by the 
master on a usb key) will not be automated. This intermediate key has a 
lifespan of a month. This means that a compromised intermediate key would 
only allow a compromise of 1 month (half a month on average)

That's why I enhanced the system to N servers and N keys. This would mean that 
the attacker would need to compromise N computers.

To enhance my proposal we could also sign the developer list with the keys of 
various devrel people, and have any invalid key invalidate the list. (One 
must still check that there are N machine keys though)

> 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

The biggest problem with your system is that it breaks when keys are 
compromised while they are still in ACL's. An unknown compromised key could 
be used to change the ACLs of packages. Once these bogus ACL's are in place 
on the user computers, there is no way to use forward signing to get new keys 
to the user in a secure way (They don't have valid ACL's anymore as they 
thought the bogus ones were valid). 

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

I have to trust that the fetch or retrieval of the public master key has not 
been compromised. Further for integrity my system has to trust that no 
developer keys have unknowingly been compromised. However once they have been 
compromised I have a clear path to purge them from the system in a way that I 
can say: "these, these and these packages have been compromised, if you 
didn't touch those within day x and day y you are safe and you will be safe 
from now on as the key is now invalid" It also ensures that one can trust the 
new list as it will be again derivable from the master key (which is indeed 
the single point of failure)

> 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

Unfortunately a small bit equals a total failure for anyone who happens to 
touch that package. As I showed earlier packages that will affect lesser 
people are also likely to be detected later, so that would balance out. My 
system completely stops rsync server insecurity and allows for fast and 
reliable revocation of developer keys. Your system does not allow reliable 
revocation but instead could lead to a puzz of unverifiable ACL's

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

Indeed my signing keys are more vulnerable as the intermediate key security is 
based on host security. An easy solution is to have multiple servers. One 
could also go so far to have a time switch which would only connect those 
servers to the net at the time that the keys have been generated and 
transfered. I can indeed not protect against rogue developers or compromised 
developer keys (only multiple signatures can), but however I can quickly and 
reliably invalidate them at the moment their compromise has been detected.

> 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

This ACL file is insecure and also forces a policy we don't necesarilly want. 
It mixes two issues, however even if there would only be a master ACL (which 
is very comparable) forward signing is a bad idea and my scheme is superior.

> 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

Correct

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

Your ACL update system is compromisable which shows how hard it is to design 
really secure protocols. The reason why I don't want to solve the double 
signing issue is that it requires many (security unrelated) procedure changes 
within gentoo and will take a long long time to implement.

> Regards,
> Chris

Regards,
Paul

ps. I do appreciate your feedback although I don't agree on your proposal

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@g.o
Homepage: http://www.devrieze.net