guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Unprivileged /gnu/store with PRoot


From: Ludovic Courtès
Subject: Unprivileged /gnu/store with PRoot
Date: Fri, 12 May 2017 17:53:21 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Hello Guix!

In hostile environments (read: machines that lack Guix and where you’re
not root, such as HPC clusters), it can be hard to manage software with
Guix.

We can use ‘guix pack’ to build a bundle on one machine and ship it to
the target machine.  But then, on the target machine, we need to be able
to “map” the pack’s root directory to the root directory of the
processes we run.

When user namespaces are enabled, this can be achieved with ‘unshare’
and ‘chroot’ as shown at
<https://www.gnu.org/software/guix/news/creating-bundles-with-guix-pack.html>.
However user namespaces are often disabled by distros for lack of
confidence in their security properties¹.

One way to work around the problem is to use PRoot, a ptrace(2)-based
tool to virtualize the file system².  With the ‘proot-static’ package I
just pushed, one can run, say, hwloc, on such a hostile machine by
sending locally-created packs as well as ‘proot’:

  scp $(guix build proot-static)/bin/proot hostile:
  scp $(guix pack hwloc -S /bin=bin) hostile:hwloc.tgz

and then on the hostile machine:

  mkdir ~/.local
  cd ~/.local
  tar xf ~/hwloc.tgz
  cd
  ./proot -b .local:/ /bin/lstopo

where “proot -b .local:/” essentially “bind-mounts” ~/.local to /.

Pretty cool no?  :-)

PRoot adds overhead since it has to intercept every syscall.  However,
for a mostly computational process, it should not be much of a problem.

Ludo’.

¹ See for instance
  
<http://rhelblog.redhat.com/2015/07/07/whats-next-for-containers-user-namespaces/>
  and the recent AF_PACKET vulnerability
  
<https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html>.

² https://github.com/proot-me/PRoot



reply via email to

[Prev in Thread] Current Thread [Next in Thread]