[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41499: /proc/filesystems impurity in build environment
From: |
Ludovic Courtès |
Subject: |
bug#41499: /proc/filesystems impurity in build environment |
Date: |
Sat, 30 May 2020 16:12:08 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
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’.