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... |