Hacker News Reader

Comment by benmmurphy | Hacker News Reader

'However, if the attacker is able to take advantage of a kernel bug, they may be able to escape from the container environment. ... every container runs in a different context and SELinux will forbid cross-context access, preventing any further damage from occurring.'

In this scenario SELinux will only protect you from very specific kernel bugs.

SELinux will not protect you against any kernel bug that either gives you a memory write primitive or gives you control over RIP. (Since you can just trash all the SELinux protections). It is only going to protect you from logic bugs where the kernel accidentally gives you filesystem access you weren't meant to have or something similar. Bare in mind that some of the recent kernel bugs relating to namespaces have been logic bugs.

View on HN

Have you got any numbers? It would be interesting to find out what percentage of VM escape bugs have been protected by SELinux.

It could be zero. I'm really not sure. Someone has to go through the vulns and check if they are protected or not. It probably doesn't harm security and may stop some future bug but if you have limited resources to apply to security it might be worth installing grsecurity instead of this. (https://grsecurity.net/) They are often boasting about how grsecurity would have stopped a vuln. So they seem to have a track record of useful mitigations.

Selinux should block the VENOM vulnerability in Qemu: http://danwalsh.livejournal.com/71489.html See also http://www.selinuxproject.org/page/SVirt Keep in mind that Grsec (which is definitely underdeployed in the linux community) is compatible with LSM such as SElinx and AppArmor, so you do not have to choose (you'll take a performance hit, though).

Do you know why people prefer to use labels in SELinux to isolate different Qemu instances rather than use different UIDs? Is it just a matter of convenience?

It's easy to grant a process the privilege to transition to isolated SELiniux contexts, but it's difficult to grant a process the privilege to transition to a limited range of UIDs. Doing it with SELinux also makes it easier to provide additional restrictions - there's a lot of files and device nodes that have to be a+r for normal processes, but which don't need to be available to code running in containers. Using SELinux allows you to prevent the container processes from having access to anything other than the files inside their namespace without needing to entirely refactor the permissions in the host.

Reply on news.ycombinator.com