/proc/filesystems impurity in build environment

> The Linux kernel's /proc/filesystems is an impurity in the Guix build

> environment. Its contents can cause the same derivation to behave

> differently on different systems.

>

> For example, the default kernel on Fedora systems uses SELinux, so

> /proc/filesystems contains "selinuxfs". However, the default kernel on

> Guix System does not use SELinux, so /proc/filesystems does not contain

> "selinuxfs". This causes the sed derivation to fail when run on Fedora,

> but not on Guix System:

>

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41498

>

> Can we avoid this problem somehow? For example, is there a way to

> normalize /proc/filesystems in the build environment?

>

> We have the --impersonate-linux-2.6 option as a way to eliminate a

> similar kind of impurity, but that option doesn't actually change the

> contents of /proc/filesystems at all. I tried it.

> 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.

> Ludovic Courtès <ludo@gnu.org> 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?

> 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.