From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=DMARC_REJECT, MAILING_LIST_MULTI,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=4.0.0 Received: from other.worlds.no (other.worlds.no [217.8.136.224]) by chiba.3jane.net (Postfix) with SMTP id 5B816AC55B for ; Fri, 11 Oct 2002 16:58:22 -0500 (CDT) Received: (qmail 24574 invoked from network); 11 Oct 2002 21:53:03 -0000 Received: from unknown (HELO skarby.no) (127.0.0.1) by localhost with SMTP; 11 Oct 2002 21:53:03 -0000 Received: from 10.0.7.101 (SquirrelMail authenticated user scaru) by webmail.interhost.no with HTTP; Fri, 11 Oct 2002 23:53:03 +0200 (CEST) Message-ID: <36440.10.0.7.101.1034373183.squirrel@webmail.interhost.no> Date: Fri, 11 Oct 2002 23:53:03 +0200 (CEST) Subject: Re: [gentoo-dev] Gentoo & package security From: "Christian Skarby" To: In-Reply-To: <200210101041.21287.peter.kis@linuxgear.info> References: <200210101041.21287.peter.kis@linuxgear.info> X-Priority: 3 Importance: Normal Cc: X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: f9f85f1b-c575-4962-8a7e-1d116a1e8080 X-Archives-Hash: c78176f49bb237a088c185116c742342 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