Hi Ludo, Ludovic Courtès <[email protected]> writes:
> The daemon mounts /proc in the build environment (see
> libstore/build.cc):
>
> /* Bind a new instance of procfs on /proc to reflect our
> private PID namespace. */
> createDirs(chrootRootDir + "/proc");
> if (mount("none", (chrootRootDir + "/proc").c_str(), "proc", 0, 0) == -1)
> throw SysError("mounting /proc");
>
> /proc is needed for many things on GNU/Linux. For example, libc’s
> loader relies on /proc/self/exe to implement $ORIGIN, ‘getlogin_r’
> relies on /proc/self/loginuid, ‘ttyname’ uses /proc/self/fd, ‘sysconf’
> uses /proc/sys/kernel, etc. So we have to have /proc in there.
>
> The problem is that /proc appears to be all-or-nothing.
>
> What we could do maybe is bind-mount our own statically-defined
> ‘filesystems’ file on top of the procfs mount above.
>
> There would still be many leaks in /proc anyway, so perhaps a better
> approach is to patch ‘sed’ to not refer to it.
That makes sense. I have submitted an upstream patch to fix sed:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36150
It could be fun to investigate how far we can go with respect to
limiting access in the sandbox to a minimal, uniform set of kernel
features. However, unless issues like this become more common, it may
not be that big of an issue.
Shall we close this bug report, then?
--
Chris
signature.asc
Description: PGP signature
