Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
Date: Mon, 04 Feb 2019 14:44:10
Message-Id: CAGfcS_ntcns81Ea_wCxAX49ug9UR-my77hXzSDkPvGQGEFiuBw@mail.gmail.com
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. -- Rich