Re: [gentoo-dev] An example overlayfs sandbox test

[James McMechan]

On Fri, Sep 22, 2017 at 7:26 PM, Rich Freeman <rich0@g.o> wrote:
>On Fri, Sep 22, 2017 at 6:29 PM, James McMechan <james_mcmechan@×××××××.com> wrote:
>> On Fri, Sep 22, 2017 at 5:18 PM, Rich Freeman <rich0@g.o> wrote:
>>>On Fri, Sep 22, 2017 at 4:43 PM, James McMechan
>>><james_mcmechan@×××××××.com> wrote:
>>>>
>>>> # now create a separate mount namespace non-persistent
>>>> unshare -m bash
>>>>
>>>
>>>If you're going to go to the trouble to set up a container, you might
>>>as well add some more isolation:
>>>
>>>unshare --mount --net --pid --uts --cgroup --fork --ipc --mount-proc bash
>>>
>>
>> I would not want to change the networking, it should already be working
>> and I would be better served by not messing with it.
>>
>
>Well, that's the point.  You don't want networking to work during the
>build phases.  Maybe you'd want it for the test phase.  In any case,
>you would definitely want control over that in the ebuild.  Random
>build systems shouldn't be talking to the internet, if for no other
>reason than to avoid it fetching stuff to install that bypasses the
>integrity checks.
>
>If you create a new net namespace by default it won't have any
>interfaces other than lo.

Err, perhaps I was thinking of doing the switch too early, I had been thinking
of making sure networking works for the fetch phase...

>> The --mount-proc is not really helpful as I immediately remount the entire
>> "/" filesystem at /mnt/gentoo and chroot into it after custom setup of proc sys and dev
>>
>
>As long as it doesn't see the host /proc then you're fine.  You just
>wouldn't want to have it mounted into the container.

I am pretty sure a /proc needs to be mounted inside of any container if you want builds
to work. mount, ps, and a lot of other stuff does not work without it.

I think you mean that only the container /proc is mounted.

>> Now I could see a use for  --map-root-user --user, then portage could run as
>> root in the container with the least danger by being user portage:portage outside.
>>
>
>Certainly, but that takes a bit more work, and to be honest I've never
>actually bothered to get it working using unshare.  It probably isn't
>too difficult.

You were right, I just tried it and it seemed easy enough.

>The options I listed basically "just work" without any real additional effort.

I like the lack of effort part ;) I want the computer doing the work not me.

>So, we're drifting in topic, but as long as we're coming up with
>nice-to-have utilities it would be lovely if our install CDs had
>something similar to systemd-nspawn to set up a container instead of a
>chroot for performing the install.  If nothing else it would make
>mount cleanup easier when you're done.  I imagine it would just be a
>bit of shell scripting with util-linux on the CD - while nspawn is
>bundled with systemd you don't need any of its fancier features for
>doing an install.

Ok, but what is the advantage? the mounts disappearing when you exit
the container, and anything else?

>Back on topic - none of this stuff will work on FreeBSD, which might
>be an issue for those running Gentoo on that kernel.  Ditto for Prefix
>I suppose.  I suspect that jails/etc would also do the job but you'd
>need some arch-dependent code to set up the container.  Just about all
>of these tricks are involving non-POSIX functionality.  Actually, I'm
>not sure if even the current LD_PRELOAD approach is completely
>portable, though it has the advantage of being entirely in userspace.

I don't see any BSD stuff on the download page, so it slips my mind.

I have not used any of the BSD derived systems in quite a few years.
A quick glance shows they are running things like docker so container
like functionality exists, and I seem to remember that Linux was late to
the overlay stuff, the freeBSD mount_unionfs says it went in as
mount_null in 4.4BSD according to the man page so that is present also.

Regarding prefix, or maybe RAP does sandbox even work there?

It looks like prefix uses the host system's library... would either method
sandbox currently uses work?

RAP appeared to have it's own C library so it should be possible there
I do not remember if sandbox worked under RAP it the whole project felt
very experimental when I tried it.

I think non-linux systems did adopt LD_PRELOAD and ptrace some,
I do not think either was in any of the POSIX versions though I did not
look much at the last version, it seemed mostly irrelevant by then.

Enjoy,

Jim McMechan