Quote:
Originally Posted by jggimi
jjstorm, you mentioned two Linux-specific security governance mechanisms that are unrelated to privilege separation. Unlike privilege separation, those are optional add-on mitigations.
Optional security usually remains optional. Take a look at this 2015 presentation about OpenBSD's new pledge(2) risk mitigation function. A video is available.
An application which has used the pledge() syscall has reduced its own privileges. The Chromium browser has been pledged for 5.9-release, for example. While pledge() is not privilege separation, it does share some of the same intent. Theo de Raadt plans to present on the relationship between pledge() and privilege separation at the dotSecurity conference in April.
As for Firefox, since you mentioned it, it has not been pledged. But it will use W^X (Write XOR Execute) memory allocation at 5.9-release. This is another risk mitigation technique. It doesn't separate privileges into separate processes, and doesn't reduce its own privileges, but it does ensure that memory used for program execution is read-only.
|
Excellent, so with pledge(), the applications, working together with the kernel, restrict themselves. A major advantage over apparmor and SElinux is that it cannot be turned off.