3 ms·
I remember when that article came out. The basic premise is that it defines a secure OS as something that requires an add-on security framework (resulting in ad
by hhw 12y ago
I remember when that article came out. The basic premise is that it defines a secure OS as something that requires an add-on security framework (resulting in additional complexity), and concludes that OpenBSD is not secure because it doesn't meet this definition. It's a pretty disingenuous argument. The author's knowledge and understanding of OpenBSD are also quite obviously shallow, given the examples he uses to make his points.
Yes, the approach of security through simple correctness is indeed difficult, but OpenBSD has been doing a pretty darn good job at it for a very long time. At the very least, its highly successful track record demonstrates how their approach has been more effective than any added security framework approach, in the real world. And other operating systems have come around to adopting OpenBSD's security features and techniques, rather than the other way around.
- ams6110 12y agoAlso these frameworks are frequently disabled. There are MANY widely used software products, for which step 1 in the installation instructions is "disable SELinux." The majority of the security features described in the OP, by contrast, do not need to be disabled to get mainstream software products to work.
- lmz 12y agoI personally find if SELinux "just works" for the purposes then it is great. However if I want to integrate a third party software product into the existing policies I don't know where to start with it. e.g. if I have a daemon xyzd that wants to write to a pid file and to its log file, and have read write access to its own data, how do I write a policy to confine it?
- nullc 12y agoI agree, However: This is also something that OpenBSD is guilty of— defining security as things like strlcpy (which experience has shown causes its own mistakes) or an OS with all services off while eschewing security functions others have deployed (like the SE Linux stuff mentioned there, or the excellent virtualization features in other OSes). > And other operating systems have come around to adopting OpenBSD's security features and techniques, rather than the other way around AFAIR, the PAX/NX stuff was available on Linux back in something like 1999 or 2000, several years prior to OpenBSD— likewise for many of the things in that slide deck. OpenBSD been a leader in some techniques, and a follower of others. I think sometimes the public doesn't get to see a complete picture do to the excessive fandom and politics. Relative to the level of investment in it OpenBSD does very well, but they're not the lone light of security insight some some people try to make them out to be!