LGTM

https://twitter.com/ewindisch/status/926443182010916865

Is there a CVE, so that this gets properly handled upstream and downstream?

I'm not sure if a CVE was opened for the kernel

CVE-2017-16539

Thanks!

I wonder if it's correct that he CVE is reported against Moby, as it's a kernel vulnerability; the patch here is just to work around that; http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16539

Yeah, probably the kernel gets the real blame, but I don't think there's a clear understanding yet of which piece of code would need to be fixed.

Kernel patch was created by @cyphar here; https://marc.info/?l=linux-scsi&m=150982199728895&w=2

@thaJeztah I think that Docker is the right component to be filed against (though it should be noted that the default AppArmor and SELinux setup actually protects against this attack -- so you'd have to misconfigure your system in order to make it exploitable) since we don't use user namespaces by default and we run images as root by default (with CAP_DAC_OVERRIDE enabled). If any of those things weren't true this attack couldn't work even with a misconfigured system.

Based on this conversation

https://twitter.com/ewindisch/status/926888008015638530

there's a variant on this attack (known as #GroceryShoppingWithMyKids - and every bug gets an animated GIF) where the attacker writes into /proc/scsi/device_info and can also "write into this arbitrary data append only and DOS kernel via memory allocations".

I've send in a note to update the CVE to reference the patch from @cyphar which I believe addresses this variant as well.

@vielmetti That is also protected against by the default AppArmor and SELinux profiles (so the same "misconfigured" and "our defaults really should be better if it weren't for legacy reasons" caveats as above). And yes, my patch fixes that issue from the kernel-side as well.

@justincormack would it be realistic to write a test of this ?

how's this tested?

Well, you could start a container and check whether /proc/scsi is a tmpfs mount (or check that it's empty). Not sure it's worth it though -- we have tests in runc that make sure masked paths work properly and this just uses maskedPaths in the OCI configuration, so Docker isn't actually doing anything here.