Re: [gentoo-dev] Gentoo & package security

[Christian Skarby]

I am not officially part of the Gentoo project, so my reply on your mail
should not be concidered an official statement from the Gentoo Developers
nor from the Gentoo community.

> I'm currently working on a feature article on package security.  As
> there's been yet another CERT advisory
> (http://www.cert.org/advisories/CA-2002-28.html) concerning already
> widely distributed packages that containted a trojan horse, I'm
> contacting several major Linux distributors with the following
> questions:
>
> - How do you make sure, your distribution doesn't contain packages
> modified by people unauthorized to do so?

Well, if one have such a strategy how can one be absolutely sure people
authoriezed to modify packages have pure intentions? At some level one
just will have to relay on something / others. It is not possible or at
least not effective to reinvent wheels every day.

On this mailinglist we've had discussions about pgp-signed ebuilds. Then
atleast one can trace security-issues back to spesific signatures and make
sure that the source is from whom it claims to be. But secure
authentification is not easy to set up and not between people not knowing
eachother in person. Two people knowing eachother can easily and securly
exchange public-keys this way: Person A generates a crypto-key-pair
(private and public, where private key can decrypt messages encrypted with
the public key and private key can sign messages, which signature could be
verifyed by the public key,) as I said person A generates a
crypto-key-pair and sends the public-key to person B by email. At the time
B receives this (s)he cannot be 100% sure the key (s)he received in the
mail is the key of which A sent. (A person C can teoretically replace the
key with an man-in-the-middle-strategy replacing As key while it is
transported via other computers from A to B.) So B should now have a phone
call with A, and recognize A by voice. When A read her/his publickey's
fingerprint to B, B can verify that this indeed is A's public key. Now B
can generate a key-pair, encrypt her/his public-key with A's public-key
and thus only persons having access to A's private-key can export B's
public-key. A can then verify B's key by decryption. - Okey .. but what if
A and B do not know eachother .. then they cannot be sure the person they
meet in reallife is the great programmer they've talked with on the
internett, and well .. if the can, and even if they know eachother .. how
can they be absolutely sure the other is not a blackhat or a greyhat?

Hmm .. so .. signed ebuilds cannot make sure that all code is free of
backdoors and security-bobos. Nevertheless it might make it harder for a
blackhat to place dirty code somewhere in the name of someone else, but
when uploading I belive the user must verify her-/himself by username and
password, which should be kept secret and changed often. And I am not sure
there is more security or so much more security as there is work into
implementing and maintaining such a system.

I believe the gentoo-portage is "secured" this way:

1) Only authorized users are allowed to change/update ebuilds in the live
tree
2) There is some sort of criteria to sort out who's authorized and not
3) The criteria in 2 ensures that the persons allowed to change/update
portage, they will act to best of the Gentoo community.
4) The group of users allowed to apply changes/updates are kept quite
small so that it is easier to find a wolf when there is one.
5) All mirrors are updated from a centralized server.
6) All users download the portage-three with package-checksums from one
server and package-source most likely not from the same mirror. (Hmm..
when one does download it from the same mirror it's possible to both
change the checksum and the source, but when someone downloads it from two
different servers the checksum will not match the source if the source or
the checksum is tampered with. - Thus it should be considered important
that users immidately informs the community ASAP when they discover such
an error. - Emerge denies to continue merging the package into the system
before that package-source matches the checksum.)

This security-model ensures (more or less) that the user have the same
source as the package developer, but - it does not ensure that the source
the package-developer has is free of security vulnerabilities. If one
should be able to controll that it would require that each
ebuild-developer had a holoistic picture containing the whole set of code
a program and program it interacts with have, and aswell require that the
developer will computer security, and has enough understanding and
knowlege. For smaller programs it might be close to possible to do this,
but for lager things (i.e. most packages) it would require huge resources,
and then a rotten apple among many good apples is enough ... :(

What I say is that I am not sure if we ever can make sure computers really
are a safe medium and that the computer does nothing but what we'd like it
to do. Of cource I could program my own computer (say that I trust some
vendors to make the hardware) I could write my very own operating system,
but then it would most likely not interact too well with other computers
(or well .. it would make a huge potensial security-risk.) This of course
is very paranoid and not practical either.

> - If your company uses mirrors to distribute single packages and
> updates, how do you make sure nobody tampers with the packages on those
> mirrors? There are mechanisms to ensure package integrity (e.g. MD5Sum)
> - are these used for all packages or only for ISO images (if you use
> ISOs at all)?

All ebuilds (packages) are equiped with a checksum-file with filesize and
md5sum. When a user have downloaded the source-files, emerge validates
them before it contiunes, compile and install the packages.


Regards,
Christian Skarby