boringtun
boringtun copied to clipboard
cloudflare
Not dropping root privileges running on macOS 11.6.1
Good afternoon,
I've just been testing boringtun on macOS but noticed that when I run using the following command, that it does not drop root privileges.
sudo WG_QUICK_USERSPACE_IMPLEMENTATION=boringtun WG_SUDO=1 wg-quick down ~/wireguard/example.conf
The boringtun process is running as root.
Cheers, -Chris
Hey @Noah-Kennedy I tried installing but received the following dependency error:
❯ cargo install boringtun
Updating crates.io index
Downloaded boringtun v0.4.0
Downloaded 1 crate (414.3 KB) in 0.65s
Installing boringtun v0.4.0
Downloaded itoa v1.0.1
Downloaded num_threads v0.1.3
Downloaded cfg-if v1.0.0
Downloaded ip_network_table-deps-treebitmap v0.5.0
Downloaded once_cell v1.9.0
Downloaded pin-project-lite v0.2.8
Downloaded parking_lot_core v0.9.1
Downloaded scopeguard v1.1.0
Downloaded libc v0.2.117
Downloaded parking_lot v0.12.0
Downloaded log v0.4.14
Downloaded smallvec v1.8.0
Downloaded tracing-attributes v0.1.19
Downloaded unicode-xid v0.2.2
Downloaded untrusted v0.9.0
Downloaded tracing-subscriber v0.3.8
Downloaded thread_local v1.1.4
Downloaded tracing-appender v0.2.0
Downloaded time v0.3.7
error: failed to compile `boringtun v0.4.0`, intermediate artifacts can be found at `/var/folders/hb/2mnxsd9x0bs4c6_2ldwz30km0000gq/T/cargo-installSDr0Oi`
Caused by:
failed to parse manifest at `/Users/cjones/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.3.7/Cargo.toml`
Caused by:
feature `resolver` is required
this Cargo does not support nightly features, but if you
switch to nightly channel you can add
`cargo-features = ["resolver"]` to enable this feature
Gonna try an run this on an old macbook I've got. It ran fine on CI so this is kinda weird.
@autonomic what version of the rust toolchain are you running? This looks like an issue where you are running an older version of the compiler and it isn't detecting newer cargo features.
Also, it works on my macbook. Pretty sure that rustup update will fix this for you, but I'd like to know what version you are running as well.
I'm running the latest version from Homebrew.
❯ brew info rust
rust: stable 1.58.1 (bottled), HEAD
Safe, concurrent, practical language
https://www.rust-lang.org/
/usr/local/Cellar/rust/1.58.1 (33,798 files, 840.2MB) *
Poured from bottle on 2022-01-24 at 08:01:42
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/rust.rb
License: Apache-2.0 or MIT
==> Dependencies
Build: cmake ✔, ninja ✘, [email protected] ✔
Required: libssh2 ✔, [email protected] ✔, pkg-config ✔
==> Options
--HEAD
Install HEAD version
==> Caveats
zsh completions have been installed to:
/usr/local/share/zsh/site-functions
==> Analytics
install: 39,436 (30 days), 90,085 (90 days), 348,169 (365 days)
install-on-request: 24,774 (30 days), 51,317 (90 days), 188,965 (365 days)
build-error: 463 (30 days)
Can you give me the output of cargo --version? I get the brew package, but there is something else I want to see.
@autonomic In general I'd avoid any distro or other package mangager installs of the compiler or cargo, and would just use rustup, which is the more official way to do things.
After upgrading boringtun to 0.4.0 it's still not dropping root privileges.
root 16506 0.0 0.0 4327092 2236 ?? S 10:17PM 0:00.02 boringtun utun
Alright, I figured this might be the case. This can get fixed later in a point release, now that boringtun is going to be shipping regularly again (I released 0.4.0 today). PRs are welcome from anyone interested in this. I probably wouldn't be able to get to this for a while.
@Noah-Kennedy @autonomic: I took a crack at it. Let me know if my approach is valid.
Cheers!
Just installed boringtun-cli 0.5.0 and still running into the issue where it does not drop privs and the borningtun-cli process is running as root. Running like so:
"sudo WG_QUICK_USERSPACE_IMPLEMENTATION=boringtun-cli WG_SUDO=1 wg-quick up ~/wireguard/example.conf"
@autonomic if you set WG_SUDO=1, that will circumvent dropping privileges. Can you try again after removing that env var and see if that works?
Cheers!
@phillyqueso so I ran again without WG_SUDO=1 and boringtun-cli is still not dropping privs to my regular user. Thanks for your help.
@autonomic Sadly, I'm unable to reproduce the issue.
If I drop WG_SUDO, or set it to 0, the root privileges acquired via sudo are successfully dropped.
I'm testing on Mac OSX 11.6.7 using [email protected]. Might you be running a later Mac OSX version? Or an outdated boringtun-cli instance?
@phillyqueso @Noah-Kennedy Looks like there may be some kind of regression in 0.5.2 because after installing it I'm no longer able to start boringtun-cli with:
sudo WG_QUICK_USERSPACE_IMPLEMENTATION=boringtun-cli WG_SUDO=0 wg-quick up ~/wireguard/example-wg.conf
[#] boringtun-cli utun
BoringTun failed to start
[#] rm -f /var/run/wireguard/example-wg.name
I can run with WG_SUDO=1 but it doesn't drop privs.
Hmm, all 0.5.2 did was make it so that we checked the environment var at runtime rather than compile time. Otherwise it should not change the behavior of the fix from @phillyqueso.
Oh, right, under sudo this var wouldn't be passed in.
@autonomic try sudo -E instead of sudo.
@Noah-Kennedy Still getting the same message "BoringTun failed to start" and then the process exits (using sudo -E).
...and I see what's going on. Ok, permissions dropping seems to have some issues here and I need to find a workaround for the problem.
@autonomic The issue here is that we need to know what user to go for to drop permissions. My runtime approach wouldn't work because I was assuming boringtun-cli would be run with sudo -E or something so that we could get the use.
The change @phillyqueso made basically hardcoded the compiling user into the binary to drop perms to them, which isn't correct either, as this won't work for anyone who has packaged versions of boringtun installed.
Unfortunately, I don't know of a good way for the root user to get this information, but I can dig around later. In the meantime, running as root and then trying to drop privileges won't work, unless you, say, run it with the USER=usertodropto environment var set.
@Noah-Kennedy I installed using cargo install boringtun-cli so shouldn't this allow me to run with the same user? This doesn't of course fix the issue for the wider audience when boringtun-cli is packaged but so long as I can run and drop privs to my own macOS user then that will suffice for the time being until a solution is implemented.