Re: [gentoo-dev] Reviving the Sandbox project

[Patrick McLean]

On 2017-09-22 10:03 AM, Brian Dolbec wrote:
> On Fri, 22 Sep 2017 15:06:49 +0000
> James McMechan <james_mcmechan@×××××××.com> wrote:
>
>> On Fri, Sep 22, 2017 at 5:27 AM, Rich Freeman <rich0@g.o>
>> wrote:
>>> On Fri, Sep 22, 2017 at 7:38 AM, Sergei Trofimovich
>>> <slyfox@g.o> wrote:
>>>>
>>>> Some other distros try harder to isolate build environment either
>>>> through chroot and/or private mount/user/network namespace that
>>>> contains only explicitly specified files in build environment.
>>>>
>>>> That would require more cooperation from package manager to fetch
>>>> list of all visible depends.
>>>>
>>>
>>> I definitely think this is something that would be VERY useful to
>>> have, because it makes build-time dependency issues almost
>>> impossible.
>>>
>>> However, you don't need that complete solution just to have a
>>> sandbox. You could simply create a container with the entire
>>> contents of the main filesystem, but read-only, with the exception
>>> of the build area. That would replicate the functionality of the
>>> current sandbox and would be easier than building out just the files
>>> specified in the dependencies.
>>>
>>> The main issue I see with making it dependency aware is performance.
>>> You would need to walk all the dependencies and their run-time
>>> dependencies, and the system set, and then individually bind-mount
>>> the files that belong to them read-only into the container.  That
>>> isn't necessarily difficult, but I imagine that it would be slow.
>>> Walking the dependencies obviously already happens during resolution
>>> so that could probably be cached.  You could also cache the list of
>>> files for the system set, and you could even maintain a snapshot of
>>> these that is used as the base of the container (somebody would need
>>> to work out the savings of doing this vs the cost of updating it
>>> every time a system set package changes).
>>>
>>> However, the main thing I wanted to point out is that you don't need
>>> a dependency-aware solution to just replace the existing sandbox.
>>>
>>>> I like clear sandbox error reporting.
>>>
>>> As far as error reporting goes, you would get kernel-level errors
>>> like attempting to write to a read-only bind mount, or trying to
>>> read a file that doesn't exist.  To a portage dev it should be
>>> pretty obvious what is going on.  You could add canned text to the
>>> portage error output at the end.  I'm not sure how visible the
>>> problems would be to portage except to the degree that the build
>>> system makes them visible
>>> - it would just see make terminate with a non-zero return.
>>>
>>> I would think that containers would be almost completely bug-free
>>> though.  The only thing I could see as an issue is some build system
>>> that relies on IPC with the host, network access, etc.  Namespaces
>>> themselves are very robust, and the kernel already looks at every
>>> process as belonging to a set of namespaces even in the default case
>>> where you only have one set of namespaces on the system, so they
>>> don't involve different code paths/etc.
>>>
>>> --
>>> Rich
>>
>> Another possibility, could be to have the sandbox be an overlayfs
>> not of the build directory but of the entire system starting at "/"
>> and stick that into the container, only CLONE_NEWNS looks to be
>> needed.
>>
>> A container with all writes going to the upper layer of the overlay
>> could be safe against even #RM -RF / and other disasters, while still
>> tracking what is happening during the build.
>>
>> Should performance be too much of a problem having a bind mount of
>> the build directory on top of the overlay should give normal
>> performance to everything that is obeying good practice.
>>
>> After the build completes the directory that was mounted as upper
>> could be scanned to find any wayward writes that had occurred...
>>
>> This would not require LD_PRELOAD or ptrace eliminating most of the
>> "high magic" currently used.
>>
>> Just yesterday I had a lot of ptrace failures while trying something
>> odd with ROOT= and custom USE
>>
>> Jim McMechan
>
> I kinda like this idea, It looks to me to have pretty much all the
> benefits of a sandbox and nearly none of the drawbacks.
>
> Sounds like it should get more research into this idea, figure out it's
> limitations and if there are any caveats.
>

I haven't had time as of yet to look in to it, but theoretically one
could use seccomp with bpf to make a more robust sandbox, though you
might not get as nice error reporting as we have now.

Also apparmor could theoretically be used to make a nice sandbox, but I
suspect that could come with other implications.