5 ms·

A lot of the thinking around pledge (2) is that behavior that an SElinux MAC audit would record, and therefore allow moving forward, should not be allowed. The

A lot of the thinking around pledge (2) is that behavior that an SElinux MAC audit would record, and therefore allow moving forward, should not be allowed. There are important differences. pledge requires you to modify an application. SELinux can sandbox any application, including untrusted applications (see the use of SELinux in Android). Since SELinux is external to the application, a system administrator can specify/refine a policy, while pledge calls are compiled in. As such, a number of attack/bugs found in other operating systems, don't impact OpenBSD because they were forward looking. This vision is not exclusive to OpenBSD. Red Hat Enterprise Linux has included many of the same mitigation techniques for a long time (starting at RHEL 3 in 2003). Moreover, they have shipped SELinux, which is arguably more powerful than pledge since RHEL 4 in 2005. (I don't want to discredit the work of the OpenBSD developers, which is great. I just want to point out that there are Linux distributions with similar features, wider hardware support, and wider vendor support. Many OpenBSD supporters just seem to ignore work by others in order to push their favorite system.)

ghshephard 10y ago
Yes - it's a good point that pledge(2) requires that you modify the application, and, that's too some degree a downside of the model. On the flipside, you can't turn off pledge(2) - which has been the default behavior of every (admittedly junior) sysadmin I know who ran into a problem with SELinux that I've seen. The point I was also trying to make (and I'm not sure if I was successful) was that the use of pledge sometimes results in the application being modified to prevent overly permissive behavior (http://www.tedunangst.com/flak/post/going-full-pledge http://www.tedunangst.com/flak/post/going-full-pledge) - whereas in the SELinux "audit" mode, that permissive behavior would be noted, and permitted. I"m just wondering whether tptacek has rethought his comment from 2010 about OpenBSD " its model depends on shipping bug-free distributions " given a lot of success OpenBSD has had in the past several years dodging exploits that resulted from bug-present distribution issues, that its OS compartmentalization approach has successfully avoided.

ghshephard 10y ago

Yes - it's a good point that pledge(2) requires that you modify the application, and, that's too some degree a downside of the model. On the flipside, you can't turn off pledge(2) - which has been the default behavior of every (admittedly junior) sysadmin I know who ran into a problem with SELinux that I've seen. The point I was also trying to make (and I'm not sure if I was successful) was that the use of pledge sometimes results in the application being modified to prevent overly permissive behavior (http://www.tedunangst.com/flak/post/going-full-pledge http://www.tedunangst.com/flak/post/going-full-pledge) - whereas in the SELinux "audit" mode, that permissive behavior would be noted, and permitted. I"m just wondering whether tptacek has rethought his comment from 2010 about OpenBSD " its model depends on shipping bug-free distributions " given a lot of success OpenBSD has had in the past several years dodging exploits that resulted from bug-present distribution issues, that its OS compartmentalization approach has successfully avoided.