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
1 On 2019-02-04 10:09 a.m., Alexis Ballier wrote:
2 > On Mon, 4 Feb 2019 09:43:53 -0500
3 > Rich Freeman <rich0@g.o> wrote:
4 >
5 >> On Mon, Feb 4, 2019 at 9:35 AM Alexis Ballier <aballier@g.o>
6 >> wrote:
7 >>>
8 >>> On Mon, 04 Feb 2019 15:13:36 +0100
9 >>> Michał Górny <mgorny@g.o> wrote:
10 >>>
11 >>>> 2. By design, postinst is run with full privileges. It is meant
12 >>>> to allow ebuilds to run stuff, as root.
13 >>>
14 >>> And that is precisely that kind of design that makes it hard or
15 >>> unrealistic to have unreviewed global repositories.
16 >>>
17 >>
18 >> Unless you're doing something like per-app sandboxes at runtime fixing
19 >> this is just shifting the problem elsewhere.
20 >>
21 >> Ok, so the package can't run stuff at root at time of install. But,
22 >> it can drop whatever shell script it wants into /etc/cron.hourly, or
23 >> enable some service by default. Or it can stick something in the
24 >> default shell profile. Or it can install /sbin/bash which is ahead of
25 >> /bin/bash in PATH, or whatever.
26 >>
27 >> If malware is recognized as a legitimate package by your package
28 >> manager, you've basically already lost, at least in the typical
29 >> linux/unix-like access control model. Now, if you're doing
30 >> unconventional things like android does with uids or putting 3 layers
31 >> of SELinux on top of everything then you can have more defense in
32 >> depth. But, that also requires sandboxing your package manager so
33 >> that it can't tamper with ALL of your security.
34 >>
35 >> As mgorny has already pointed out, you can't just sandbox package
36 >> phases to fix the problem. I think sandboxing your build system is a
37 >> great way to improve build system QA in general, but it doesn't solve
38 >> intrusion.
39 >>
40 >
41 >
42 > Ok, so the claim here is that installing is more or less the same as
43 > running wrt malicious code. Fine.
44 >
45 > Now, I want to install an ebuild from that overlay: I review said
46 > ebuild, seems fine, so I add & enable the overlay. Except, someone just
47 > pushed a malicious app-shells/bash running malicious code at global
48 > scope. Last I checked portage will source it and in the best case
49 > output a warning about running commands at global scope. I am now pwned.
50 >
51
52 All of this doesn't even get to the much more common issue we are
53 going to face, which is simply that these ebuilds and packages are
54 more often than not going to be outright broken. The sunrise project
55 had a big barrier to entry for a lot of folks because of the review
56 process that enforced ebuild structure and quality well above what
57 repoman can do. So forgetting about someone actively deciding to
58 rootkit a bunch of folks, what're we going to do about the ebuilds
59 that are going to break everyone's deptree resolution, or have a ton
60 of automagic deps that cause havoc on the next -uDN ?
61
62 Even if we do a two-layer repo where the 'public' one is only rolled
63 forward when a gentoo-ci run passes cleanly, that only fixes so much
64 AND it'll cause the project to stall when nobody bothers to fix the
65 blockages. I assume we aren't to the point where gentoo-ci runs on
66 every individual commit and then kicks out the one(s) that fail while
67 rebasing to test and accept others...

Attachments

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

Replies