You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You'd expect --unshare-pid --proc /proc --clearenv to safely hide all environment variables. However, when not using --as-pid-1, the environment is leaked in /proc/1/environ!
Not sure if this is actually relevant security wise, but I'd better hope nobody is using --clearenv to clear sensitive environment variables!
Not sure if this is actually relevant security wise, but I'd better hope nobody is using --clearenv to clear sensitive environment variables!
I don't think bubblewrap ever intended it to be a security guarantee that --unsetenv or --clearenv would make the environment variables' values not visible to processes inside the container - I'd always seen it as a way to clear environment variables that are functionally inappropriate for the container (for example when a Flatpak app swaps to a different /usr, it needs to clear the LD_LIBRARY_PATH).
As a general design principle, I would recommend reducing the scope of sensitive environment variables to be as narrow as possible, and preferring to reference a file containing secrets (for example this is how $XAUTHORITY and $DOCKER_CONFIG work) rather than directly putting the secret in the environment variable.
I don't think bubblewrap ever intended it to be a security guarantee that --unsetenv or --clearenv would make the environment variables' values not visible to processes inside the container
Perhaps that could be stated in the man page? e.g. "warning: --clearenv is not a security feature. sanitize your own environment beforehand"
Judging by the number of PR references to this issue, it seems people thought --clearenv was a security feature, and the confusion is understandable.
Also, as an aside, /proc/1/cmdline will leak the original bwrap commandline, allowing an attacker to infer details about the host machine and the sandbox itself. Not as scary as the env leak, but it's still probably best to use an --args FD to hide the commandline.
Activity
[-]--clearenv leaks environment[/-][+]`--clearenv` leaks environment[/+]fix: close two sandbox escapes in the bwrap policies
Overwrite removed env strings so they do not leak via /proc/PID/environ
smcv commentedon Sep 18, 2026
I don't think bubblewrap ever intended it to be a security guarantee that
--unsetenvor--clearenvwould make the environment variables' values not visible to processes inside the container - I'd always seen it as a way to clear environment variables that are functionally inappropriate for the container (for example when a Flatpak app swaps to a different/usr, it needs to clear theLD_LIBRARY_PATH).As a general design principle, I would recommend reducing the scope of sensitive environment variables to be as narrow as possible, and preferring to reference a file containing secrets (for example this is how
$XAUTHORITYand$DOCKER_CONFIGwork) rather than directly putting the secret in the environment variable.chjj commentedon Sep 19, 2026
Perhaps that could be stated in the man page? e.g. "warning: --clearenv is not a security feature. sanitize your own environment beforehand"
Judging by the number of PR references to this issue, it seems people thought --clearenv was a security feature, and the confusion is understandable.
swick commentedon Sep 21, 2026
Personally, I would appreciate if --clearenv actually made the environment of the caller inaccessible.
karthik20066002 commentedon Sep 24, 2026
well, there's quite a few PR's already, can I help out if needed?
Overwrite removed env strings so they do not leak via /proc/PID/environ
chjj commentedon Sep 27, 2026
Also, as an aside, /proc/1/cmdline will leak the original bwrap commandline, allowing an attacker to infer details about the host machine and the sandbox itself. Not as scary as the env leak, but it's still probably best to use an
--argsFD to hide the commandline.smcv commentedon Sep 27, 2026
@shleder, please don't use another project's issue tracker as somewhere to advertise your vaguely related project.