5 ms·

What you've answered is a great (if not the best) way to defend against attackers, but not what was asked,They asked how to detect. I'll strongly disagree on s

What you've answered is a great (if not the best) way to defend against attackers, but not what was asked,They asked how to detect. I'll strongly disagree on selinux, I have seen it work in practice to defeat attackers many times, that provide features that seccomp and cgroups etc do not.

amluto 2y ago
re: SELinux, I think it depends on your use case. If your system is a flight information display, then you may well have two userspace processes that do anything of significance: the display manager and the actual app. There is no persistent state. At this point, SELinux is purely overhead and extra attack surface — what would it even protect. If your payload is a container (database server, microservice, whatever), and you’re doing some form of best-practice volume management, then only the database’s own data is mounted for it. SELinux is a real PITA to get working in a context like this, and it’s not really clear what it would add. (Okay, maybe you get fancy and use it to restrict what can talk to the microservice. Or maybe you use network namespaces.) If you’re running a desktop or a more conventional server setup, then, sure, MAC policy has its place.
- ungamedplayer 2y ago
  Absolutely depends on the use case. I'm attempting to talk in the generic case. If you limit policy to the minimum attack surface from outside the process including permissions and capabilities which are significantly more fine grained in selinux compared to normal Unix permissions, you reduce the the capability of the attacker once they gain access to the system. Imagine if they got access to local code execution... Binding to sctp protocol would instantiate the whole protocol in kernel. Effectively opening up whole new attack vectors. I can't see any other techniques (other than selinux like AC) that enables this kind of attack space reduction as easily. I am aware that you can blacklist modules,etc but this is just one of many examples.
  - ongy 2y ago
    You can use SEccomp for some of it as well. But for SEccomp something in the hierarchy needs to do this actively While SELinux can be set up somewhat orthogonal to the running system. OTOH systemd should make it easy to confirm every service process
  - amluto 2y ago
    For this sort of kernel attack surface reduction, I would use a combination of seccomp and runtime module loading restriction. In the specific example of sctp, one can turn off loading of modules at runtime entirely.

amluto 2y ago

re: SELinux, I think it depends on your use case. If your system is a flight information display, then you may well have two userspace processes that do anything of significance: the display manager and the actual app. There is no persistent state. At this point, SELinux is purely overhead and extra attack surface — what would it even protect. If your payload is a container (database server, microservice, whatever), and you’re doing some form of best-practice volume management, then only the database’s own data is mounted for it. SELinux is a real PITA to get working in a context like this, and it’s not really clear what it would add. (Okay, maybe you get fancy and use it to restrict what can talk to the microservice. Or maybe you use network namespaces.) If you’re running a desktop or a more conventional server setup, then, sure, MAC policy has its place.

ungamedplayer 2y ago
Absolutely depends on the use case. I'm attempting to talk in the generic case. If you limit policy to the minimum attack surface from outside the process including permissions and capabilities which are significantly more fine grained in selinux compared to normal Unix permissions, you reduce the the capability of the attacker once they gain access to the system. Imagine if they got access to local code execution... Binding to sctp protocol would instantiate the whole protocol in kernel. Effectively opening up whole new attack vectors. I can't see any other techniques (other than selinux like AC) that enables this kind of attack space reduction as easily. I am aware that you can blacklist modules,etc but this is just one of many examples.
- ongy 2y ago
  You can use SEccomp for some of it as well. But for SEccomp something in the hierarchy needs to do this actively While SELinux can be set up somewhat orthogonal to the running system. OTOH systemd should make it easy to confirm every service process
- amluto 2y ago
  For this sort of kernel attack surface reduction, I would use a combination of seccomp and runtime module loading restriction. In the specific example of sctp, one can turn off loading of modules at runtime entirely.