Why is setuid dropped on execve in an alpine container? - docker

Question

In an alpine container only: When running a setuid binary which starts an other executable (execve(2)), the kernel[1] BusyBox seems to drop privileges acquired by setuid. I think this might be by design because of security implications.
Question: I would like to understand why this is happening and what is responsible for this?
I am working on a one-shot setuid runner called kamikaze written in rust. kamikaze is a very simple binary that unlink(2) itself and then starts a new process using fork(2) and execve(2).
The main components are:
src/main.rs [a47dedc]: Implements the unlink(2) and process spawning.
use std::env;
use std::fs;
use std::process::{Command, exit};
fn usage() {
println!("usage: kamikaze <command> <arguments>");
exit(1);
}
fn main() {
// Kill myself
fs::remove_file(
env::current_exe().expect("failed to get path to executable")
).expect("kamikaze failed");
let mut args: Vec<String> = env::args().collect();
match args.len() {
0 => usage(),
1 => usage(),
_ => {
args.remove(0);
let mut child = Command::new(args.remove(0))
.args(&args)
.spawn()
.expect("failed to execute process");
exit(
child
.wait()
.expect("wait failed")
.code().unwrap()
);
},
}
}
install.sh [a47dedc]: A simple installer which downloads kamikaze, changes ownership to root and sets the setuid bit.
#!/usr/bin/env sh
set -euo pipefail
REPO="Enteee/kamikaze"
INSTALL="install -m 755 -o root kamikaze-download kamikaze && chmod u+s kamikaze"
curl -s "https://api.github.com/repos/${REPO}/releases/latest" \
| grep "browser_download_url" \
| cut -d '"' -f 4 \
| xargs -n1 curl -s -L --output kamikaze-download
trap 'rm kamikaze-download' EXIT
if [[ $(id -u) -ne 0 ]]; then
sudo sh -c "${INSTALL}"
else
eval "${INSTALL}"
fi
When I run kamikaze outside a container[2]:
$ curl https://raw.githubusercontent.com/Enteee/kamikaze/master/install.sh | sh
$ ./kamikaze ps -f
UID PID PPID C STIME TTY TIME CMD
root 3223 9587 0 08:17 pts/0 00:00:00 ./kamikaze ps -f
root 3224 3223 0 08:17 pts/0 00:00:00 ps -f
I get the expected behavior. The child process (PID=3224) runs as root. On the other hand, inside a container[2]:
$ docker build -t kamikaze - <<EOF
FROM alpine
RUN set -exuo pipefail \
&& apk add curl \
&& curl https://raw.githubusercontent.com/Enteee/kamikaze/master/install.sh | sh
USER nobody
CMD ["/kamikaze", "ps"]
EOF
$ docker run kamikaze
PID USER TIME COMMAND
1 root 0:00 /kamikaze ps
6 nobody 0:00 ps
ps runs as nobody.
[1] I first thought that this was because of some security mechanism implemented by docker and the Linux kernel. But after a deep dive into Docker Security, NO_NEW_PRIVILEGES and seccomp(2) I finally realized that BusyBox is simply dropping privileges.
[2] kamikaze [1.0.0] fixed and changed this behavior. Therefore this example does no longer work. For reproducing the example use the kamikaze [0.0.0] release.

Answer 1

BusyBox, which implements the ps command in alpine, drops privileges acquired by setuid by setting the effective user id to the real user id.
libbb/appletlib.c [b097a84]:
} else if (APPLET_SUID(applet_no) == BB_SUID_DROP) {
/*
* Drop all privileges.
*
* Don't check for errors: in normal use, they are impossible,
* and in special cases, exiting is harmful. Example:
* 'unshare --user' when user's shell is also from busybox.
*
* 'unshare --user' creates a new user namespace without any
* uid mappings. Thus, busybox binary is setuid nobody:nogroup
* within the namespace, as that is the only user. However,
* since no uids are mapped, calls to setgid/setuid
* fail (even though they would do nothing).
*/
setgid(rgid);
setuid(ruid);
}
procps/ps.c [b097a84]: Defines BB_SUID_DROP.
// APPLET_NOEXEC:name main location suid_type help
//applet:IF_PS( APPLET_NOEXEC(ps, ps, BB_DIR_BIN, BB_SUID_DROP, ps))
//applet:IF_MINIPS(APPLET_NOEXEC(minips, ps, BB_DIR_BIN, BB_SUID_DROP, ps))
The fix for this was simple. kamikaze just has to set the real user id to the effective user id before execve(2).
src/main.rs [f4c5501]:
extern crate exec;
extern crate users;
use std::env;
use std::fs;
use std::process::exit;
use users::{get_effective_uid, get_effective_gid};
use users::switch::{set_current_uid, set_current_gid};
fn usage() {
println!("usage: kamikaze <command> <arguments>");
}
fn main() {
// Kill myself
fs::remove_file(
env::current_exe().expect("failed to get path to executable")
).expect("kamikaze failed");
set_current_uid(
get_effective_uid()
).expect("failed setting current uid");
set_current_gid(
get_effective_gid()
).expect("failed setting current gid");
let mut args: Vec<String> = env::args().collect();
match args.len() {
0 => usage(),
1 => usage(),
_ => {
args.remove(0);
let err = exec::Command::new(args.remove(0))
.args(&args)
.exec();
println!("Error: {}", err);
},
}
// Should never get here
exit(1);
}
with the newly released kamikaze [1.0.0] we now get:
$ docker build -t kamikaze - <<EOF
FROM alpine
RUN set -exuo pipefail \
&& apk add curl \
&& curl https://raw.githubusercontent.com/Enteee/kamikaze/master/install.sh | sh
USER nobody
CMD ["/kamikaze", "ps"]
EOF
$ docker run kamikaze
PID USER TIME COMMAND
1 root 0:00 ps