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

It doesn't help that cloud providers, e.g. DigitalOcean disable Selinux

When I asked them about this and why they do not even tell the customer about this, they said it is so that they can reset the password when requested through the control panel.

If their "reset password" implementation took care to not mess up the MAC labels on edited files, disabling SELinux wouldn't be necessary.

See virt-rescue(1) (and libguestfs-tools in general) for how to do it properly.

Couldn't they do a "touch /.autorelabel" and reboot the system?

I think that is a reasonable sacrifice considering you lost access to your system.

Seems like they could write an SELinux rule to allow that behavior...

Yeah, but it's basically same as `setenforce 0`.

You need to be in the context that will allow the change of password. For example, if this is an agent, you need to be able to execute code in the agent. If this is from a DHCP hook in early boot, you need to execute in that hook.

That's totally not equivalent to the use of "setenforce 0".

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