3 ms·

They have pledge(2) and unveil(2) instead.

by GeorgeWBasic 7y ago

smitty1e 7y ago
Excellent. Thank you.
- beefhash 7y ago
  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.
  - ori_b 7y ago
    It's worth pointing out that chrome is pledged and unveiled. Even a compromised chrome can only modify the downloads dir.
  - floatboth 7y ago
    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.
  - dralley 7y ago
    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.
  - Someone 7y ago
    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.

They have pledge(2) and unveil(2) instead.

smitty1e 7y ago

Excellent. Thank you.

beefhash 7y ago
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.
- ori_b 7y ago
  It's worth pointing out that chrome is pledged and unveiled. Even a compromised chrome can only modify the downloads dir.
- floatboth 7y ago
  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.
- dralley 7y ago
  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.
- Someone 7y ago
  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.