4 ms·
That's pretty sweet, if I had to manage my own VMs I'd definitely look into SELinux for that feature. I can see an argument for a defense in depth approach her
by rightos 9y ago
That's pretty sweet, if I had to manage my own VMs I'd definitely look into SELinux for that feature.
I can see an argument for a defense in depth approach here, but if there's only one service per VM and that service is already restricted to only the stuff it needs to talk to on the network level I'm not convinced it makes much sense. As far as I know at least, SELinux won't be able to prevent kernel exploitation or the like.
- ungamed 9y agoIt absolutely prevents kernel exploitation by stopping certain syscalls. I guess you can argue that it doesn't stop "The exploit" in syscalls it allows but it does prevent syscalls from being run.
- rightos 9y agoI'm referring to remote kernel exploits - things that would introduce a new attack vector. Say a bug in a say a network driver or protocol that would already be at ring0 - SELinux does not prevent such an attack. Something that would allow a new way in to a host other than the service in question. If you have ring0 you can just disable SELinux. If you already broke into the service and can make syscalls, well, there's really not much gain from that under my architecture at least - you can still only access what's already in that one service.