Hacker News Reader

Comment by beefhash | Hacker News Reader

I feel like I should add a bit that pledge(2) and unveil(2) take the "opposite" approach of SELinux. Instead of caging an application in hopes that the cage is correctly set up, the responsibility for pledge(2) and unveil(2) is intended to be with the application developer, who minimizes system calls as much as possible and only keeps paths unveiled that they actually require. As far as I know, the idea here is that the developer knows best.

People seem to have been experimenting with applying these restrictions from the outside, but it's generally hard to guess how a large program from ports will behave.

View on HN

SELinux wasn't even invented for app sandboxing, even though e.g. Android uses it for that. There are LSMs designed for app sandboxing, like Canonical's AppArmor. SELinux (and MAC in general) comes from the NSA world of big government servers with complex policies about which actual human users can access which documents and so on.

Those BSD tools do not protect the system’s users against their tools, they protect the tool’s programmers against themselves (which, in turn, will make users trust those tools better)

They also do so at runtime, which means they can restrict themselves much more than a generic configuration can.

Once you’ve stated, for example, “this execution of this tool will only read standard input and write file F”, nothing you do, whether it is sloppy programming or the use of third party libraries with bugs, can change that.

It's worth pointing out that chrome is pledged and unveiled. Even a compromised chrome can only modify the downloads dir.

Ideally, that's how SELinux would work as well. The application developer can be the one writing the SELinux config... it's just that in practice, few of them do, so it's up to the community to do instead.

The rub being that SELinux is mandatory, so if you don't provide some kind of profile, it simply won't run.

Reply on news.ycombinator.com