4 posts were merged into an existing topic: BeOS compatibility and packagefs
I agree that something like pledge would be awesome.
I am not convinced that (only) doing this with runtime calls makes sense though, this leads to applications theoretically beeing able to call exec to then regain permissions (in the new process)
Perhaps this can be improved by having flags in ELF for denying stuff before the application is even started.
2 Likes
Wouldn’t it be good to put in place a system that asks us for authorization for delicate things, something like sudo?
It gets old very quickly. On my MacOS system, I seem to have such a dialog every ten minutes.
1 Like
AppArmor does it with configuration files outside of the application. These things can complete each other, they protect against different things and attack scenarios.
I think that’s the first thing to ask when talking about security: what is the thing you are trying to secure? Websites collecting your personal data? Family members looking at your personal files? Some government agency spying on you? Each of these (and any other scenario) will require different protections
Yes sure, but then pledge (and unveil) are OpenBSD mechanisms, while apparmor is a linux one.
The big difference I think is that in OpenBsD applications are designed to work with both, but AppArmor is done after the fact.
We can probably take inspiration from both.
See also: https://www.engr.mun.ca/~anderson/publications/2017/sandbox-comparison.pdf
The Capsicum compartmentalization framework is different from seccomp-bpf and pledge(2) in two key ways. First, Capsicum employs a principled, coherent model for restrictions on processes when applications are compartmentalized. This is implemented by Capsicum’s capability mode. Second, Capsicum employs fine-grained, monotonic reduction of authority on specific OS objects accessed via
attenuated file descriptors, called capabilities.
It’s a part of FreeBSD by the way: Capsicum - FreeBSD Wiki.
You can just pledge not to exec()… seems pretty trivial solution to that. Also don’t execed process inherit parent’s permissions? It seems like that would be a sane way to do that anyway…
Also the reason it is done that way is because its not something you can just turn off… like SELinux for example, which often gets turned off because “its not working” etc… It designed to “just work”.
The unveil system call would also be handy for security Serenity also implemented that one.
Capsicum seems complicated, much like SELinux… and would end up being something you’d “turn off” to make things work… exactly what OpenBSD was trying to avoid.
Unlike SELinux, it’s the programmer’s duty to make things go smoothly. I believe that with a bit of thought capabilities could be used very effectively.
https://www.reddit.com/r/freebsd/comments/jldsm2/do_freebsds_jails_basically_accomplish_the_same/
See there… basically Capsicum is doing almost the same things as pledge / unveil but being harder to implement and more complicated.
https://www.reddit.com/r/freebsd/comments/jldsm2/do_freebsds_jails_basically_accomplish_the_same/
And it links to http://www.engr.mun.ca/~anderson/publications/2017/sandbox-comparison.pdf, which explains why they are not the same.
For example, Capsicum allows safe exec, unlike pledge.
No they do not, one reason for this is that most programms (atleast in OpenBSD‘s design) habe some sort of „setup“ phase where they need more permissions, which they will drop later.
e.g open config files for reading.
Yes you can pledge not to exec, but not in every app where you need this functionality.
I definetely agree with openbsd‘s stance on security you can‘t „just disable“. If there would be a mechanidm to drop privileges before application start it should be embedded in the ELF ressources, not some config files.
2 Likes