Re: [gentoo-hardened] The state of ebuild signing in portage

[Toby Dickenson]

On Thursday 24 April 2003 4:34 pm, Joshua Brindle wrote:
> >On Thursday 24 April 2003 3:10 pm, Joshua Brindle wrote:

> >Consider this fictional scenario: A colleague is appointed a new gentoo
> >developer because of his interest in maintaining app-games/abcabcabcabc. I
> > am not interested in this package, and never intend to install it on our
> > server cluster.
> >
> >Do I have to worry about him planting trojan sys-libs/glibc ebuilds in our
> >local portage mirror?
>
> Well, there isn't anything we can do on the client side. Users will always
> have the able to modify ebuilds/packages on their own machines
> or we'd have a lot of angry users. The one thing that would solve the
> problem is to 1) make sure you don't have any PORTDIR_OVERLAY's since
> those probably won't be verified by keys anyway (we may have a setting
> for this) and 2) emerge sync before you do _anything_, this means even
> emerge -s or emerge -p.
>
> Since an emerge sync would overwrite any changes in the local repository
> all your coworkers hard work got erased...
> Also: on my machine /usr/portage is writable only by root.. if the coworker
> has the access to write to the local tree then uhh, i don't guess it
> matters since he could just backdoor your system without using portage..

Our "local portage mirror" is a seperate machine which runs an rsync daemon 
for our internal machines. It is an intermediary between the internal 
machines and the public rsync mirrors.

Yes, suppose that mirror machine is rooted. I would like for portage on the 
non-rooted internal machines to be able to detect tampering on the 
intermediary.

(I can understand if its not possible, but that doesnt stop me wanting it ;-)



> >Another way of looking at it........
> >
> >If I understand correctly, your proposal is using signatures from an inner
> >keyring for two different purposes:
> >1. To confirm identity. This is the conventional meaning of a key
> > signature, as should be understood by everyone that signs someone elses
> > key. 2. To confirm status. That is, to confirm that the owner of the key
> > is an official gentoo developer.
> >
> >Would it be better to use key signatures from the inner keyring only for
> > the first of those two purposes. Some file in portage, appropriately
> > signed, would list all official developers and the packages that they are
> > authorised to maintain. Senior gentoo developers will be authorised for
> > everything.
>
> It would be impossible to keep the file accurate and up to date. Far too
> many devs are involved in lots of things, also we'd have to wait on the
> permissions key signer to even add new packages which would slow
> developmental efforts down dramatically.

Hmmm. maybe the ~arch testing flag could be used to pipeline these tasks. I 
take your point made in your original post that developer convenience is 
important too.

> I have personally edited a lot of the core packages, gcc, glibc, xfree,
> etc. It would have been a huge hassle if I had to go seek permission and
> justify it and wait for a decision, etc.

Yes, of course allowing this capability to all junior developers has a 
security implication. One compromised gpg key of *any* developer can 
compromise any package, so security is reduced by appointing many junior 
developers.

(Which isnt necessarily a problem, but its nice to know where the boundaries 
lie.)

Thanks for taking the time to discuss this.

-- 
Toby Dickenson
http://www.geminidataloggers.com/people/tdickenson

--
gentoo-hardened@g.o mailing list