bug#41499: /proc/filesystems impurity in build environment

bug#41499: /proc/filesystems impurity in build environment

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

Hi,

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.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#41499: /proc/filesystems impurity in build environment

[Ludovic Courtès]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> skribis:

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

Thoughts?

Ludo’.

bug#41499: /proc/filesystems impurity in build environment

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

Hi Ludo,

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?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#41499: /proc/filesystems impurity in build environment

[Ludovic Courtès]

Hi,

Chris Marusich <cmmarusich@gmail.com> skribis:

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

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

bug#41499: /proc/filesystems impurity in build environment

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

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

OK.  Thank you for the interesting link!  I'm closing this bug report.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]