Support build users on unprivileged users with subuid/subgid#15183
Conversation
github-actions
Bot
added
the
store
artemist
force-pushed
the
newuidmap
branch
2 times, most recently
from
e1401af to
80fb324
Compare
|
One thing I'm unsure about is getting nswrapper to build only on linux. The build infrastructure seems to assume that every subproject is built for all systems, and I'm not sure if I will break anything by changing that. I'd also need to change that assumption in a few places, but that shouldn't be too bad. |
artemist
force-pushed
the
newuidmap
branch
5 times, most recently
from
fc45e0a to
92df9ec
Compare
|
I am somewhat surprised that macos tests built, I guess we don't have any testing running the full meson build. I just pushed a new change that makes it only attempt to build nswrapper on linux |
Ericson2314
force-pushed
the
newuidmap
branch
from
92df9ec to
e0c3667
Compare
artemist
force-pushed
the
newuidmap
branch
2 times, most recently
from
56ff9e1 to
0dab126
Compare
|
Seems that the issue with running |
| throw SysError("dropping groups"); | ||
|
|
||
| // We have to mount a new devpts, otherwise we won't be able to chown ptses for build users | ||
| if (mount("none", "/dev/pts", "devpts", 0, "mode=0620") < 0) |
There was a problem hiding this comment.
This is intended to use the hosts /dev/pts or a fresh one?
There was a problem hiding this comment.
This is intended to be the same as the host, but I don't believe it's strictly necessary. AIUI if i were mounting a new instance I would want to symlink /dev/ptmx to /dev/pts/ptmx, which would require mounting a new /dev. That /dev wouldn't have all the symlinks generated by systemd-udevd which nix might want to use, e.g. when impurely passing in devices. I'm not sure if that's entirely true though.
| if (argc < 4) | ||
| throw UsageError("Usage: %1% first_uid num_uids command [args...]", argv[0]); |
There was a problem hiding this comment.
Should we factor this out to print on error? Ideally we'd have some helper function for creating libexec wrappers more concisely and print the usage message on all UsageError cases.
There was a problem hiding this comment.
We already have nix::Args, but it's somewhat complicated to use outside of the existing command structure.
There was a problem hiding this comment.
Yeah Args is super complex, and I hope to move it out of libutil --- it is far too opinionated for that.
| auto baseExtra = parseUid(argv[1]); | ||
| auto numExtra = parseUid(argv[2]); |
There was a problem hiding this comment.
Should there be some checks that the uids don't step on system uid ranges?
There was a problem hiding this comment.
We could add additional checks (Maybe that the id is above 1 << 16?), but newuidmap or newgidmap will fail if the ids aren't already in /etc/subuid or /etc/subgid, which requires manual administrator intervention.
There was a problem hiding this comment.
Yeah it is new*map's responsibility not do a bad thing, not ours. The setuid binaries have to be hardened to things.
artemist
force-pushed
the
newuidmap
branch
2 times, most recently
from
e70dfd7 to
bfc0c12
Compare
nix-nswrapper allows running nix in its own user namespace,
believing it is root and with access to build users for sandboxing
with auto-allocate-uids, while it is actually unprivileged.
It is used to wrap nix, and an example of its use has been
added to the unprivileged daemon functional tests.
Running it does not require any elevated privileges,
only uids and gids allocated in /etc/sub{uid,gid}
Support build users on unprivileged users with subuid/subgid
4 participants
Motivation
Some users, especially on non-NixOS systems, may want to run an unprivileged daemon, so as to reduce the possible escalation if the daemon is exploited. Currently, doing so would prevent the daemon from using build users for isolating builds, making it substantially less secure.
However, with unprivileged user namespaces it is possible to become what looks like root, but without gaining any actual new permissions. With this and the
newuidmapandnewgidmapexecutables available on base linux we can allow the nix daemon to run builds as statically allocated build users without running as actual root.Context
I have attempted this several other ways, including with nsresourced (#15103), but they all faced issues. Allocating uids with a call to
newuidmapandnewgidmapappears the most likely to work, as we can map both the daemon user and all allocated build users into the same namespace.The least invasive change appeared to be to wrap the entire nix daemon so it thinks it's running as root. In that case it can use the existing
auto-allocate-uidslogic without any changes to core nix.This is a very early draft and will need quite a few changes before I consider it ready.
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.