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

[Martin Vaeth]

Rich Freeman <rich0@g.o> wrote:
> On Sun, Sep 24, 2017 at 4:24 AM, Martin Vaeth <martin@×××××.de> wrote:
>> Tim Harder <radhermit@g.o> wrote:
>>
>> It is the big advantage of overlay that it is implemented in
>> kernel and does not involve any time-consuming checks during
>> normal file operations.
>
> Why would you expect containers to behave any differently?

For overlay, there is only one directory to be checked in
addition for every file access.

For containers, at least a dozens of binds are minimally required
(/usr /proc /sys /dev ...). But as you mentioned in your posting,
if you want to take more care you easily have thousands of bind mounts.
At least implicitly in the kernel, all of these binds must be checked
for every file access. I am not sure whether this happens very quickly
by hashing (so that essentially really only the creation costs time).

As mentioned, I do not have actual timing results. I am just afraid
that it might easily cost more than a context-switch which already
gives a slowdown for fuse-overlay which is so large that I would
not recommend it for a sandbox.

> Now, I am concerned about the time to create the container, if we're
> going to specify individual files, but the same would be true of an
> overlay. [...]
> to populate an overlayfs with just that specific list of files.

No. For overlay you need only one mount (not even a bind)
and only one directory traversal at the end to check for
violations.
The nice thing is that this is practically independent of
the number or structure of directories/files you want to protect,
i.e. it scales perfectly well.
For the more fine-grained approach, you just delete the files
you do not want to have in the beginning. Not sure, how quick this
can be done, but once it is done, the slowdown when running the
sandbox is independent of the number of deleted files (because
here certainly only one hash lookup is required).

Of course, as mgorny already observed, overlay alone is not an
absolute protection (e.g. against writing to some /dev/...),
so perhaps it is a good idea to use containers as an additional
protection level.

> If you just replicate the current sandbox
> functionality then setup time is tiny

I am not so much concerned about the setup time but more about the
delay caused for file operations once the sandbox is set up.
Perhaps even a dozen bind directories already give a considerable
slowdown...