[hhw]

There are two different schools of thought to a secure operating system. One is to add features / layers to enhance security, such as with GRSecurity. The other is to ensure correctness, so that there are no bugs to exploit. OpenBSD takes the latter approach, as they're of the opinion that additional features and layers result in more complexity with increased probability of bugs and/or misuse. Also, it's a misconception that OpenBSD's primary focus is security; the primary focus is in fact on correctness, with security being an important but auxiliary benefit of that.

The article posted makes the argument that the first approach is the only true approach to a secure operating system, and that OpenBSD is thus insecure by definition. There's not enough data / samples of secure operating systems to make an intellectually honest assertion that one approach is definitively superior, but OpenBSD likely has the best security track record for an operating system in real-world scenarios.

point of reference: years of following the OpenBSD mailing lists

[microtonal]

There's not enough data / samples of secure operating systems to make an intellectually honest assertion that one approach is definitively superior, but OpenBSD likely has the best security track record for an operating system in real-world scenarios.

While auditing is definitely a good idea, the latter approach only works when you only run services and applications that are part of OpenBSD. Since that is not the case for most realistic usage scenarios, OpenBSD gives you very little, while the former approach (think e.g. SELinux) can help you with isolating applications that you trust, but not as much as, say OpenBSD.

[upofadown]

The comment you are replying to does not mention auditing.

[ljw_dev]

It's implied. The comment mentions code correctness and, per the article, this comes from "the extensive code auditing performed on the base system".

[nickpsecurity]

This two schools of security isn't accurate. The original approach to security, devised by the inventors of INFOSEC, was doing all of these things:

http://pastebin.com/xZ6m4T8Z

Most vendors and FOSS ignored them despite those methods getting consistently-great results but preferred method not doing so. They then pick and choose among lowest-level techniques for verification. They also slowly relearned independently some of the vast body of security engineering knowledge they're ignoring to this day.

In this case, one camp is about trying to make code in an insecure language perfect with probabilistic mitigations to stop problems. Another barely cares about code security but uses strong measures for containment to hopefully limit damage. Author of OP supports doing both as far as I can tell. High-assurance supports doing what was proven, mathematically and empirically, to get the job done going back to the 1960's-80's extended with what we've learned today. Commercial, CompSci, and a few FOSS projects attempt various levels of adoption of such techniques with safety-critical proprietary (eg aerospace, trains) doing it the most.

"There's not enough data / samples of secure operating systems to make an intellectually honest assertion that one approach is definitively superior"

There really is. Certain methods I outlined consistently worked better. Others didn't. OpenBSD avoids most of what worked outside code review, hardening, and pledge then continues to use language and architecture proven to cause problems vs alternatives for UNIX compatibility. One can definitely make predictions from that about kinds of issues they'll face or upper limits of assurance that can be provided.

[hannob]

> One is to add features / layers to enhance security, such as with GRSecurity. The other is to ensure correctness, so that there are no bugs to exploit.

There is no principle reason why these two philosophies - fixing bugs and explit mitigations - collide. You can strive for both - and I'd argue that that's probably what most infosec people would support. OpenBSD also does quite a bit of exploit mitigation, so they're not clearly on a "bug fixing" philosophy either.

I know Spender has a pretty extreme position in saying that fixing bugs is almost irrelevant. But I'd say he's an extreme voice in that debate.

[vbezhenar]

pledge, W^X are examples of the former approach.