Are lxd unprivileged container affected by CVE-2020-14386?

the Mitigation from the usn:

If unprivileged user namespaces are not needed, set the
kernel.unprivileged_userns_clone sysctl to 0; e.g.

$ sudo sysctl kernel.unprivileged_userns_clone=0

I wonder lxd unprivileged container can safely apply the mitigatin or not ?

unprivileged user namespaces

sounds like you would need these for unpriviledged containers.
But @stgraber will know better.

Anyway the kernel maintainers should fix this rather quick, sadly the solution seems to be deferred (according to some tech media).

Setting that option will prevent unprivileged users access to cloning a user namespace.
This will not prevent LXD from running as it runs as root, but it also won’t prevent someone inside a container from attempting to exploit this flaw.

Updating your kernel is, as usual, the best option there. There may be more ways to prevent this attack if a reboot isn’t an option, but I’d need to know a lot more about the actual bug to see alternative ways to block it (seccomp/apparmor). This may also be something that livepatching could fix (not sure if this was picked up for that or not though).

1 Like

Bug is fixed in upstream kernel releases: 5.8.8 and 5.4.64.
I assume mainline and other longterm versions also contain the fix.

1 Like