Risk of local privilege escalation via guix-daemon
A security vulnerability that can lead to local privilege escalation has been
It affects multi-user setups in which
guix-daemon runs locally.
It does not affect multi-user setups where
guix-daemon runs on a
separate machine and is accessed over the network via
GUIX_DAEMON_SOCKET, as is customary on cluster
Exploitation is more difficult, but not impossible, on machines where
the Linux protected
is enabled, which is common — this is the case when the contents of
The attack consists in having an unprivileged user spawn a build process, for
guix build, that makes its build directory world-writable. The
user then creates a hardlink to a root-owned file such as
/etc/shadow in that
build directory. If the user passed the
--keep-failed option and the build
eventually fails, the daemon changes ownership of the whole build tree,
including the hardlink, to the user. At that point, the user has write access
to the target file.
This bug has been fixed. See below for upgrade instructions.
The fix consists in adding a root-owned “wrapper” directory in which the build
directory itself is located. If the user passed the
--keep-failed option and
the build fails, the
guix-daemon first changes ownership of the build
directory, and then, in two stages, moves the build directory into the location
where users expect to find failed builds, roughly like this:
chown -R USER /tmp/guix-build-foo.drv-0/top
mv /tmp/guix-build-foo.drv-0.pivot/top /tmp/guix-build-foo.drv-0
In step #1,
/tmp/guix-build-foo.drv-0 remains root-owned, with permissions of
#o700. Thus, only root can change directory into it or into
top. Likewise in
The build tree becomes accessible to the user once step #3 has succeeded, not before. These steps are performed after the package build scripts have stopped running.
On multi-user systems, we recommend upgrading the
To upgrade the daemon on Guix System, run something like:
guix pull sudo guix system reconfigure /run/current-system/configuration.scm sudo herd restart guix-daemon
On other distros, use something like this:
sudo --login guix pull sudo systemctl restart guix-daemon.service
One of the flagship features of GNU Guix is to enable unprivileged package management, which includes building packages. Building occurs in an isolated build environment. This environment is isolated from the rest of the system not only to control the build process to implement the functional packaging model, but also to protect the system from package build scripts.
Despite our best efforts, there is always the possibility that we have overlooked something, as in this case.
This issue is tracked as bug #47229; you can read the thread for more information.
We are grateful to Nathan Nye of WhiteBeam Security for reporting this bug.
Please report any issues you may have to
email@example.com. See the
security web page for information
on how to report security issues.
About GNU Guix
GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the Hurd or the Linux kernel, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.
In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.
Related topics:Security Advisory