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

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

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]