4 ms·

I read through your 2010 post three or four times - but it doesn't really seem to be as relevant to 2016 OpenBSD. 2016 OpenBSD assumes that there will be error

I read through your 2010 post three or four times - but it doesn't really seem to be as relevant to 2016 OpenBSD. 2016 OpenBSD assumes that there will be errors in the code, and furthermore, there will be errors that have downstream security effects that the authors can't envision today. 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 entire operating systems seems to be designed in the belief that there is no way to write bug-free applications, so at every level, the operating system, and kernel, should be designed with the expectation that an attacker has broken applications in a manner not envisioned by the application writers of the time. As such, a number of attack/bugs found in other operating systems, don't impact OpenBSD because they were forward looking. I'm wondering if you've had a chance to review the change in thinking that the OpenBSD organization has had in the last 6 years, and how it might impact your original 2010 post?

danieldk 10y ago
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.
tptacek 10y ago
Like I said, I'd be willing to stipulate to an argument that the OpenBSD and MAC approaches were merging. The stuff going on with pledge is a step forward! I like 2016 OpenBSD more than I did 2010 OpenBSD. (I was, as you probably know, involved in OpenBSD in the 1990s, and then, because I worked for a company staffed by Monkey.org people, shipped a demanding product on it --- both experiences left a bad taste in my mouth).

danieldk 10y ago

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.

tptacek 10y ago

Like I said, I'd be willing to stipulate to an argument that the OpenBSD and MAC approaches were merging. The stuff going on with pledge is a step forward! I like 2016 OpenBSD more than I did 2010 OpenBSD. (I was, as you probably know, involved in OpenBSD in the 1990s, and then, because I worked for a company staffed by Monkey.org people, shipped a demanding product on it --- both experiences left a bad taste in my mouth).