Hi, Chris Marusich <[email protected]> skribis:
> 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. There’s /proc, but there are also syscalls that leak info, such as uname(2). Fortunately these issues are quite rare in practice (it’s mentioned in <https://guix.gnu.org/blog/2015/reproducible-builds-a-means-to-an-end/>, which references an earlier NixOS paper that discusses it.) > Shall we close this bug report, then? I think so. Thanks, Ludo’.
