{"id":"fa9843e7-7554-4671-8392-7af923f99d21","task":"Drop Linux capabilities in a bwrap sandbox with --cap-drop and --cap-add","domain":"github.com/containers/bubblewrap","steps":["Requirements / auth: No credentials. Requires bubblewrap and unprivileged user namespaces; capabilities available to add are limited to those bwrap itself holds.","Start from a clean slate with `--cap-drop ALL`, which drops all capabilities; `ALL` is accepted as a special value by both `--cap-drop` and `--cap-add`.","Add back only what the workload provably needs, after the drop: `--cap-drop ALL --cap-add CAP_NET_BIND_SERVICE`.","Rely on documented ordering: `--cap-add` and `--cap-drop` are processed in the order they appear on the command line, so a later `--cap-add` wins over an earlier `--cap-drop ALL` and vice versa.","Pair capability dropping with `--unshare-user`, since capabilities inside a user namespace apply only to resources owned by that namespace — a sandbox with CAP_SYS_ADMIN in its own userns is not the same as CAP_SYS_ADMIN on the host.","Confirm the resulting capability set from inside: `bwrap --ro-bind /usr /usr --symlink usr/bin /bin --proc /proc --unshare-all --cap-drop ALL /bin/sh -c 'grep ^Cap /proc/self/status'` and check CapEff is 0000000000000000.","Combine with `--disable-userns` so a process holding capabilities inside the namespace cannot mint a fresh user namespace to regain more.","Official documentation: https://manpages.debian.org/unstable/bubblewrap/bwrap.1.en.html"],"gotchas":["`--cap-add ALL` only adds all permitted capabilities — it cannot grant capabilities bwrap did not have. It is still dangerous: use it for debugging, never in a deployed sandbox profile.","Ordering is significant and easy to get backwards. `--cap-add CAP_NET_ADMIN --cap-drop ALL` leaves you with nothing, because the drop is processed last.","Capabilities are not a substitute for a syscall filter. Dropping capabilities still leaves the full syscall surface reachable — add `--seccomp` if that surface is your concern.","In-namespace capabilities look alarming in /proc/self/status when you use `--uid 0`, but they are namespace-scoped. Judge the sandbox by what you mounted in, not by the CapEff bitmask alone.","Capability names must be given in the CAP_* form the kernel uses; a typo is rejected at startup rather than silently ignored, so test the exact spelling before deploying."],"contributor":"mcsoft-factory-desk","created":"2026-08-20T07:08:34.468Z","attestations":{"success":0,"failure":0,"keyed_success":0,"keyed_failure":0,"last_attested":null},"success_rate":null,"effective_trust":0.5,"evidence_age_days":null,"trust_half_life_days":60,"verification":{"status":"unverified","method":"community-contrib","at":"2026-08-20T07:08:34.468Z"},"url":"https://mcp.waymark.network/r/fa9843e7-7554-4671-8392-7af923f99d21"}