Here's a write-up showing how AppArmor can protect Docker containers and the underlying host... quote from the article, "So without even patching the container we have prevented rouge pid from spawning using a correct security profile with AppArmor."
I really wish SELinux would evolve some better configuration tools/culture, but after a decade and a half I despair of this ever happening. Every single Fedora release I leave it enabled on my personal machine thinking "THIS will be the moment where I really puzzle it out". Then I disable it a week later when I realize how much annoying work configuring rules for my rando backup and device management scripting will be, and when I see that it still lacks rules for a bunch of in-distro tools I need to use.
1. gain access to the system (unrelated exploit) 2. elevate to root with profile which can create hardlinks at all 3. have access to a directory unrestricted in the profile 4. have local, unrestricted application which can be exploited by hardlink manipulation
This is theoretically possible on some systems. But it's a massive effort and fairly easily mitigated by having a profile for all running services which disallows hardlinks in the first place. As far as risk of service exploitation goes, this should be a fairly minimal one. (and requires targeted approach)
Based on seeing email chatter about this report in the context of Cloud Foundry. Under the hood CF uses runC, partly to allow AppArmor to be applied.
Disclosure: I work for Pivotal, the majority contributor of engineering to Cloud Foundry.
Disclosure: I worked on testing the fixes for this CVE.
It was our understanding from the original report that the vulnerability was mitigated by AppArmor disabling ptrace, by no user process running as pid 1 inside the container, and because in CF buildpack apps, user processes run as unprivileged users. This is the stance communicated in the CVE report.
However, with some further consideration and updated information yesterday, we decided it would be prudent to patch and release immediately to be on the safe side. This was communicated to the Cloud Foundry Security team.
I'd have to think about this further, but I'm not convinced that would be sufficient protection (accessing /proc/$pid/fd has a different set of access requirements to ptrace -- it's a dumpability check basically). However, since you've already sent patches around it's all good.
Disclosure: I discovered, wrote patches for and helped with coordination of this vuln.
If we're wrong, we'll change it.
Edit: looks like we already did.