Linux containers vs. VMs: A security comparison (InfoWorld)

It's true that grsecurity doesn't support mount namespaces in RBAC, like several other access control systems. The difficulty being that RBAC is designed to be used system-wide and doesn't yet permit individual per-namespace policies. Mount namespaces allow for filesystems to exist which cannot be seen via the global namespace, so there's no way I can see yet for us to construct a path to represent those unreachable names when logging to dmesg, and it's not possible to have one gradm see all the files involved at load time. I also don't like the user experience of requiring individual gradm usage in each container, particularly when that's generally automated.

It's not true however that grsecurity has no namespace support. There's special handling in some of the chroot features for pid /mount namespaces, all of the code is user-namespace aware, and the net/cgroup namespaces are pretty orthogonal to anything in grsec. Several non-configurable changes also provide additional security for containers, requiring CAP_SYS_ADMIN for /proc/sys writes, for instance.

I know of many people using Docker with grsecurity -- from a read of a recent github issue about it, it seems they've also resolved an incompatibility that required disabling two chroot protections at runtime. If anyone has any compatibility issues with containers, they're of course welcome to report that on our forums (or point us to relevant Docker github issues) where we can help explain things and come up with more secure alternatives.

Finally, the reason it should have been mentioned (generally this would have happened in the paragraph starting with "Finally, the process to kernel interface (for system calls) is large and exposed in every container", or even seccomp at least) is why anyone using containers or shared hosting uses grsecurity: to protect the kernel from users and strengthen the separation between one potentially compromised user and other customers. Obviously it's no guarantee, there are still logic bugs and other one-off failures, but what is a guarantee is that any public memory corruption exploit that has a chance of working against grsecurity or demonstrates new exploit techniques will have its techniques and bug classes killed off in a short period of time. Anyone's welcome to look into our history to see many examples of this (shadow vsyscall hardening, KSTACKOVERFLOW, RANDKSTACK, STACKLEAK, USERCOPY, some very recent USERCOPY enhancements, STRUCTLEAK, removal of thread_info from the stack, MODHARDEN, etc etc).

-Brad