Re: linux-user-chroot: Mounting more stuff inside the chroot

[Colin Walters <walters verbum org>]

On Fri, Jun 5, 2015, at 05:40 AM, Sam Thursfield wrote:
> Good idea, I hadn't thought of that. I'm actually wrapping 
> linux-user-chroot in a little Python library called sandboxlib (I know, 
> "solving" problems by adding new abstraction layers...), so can put the 
> this mktemp code in there.

That type of thing is definitely intended!  I see l-u-c as a "core engine",
and because it's setuid we want to have as little code in it as possible.

Very occasionally I do things like:

$ linux-user-chroot --unshare-net / ping localhost

to test out commands with no network stack quickly, but it's
usable enough for that I think.

I haven't yet hit a program requiring /dev/shm.

Thinking about this a bit more...we could split l-u-c into two parts,
having an unprivileged entrypoint program that can do all sorts of
things like this /dev/shm setup, then it execve()s into l-u-c-setuid.

So maybe we could rethink your --mount-dev-shm ?

> The mindset we've always had for reproducibility is "everything must 
> always be reproducible", i.e. try to force it for the unreasonable 
> programs as well.

If you're going down that path seriously, see
https://lwn.net/Articles/630074/
and
https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details

if you haven't already.

One notable point: Making things output deterministic binaries actually
helps OSTree, because then recompiling won't cause downloads.

> As I said above I've moved our existing sandboxing code into a 
> standalone Python library: 
> <https://github.com/CodethinkLabs/sandboxlib>. This adds a new level of 
> abstraction, but that means we can move away from linux-user-chroot if 
> something better appears (it also means we can fall back to 'chroot' on 
> non-Linux). So I'll only  want to add code to linux-user-chroot if 
> that's the best place for it.

Cool, I added a link to this here:
https://git.gnome.org/browse/linux-user-chroot/commit/?id=1ab0cc3bc401c8e5578dd1da05aed502544e5183

> I've done a bit of digging around other tools as well. You're right that 
> it's hard to find a container tool that doesn't require 'root' at 
> present. Seems weird that nobody in the has visibly attacked that 
> problem yet, but I guess it's quite intractable with all the networking 
> and namespace setup that needs to be done. I do think the App Container 
> spec has promise as it's so simple. I was happy to find out that 'rkt' 
> wraps 'systemd-nspawn' as well...

I definitely have on my TODO list teaching Docker how to do
what linux-user-chroot is doing.  Combine that with some work
we (Red Hat) are doing on
https://github.com/rhatdan/docker-rbac
it'd be possible to grant access to regular users to create
unprivileged containers.

Comparing that versus l-u-c, you'd get access to all of the Docker
ecosystem and tooling/API.

But it's still in the future, where l-u-c exists, works, and was secure
for this purpose before Docker existed ;)
 
> I confess I've punted looking closely at xdg-app and Sandstorm.io so 
> far. I had in my head that SECCOMP would be too limiting for a build 
> system, but now I see there's a trick where you have a privileged thread 
> communicating with the SECCOMP sandbox.

I'm thinking more about the blacklist approach rather than whitelist.

Specifically blacklisting things like the perf system call which
have had numerous holes.

The privileged broker approach comes in when you're doing a lot
more extensive filtering.

> As I said above, probably the only 'perfect' solution for build 
> sandboxing is to virtualise the entire machine. 
> <https://lwn.net/Articles/644675/> describes some work Intel have done 
> with really fast-loading KVM containers. But that's x86 only, and it 
> seems quite a way off being ready (I couldn't actually get the "Clear 
> Containers" demo to work at all).

The issue with virt that I have is getting data in and out.  For l-u-c
as a build system, I can just --mount-bind /path/to/some/git /src/git
and go.  With virt I'd have to copy it in, and that gets nontrivial.

Also things like getting core dumps out if a program crashes.

There is 9p...but the farther you go down that route, the more of
the kernel attack surface you're exposing and the closer you
are to containers...