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

[Jesse Nelson]

* Paul de Vrieze (pauldv@g.o) wrote:
> Date: Wed, 24 Mar 2004 11:55:52 +0100
> From: Paul de Vrieze <pauldv@g.o>
> To: gentoo-dev@l.g.o
> User-Agent: KMail/1.6.1
> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63
> Subject: Re: [gentoo-dev] 2004.1 will not include a secure portage.
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 24 March 2004 01:09, Chris Bainbridge wrote:
> > I think the idea of a central key controlling everything is bad - this
> > means one person is ultimately responsible for the portage tree, and
> > compromising this will allow access to everything. It would be better
> > if every gentoo developer had a gpg key. Each package in the portage
> > tree would then have a .gpg file which lists signatures for the
> > package digest which contains hashes of each ebuild, files/*, and
> > downloaded distfiles, and a permissions section listing who has access
> > to make modifications to this dir (such as writing new ebuilds).
> > People who already have access to a package are then free to grant
> > access to others merely by inserting their public key into this file.
> > emerge sync would have to be modified so that it checks signatures
> > before files are updated.
>
> We have a master key that does nothing but sign a more shortlived
> "signing" key. This signing key which is also highly restricted is only
> used to list which keys are acceptable to sign packages. Every dev will
> still have his own key (and only access to this key).
>
> Changing emerge sync is not really an option. There are two problems with
> your idea:
> - - How do I know that the permissions file is actually valid as it is
> self-signed.
> - - It seriously expands the tree.
> - - We currently don't want a package based security level.
>
> > Important packages may require multiple signatures before a file is
> > installed - this is to eliminate the possibility that a compromise of
> > a single gentoo developer will hand root access to every gentoo
> > installed system. At the moment, every developer is a point of cvs
> > write access from which an attacker could root many gentoo
> > installations.
>
> A compromise of any ebuild is able to do that so package based security
> will not solve much of this problem.

um per package security with multiple sigs definatly  prevents a single dev or dev key from compromising integrity. Asuming that ememger on sync or on build is forced to check for multiple sigs, and then yell/scream if somthing only has one or none etc. Of course that would have to be somthing settable in make.conf etc. This does not however solve the event of a malicious comspiracy.

>
> > The key downloads, checking, revocation etc. would be handled by the
> > existing gpg keyserver infrastructure (eg. keyserver.net). There is no
> > need for an all powerful gentoo key, or even distribution system.
> > Simply have emerge call gpg to do everything.
>
> That's not really possible. For one signing a key in gpg means that you
> verified that this person is who he says he is. The keychain does not
> have such a meaning it means: the person belonging to this key is
> allowed to approve packages in the tree. That does not guarantee that
> the person is who he says he is, except that we are confident this
> person is a gentoo developer (he has access to gentoo cvs etc).

well part of gettin your dev key into the keyring in the firsplace would require that you go through some sort of verification. this is true weather or not your issuing certs or gpg keys, and the persons pasphrase is what is verify weather or not he/she is who they say they are, unless you propose sending biometric devices to every dev i don't see how you can do this with any more confidence any other way. Debian has a nice process for gpg key submittals: http://www.debian.org/devel/join/nm-step2 

>
> Also the gpg infrastructure does not provide any way to say who is
> actually allowed to sign packages, it just enables to identify who
> signed it, and it enables people to say I signed it as I can sign
> something which can be decoded with the same public key.

well you can have a list of valid sigs for a particular package. defining whose allowed to sign a that "package", but really your asking for some ACL's here related to users and whatnot. which should be enforced in your rcs not really by your signing system IMHO.

>
> > This only really requires changes to the emerge sync process and a
> > developer script to check, sign, and post changes. Everything else can
> > be handed off to gpg. It would also enable some more exciting
> > distribution methods like RSS channels listing new signed files in
> > portage along with a p2p backend to fetch them, automatic security
> > updates, etc.
>
> p2p and rss are completely independent of the signing problem and signing
> does not enable or disable the use of these systems.

actually p2p distribution in combination with multiple sigs lend to each other quite well. Once a file or set of files is signed by 3 parties @ those sigs are part of your installed gentoo keyring (and verifiable outside that). you can have pretty high confidence that what your pulling from joe users box is prsitine (pristine being what the gentoo devs had released/signed etc). 

http://www.ugcs.caltech.edu/~wtanaka/java/Byzantine.html 

original paper:
http://citeseer.ist.psu.edu/lamport82byzantine.html
     The Byzantine Generals Problem (1982) 
      Leslie Lamport, Robert Shostak, Marshall Pease
      
>
> Paul
>
> - --
> Paul de Vrieze
> Gentoo Developer
> Mail: pauldv@g.o
> Homepage: http://www.devrieze.net
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAYWk4bKx5DBjWFdsRAoReAJ9/zIwAekxYhcbBmi7y3Iasx3XfnQCgqLI9
> 5eYehXbC9nlrkzqefQJh+Bk=
> =gH/a
> -----END PGP SIGNATURE-----
>
> --
> gentoo-dev@g.o mailing list
>
>

--
gentoo-dev@g.o mailing list