Hacker News new | past | comments | ask | show | jobs | submit login

Yes, you are right. However, when I calculating risks and protection/price ratio, I see no difference. System with `setenforce 0` is equal to system with the rule for first two significant digit, because root password is most significant and risk of attack through webui is same and high too. Other risks are less significant than that and SELinux does not reduce them significantly.

It sounds like you're saying the security position can be simplified to one dimension. It can't. Unless you're able to provide risk and exposure for all users and somehow make them the same for everyone (they're not).

Then you write that SELinux doesn't reduce the risk. It definitely does that for webapps executing wrong commands, utility services being exploited for local access, many attempts at race conditions via shared directories, etc. For example almost all interesting use cases for imagetragick exploits are severely limited by properly configured selinux. Once in a while there's going to be an issue with a trivial exploit which everybody and their dog will use to scan the whole internet before you have time to patch. This is what LSM is great to protect against.

I'm not saying that risk is not reduced. I'm saying SELinux is not effective, so it's better to spent my time/money on something that can reduce risk significantly.

I saw no 0-day exploits to date which are stopped by SELinux. For example, a trojan can use apache process as malware host, without reading/writing to disk at all. SELinux will not stop that even in theory.

It will not. But looking at what exploits normally do - that would be uncommon and targeted. A lot of common stuff will only drop a stage 2 downloader and try to execute it. Doesn't work - move to the next target.

For most of automated exploitation, selinux is perfectly capable of intervening.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact