Gentoo Archives: gentoo-dev

From: Christian Skarby <christian@××××××.no>
To: peter.kis@×××××××××.info
Cc: gentoo-dev@g.o
Subject: Re: [gentoo-dev] Gentoo & package security
Date: Fri, 11 Oct 2002 16:58:22
In Reply to: [gentoo-dev] Gentoo & package security by Peter Kis
1 I am not officially part of the Gentoo project, so my reply on your mail
2 should not be concidered an official statement from the Gentoo Developers
3 nor from the Gentoo community.
5 > I'm currently working on a feature article on package security. As
6 > there's been yet another CERT advisory
7 > ( concerning already
8 > widely distributed packages that containted a trojan horse, I'm
9 > contacting several major Linux distributors with the following
10 > questions:
11 >
12 > - How do you make sure, your distribution doesn't contain packages
13 > modified by people unauthorized to do so?
15 Well, if one have such a strategy how can one be absolutely sure people
16 authoriezed to modify packages have pure intentions? At some level one
17 just will have to relay on something / others. It is not possible or at
18 least not effective to reinvent wheels every day.
20 On this mailinglist we've had discussions about pgp-signed ebuilds. Then
21 atleast one can trace security-issues back to spesific signatures and make
22 sure that the source is from whom it claims to be. But secure
23 authentification is not easy to set up and not between people not knowing
24 eachother in person. Two people knowing eachother can easily and securly
25 exchange public-keys this way: Person A generates a crypto-key-pair
26 (private and public, where private key can decrypt messages encrypted with
27 the public key and private key can sign messages, which signature could be
28 verifyed by the public key,) as I said person A generates a
29 crypto-key-pair and sends the public-key to person B by email. At the time
30 B receives this (s)he cannot be 100% sure the key (s)he received in the
31 mail is the key of which A sent. (A person C can teoretically replace the
32 key with an man-in-the-middle-strategy replacing As key while it is
33 transported via other computers from A to B.) So B should now have a phone
34 call with A, and recognize A by voice. When A read her/his publickey's
35 fingerprint to B, B can verify that this indeed is A's public key. Now B
36 can generate a key-pair, encrypt her/his public-key with A's public-key
37 and thus only persons having access to A's private-key can export B's
38 public-key. A can then verify B's key by decryption. - Okey .. but what if
39 A and B do not know eachother .. then they cannot be sure the person they
40 meet in reallife is the great programmer they've talked with on the
41 internett, and well .. if the can, and even if they know eachother .. how
42 can they be absolutely sure the other is not a blackhat or a greyhat?
44 Hmm .. so .. signed ebuilds cannot make sure that all code is free of
45 backdoors and security-bobos. Nevertheless it might make it harder for a
46 blackhat to place dirty code somewhere in the name of someone else, but
47 when uploading I belive the user must verify her-/himself by username and
48 password, which should be kept secret and changed often. And I am not sure
49 there is more security or so much more security as there is work into
50 implementing and maintaining such a system.
52 I believe the gentoo-portage is "secured" this way:
54 1) Only authorized users are allowed to change/update ebuilds in the live
55 tree
56 2) There is some sort of criteria to sort out who's authorized and not
57 3) The criteria in 2 ensures that the persons allowed to change/update
58 portage, they will act to best of the Gentoo community.
59 4) The group of users allowed to apply changes/updates are kept quite
60 small so that it is easier to find a wolf when there is one.
61 5) All mirrors are updated from a centralized server.
62 6) All users download the portage-three with package-checksums from one
63 server and package-source most likely not from the same mirror. (Hmm..
64 when one does download it from the same mirror it's possible to both
65 change the checksum and the source, but when someone downloads it from two
66 different servers the checksum will not match the source if the source or
67 the checksum is tampered with. - Thus it should be considered important
68 that users immidately informs the community ASAP when they discover such
69 an error. - Emerge denies to continue merging the package into the system
70 before that package-source matches the checksum.)
72 This security-model ensures (more or less) that the user have the same
73 source as the package developer, but - it does not ensure that the source
74 the package-developer has is free of security vulnerabilities. If one
75 should be able to controll that it would require that each
76 ebuild-developer had a holoistic picture containing the whole set of code
77 a program and program it interacts with have, and aswell require that the
78 developer will computer security, and has enough understanding and
79 knowlege. For smaller programs it might be close to possible to do this,
80 but for lager things (i.e. most packages) it would require huge resources,
81 and then a rotten apple among many good apples is enough ... :(
83 What I say is that I am not sure if we ever can make sure computers really
84 are a safe medium and that the computer does nothing but what we'd like it
85 to do. Of cource I could program my own computer (say that I trust some
86 vendors to make the hardware) I could write my very own operating system,
87 but then it would most likely not interact too well with other computers
88 (or well .. it would make a huge potensial security-risk.) This of course
89 is very paranoid and not practical either.
91 > - If your company uses mirrors to distribute single packages and
92 > updates, how do you make sure nobody tampers with the packages on those
93 > mirrors? There are mechanisms to ensure package integrity (e.g. MD5Sum)
94 > - are these used for all packages or only for ISO images (if you use
95 > ISOs at all)?
97 All ebuilds (packages) are equiped with a checksum-file with filesize and
98 md5sum. When a user have downloaded the source-files, emerge validates
99 them before it contiunes, compile and install the packages.
102 Regards,
103 Christian Skarby


Subject Author
Re[2]: [gentoo-dev] Gentoo & package security Henti Smith <bain@××××××××××××××××××××.za>
Re: [gentoo-dev] Gentoo & package security Jean-Michel Smith <jean@××××.com>