Gentoo Archives: gentoo-project

From: Ian Stakenvicius <axs@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
Date: Mon, 04 Feb 2019 17:06:49
Message-Id: 5ad9da44-3596-c3ce-aa58-e2f56f90dfad@gentoo.org
In Reply to: Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed] by Alexis Ballier
On 2019-02-04 10:09 a.m., Alexis Ballier wrote:
> On Mon, 4 Feb 2019 09:43:53 -0500 > Rich Freeman <rich0@g.o> wrote: > >> On Mon, Feb 4, 2019 at 9:35 AM Alexis Ballier <aballier@g.o> >> wrote: >>> >>> On Mon, 04 Feb 2019 15:13:36 +0100 >>> Michał Górny <mgorny@g.o> wrote: >>> >>>> 2. By design, postinst is run with full privileges. It is meant >>>> to allow ebuilds to run stuff, as root. >>> >>> And that is precisely that kind of design that makes it hard or >>> unrealistic to have unreviewed global repositories. >>> >> >> Unless you're doing something like per-app sandboxes at runtime fixing >> this is just shifting the problem elsewhere. >> >> Ok, so the package can't run stuff at root at time of install. But, >> it can drop whatever shell script it wants into /etc/cron.hourly, or >> enable some service by default. Or it can stick something in the >> default shell profile. Or it can install /sbin/bash which is ahead of >> /bin/bash in PATH, or whatever. >> >> If malware is recognized as a legitimate package by your package >> manager, you've basically already lost, at least in the typical >> linux/unix-like access control model. Now, if you're doing >> unconventional things like android does with uids or putting 3 layers >> of SELinux on top of everything then you can have more defense in >> depth. But, that also requires sandboxing your package manager so >> that it can't tamper with ALL of your security. >> >> As mgorny has already pointed out, you can't just sandbox package >> phases to fix the problem. I think sandboxing your build system is a >> great way to improve build system QA in general, but it doesn't solve >> intrusion. >> > > > Ok, so the claim here is that installing is more or less the same as > running wrt malicious code. Fine. > > Now, I want to install an ebuild from that overlay: I review said > ebuild, seems fine, so I add & enable the overlay. Except, someone just > pushed a malicious app-shells/bash running malicious code at global > scope. Last I checked portage will source it and in the best case > output a warning about running commands at global scope. I am now pwned. >
All of this doesn't even get to the much more common issue we are going to face, which is simply that these ebuilds and packages are more often than not going to be outright broken. The sunrise project had a big barrier to entry for a lot of folks because of the review process that enforced ebuild structure and quality well above what repoman can do. So forgetting about someone actively deciding to rootkit a bunch of folks, what're we going to do about the ebuilds that are going to break everyone's deptree resolution, or have a ton of automagic deps that cause havoc on the next -uDN ? Even if we do a two-layer repo where the 'public' one is only rolled forward when a gentoo-ci run passes cleanly, that only fixes so much AND it'll cause the project to stall when nobody bothers to fix the blockages. I assume we aren't to the point where gentoo-ci runs on every individual commit and then kicks out the one(s) that fail while rebasing to test and accept others...

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies