ahead of my talk at @defcon on evil #eBPF, i'd like to leave you all with a PoC of a vanilla cap_sys_admin dockerized process (ie w/ vanilla apparmor/seccomp) that stomps pid 1 memory.
this is a generic escape btw. like i said at #35c3, docker's sysfs restrictions are not enoughpic.twitter.com/ZVikbhmyvj
-
Show this thread
-
Replying to @ChaosDatumz @defcon
Just to check, does this only work if you add CAP_SYS_ADMIN , or would it work with Docker's default capability set?
2 replies 0 retweets 4 likes -
Quoting the manual "CAP_SYS_ADMIN is the new root". Seems there might be multiple ways to escape via it. Maybe Docker should have a better security UX and warn about insecure options passed to it?
1 reply 0 retweets 1 like -
docker quite specifically makes it required to do any eBPF stuff (likely as a snub to
@tehjh) when there is no such restriction in the kernel for a number of the eBPF APIs. but the real fault lies in the kernel for placing too much eBPF stuff behind cap_sys_admin in the 1st place1 reply 0 retweets 3 likes -
Replying to @ChaosDatumz @disconnect3d_pl and
but some of the blame is also on docker for trying to use apparmor/seccomp/etc to make sys_admin not root equivalent. it's a losing battle, and their decision to place a strict privilege boundary where none really existed will likely have long-term negative effects for security.
1 reply 0 retweets 2 likes -
Replying to @ChaosDatumz @raesene and
"blame is also on docker for trying to use apparmor/seccomp/etc to make sys_admin not root equivalent" Is it? Imo it's a side effect of allowing to choose caps and having many layers of security (which is good?) I'd rather blame UX not warning ppl about given caps being dangerous
1 reply 0 retweets 1 like -
Replying to @disconnect3d_pl @raesene and
that's the whole point of capabilities, they are powerful/dangerous. silently changing the rules of how they work is bad and essentially necessitates --privileged, b/c few are going to write their own seccomp profile just to use eBPF, and those that do will likely mess it up.
2 replies 0 retweets 2 likes -
Replying to @ChaosDatumz @raesene and
...and still docker enables some of them by default (which is bad). Back to the topic is ebpf (fairly?) safe? If so, then maybe it should be in a different or its own capability? or people shouldn't use it in docker without assuming full privs?
1 reply 0 retweets 3 likes -
Replying to @disconnect3d_pl @raesene and
the former, but that is work no one is doing. the one off trend (cgroup_skb) is to make more program types unpriv'd to create and then requiring cap_net_*/etc to attach them. but more needs to be done.
1 reply 0 retweets 3 likes
there actually is a lot of activity on the bpf list right now, on the topic of how to restrict BPF access properly
-
-
Replying to @tehjh @ChaosDatumz and
see e.g.: https://lore.kernel.org/bpf/20190627201923.2589391-1-songliubraving@fb.com/T/ … https://lore.kernel.org/bpf/cover.1565040372.git.luto@kernel.org/T/ …
1 reply 1 retweet 6 likes -
Replying to @tehjh @disconnect3d_pl and
i'm very suspicious of /dev/bpf, i'd prefer more fundamental hardening of the vm runtime than yet more ways to deny access to running a socket_filter. the stuff from _yesterday_ is interesting, but it doesn't look like much has been done yet, so unclear what it will look like.
0 replies 0 retweets 1 like
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.