all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#41499: /proc/filesystems impurity in build environment
@ 2020-05-24  8:32 Chris Marusich
  2020-05-29 14:56 ` Ludovic Courtès
  0 siblings, 1 reply; 5+ messages in thread
From: Chris Marusich @ 2020-05-24  8:32 UTC (permalink / raw)
  To: 41499

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#41499: /proc/filesystems impurity in build environment
  2020-05-24  8:32 bug#41499: /proc/filesystems impurity in build environment Chris Marusich
@ 2020-05-29 14:56 ` Ludovic Courtès
  2020-05-30  8:23   ` Chris Marusich
  0 siblings, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2020-05-29 14:56 UTC (permalink / raw)
  To: Chris Marusich; +Cc: 41499

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




^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#41499: /proc/filesystems impurity in build environment
  2020-05-29 14:56 ` Ludovic Courtès
@ 2020-05-30  8:23   ` Chris Marusich
  2020-05-30 14:12     ` Ludovic Courtès
  0 siblings, 1 reply; 5+ messages in thread
From: Chris Marusich @ 2020-05-30  8:23 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 41499

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#41499: /proc/filesystems impurity in build environment
  2020-05-30  8:23   ` Chris Marusich
@ 2020-05-30 14:12     ` Ludovic Courtès
  2020-06-02  1:17       ` Chris Marusich
  0 siblings, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2020-05-30 14:12 UTC (permalink / raw)
  To: Chris Marusich; +Cc: 41499

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




^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#41499: /proc/filesystems impurity in build environment
  2020-05-30 14:12     ` Ludovic Courtès
@ 2020-06-02  1:17       ` Chris Marusich
  0 siblings, 0 replies; 5+ messages in thread
From: Chris Marusich @ 2020-06-02  1:17 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 41499-close

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-06-02  1:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-05-24  8:32 bug#41499: /proc/filesystems impurity in build environment Chris Marusich
2020-05-29 14:56 ` Ludovic Courtès
2020-05-30  8:23   ` Chris Marusich
2020-05-30 14:12     ` Ludovic Courtès
2020-06-02  1:17       ` Chris Marusich

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.