[tptacek]

OpenBSD by itself contains a feature set similar in comparison to the GRSecurity patch for Linux without the ACL or RBAC implementation. GRSecurity and the Openwall project actually pioneered many of the protections that occurred later in OpenBSD such as Executable Space Protection, chroot restrictions, PID randomization and attempts to prevent race conditions

On the one hand: I think OpenBSD did pioneer some of these things (PID randomization --- randomization of all monotonically increasing IDs, really --- was something TdR was doing in the 1990s). Privsep daemons might be another example.

On the other hand, I'm not sure I buy that OpenBSD has a feature set comparable to GRsecurity without the ACL/RBAC stuff.

[milcron]

Just to try and explain where I feel the OpenBSD project is coming from... their philosophy is a little different.

At the very beginning OpenBSD was not about security per se, but about simplicity of implementation and stark, clean code. It turns out this results in a rather secure system (go figure).

It was only after the fork from NetBSD that OpenBSD gained a real security orientation... I think there was some client who wanted a secure OS, and they helped fund the audit of OpenBSD's codebase. Yet even today OpenBSD's philosophy is better explained as a focus on stark simplicity.

Coming from that perspective, many of their decisions make sense. ACLs are a terribly complex mechanism that would require a lot of new code added to the kernel. Any new code is a deadweight that needs to be tested, audited, maintained, etc. across a large number of platforms, not just x86 and ARM.

OpenBSD (historically) has no hypervisor for the same reason. It's an incredibly complicated feature that would be difficult to implement securely and succinctly. As Theo put it (in characteristically brusque style):

>x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.

>You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

That said, OpenBSD has pioneered a lot of security features. They created sudo in 1997, recently replaced sudo with a simpler program `doas`. OpenBSD was the first mainstream OS to have ASLR turned on by default. And their new privilege-drop feature `pledge` looks great.

In the end, they're a smaller project with less manpower so it's impressive they achieve what they do. Obviously auditing the entire ports tree is going to be out of scope... auditing Firefox alone would probably be a multi-million dollar project.

[tptacek]

Yeah, I was there at the beginning of the OpenBSD audit (there, as in, in Canada, at times in Theo's basement), and for a few years was the person writing the advisories (I'm particularly proud of rfork and the I/O signal advisory).

I don't dispute that OpenBSD is good at the small-bore Unix stuff. They are! I think OpenBSD is the undisputed master of small-bore Unix security. If you want something in userland priv-separated or some ID randomized, call the OpenBSD team.

The problem though is exactly what this article says it is: the code OpenBSD has custody over is a small fraction of the code users need to run, and OpenBSD's code just isn't up to the challenge of securing other people's code. Modern Linux security has taken the other road: part of the kernel's job is --- at least in GRsecurity-world --- to assume that you're running insecure C code, and still not lose your kernel to an attacker's persistence tools.

[milcron]

Did not mean to preach to the choir, hah!

I would argue that pledge goes a long way towards addressing the problems of insecure C code, although it's definitely not as fine-grained as ACLs.

[bandrami]

ACLs are a terribly complex mechanism that would require a lot of new code added to the kernel

ACLs also make me as an administrator have to think much harder about, well, everything. Same problem with capabilities: each new layer increases the complexity of the reasoning required combinatorially ("so, the daemon isn't running as root, but it's in the daemon group, and the file has these capabilities, and those ACLs...")

[jlgaddis]

You do know that OpenBSD just recently introduced a hypervisor, right?

(From the "(historically)", I'm guessing you do but others reading this may not realize that OpenBSD now does ship with a hypervisor. It's very "early", though, FWIW.)

[milcron]

Correct. Currently it can only run OpenBSD guests, and it only supports x86.

The landscape is a little different now that hypervisors are no longer cutting edge, and the x86 architecture has improved virtualization abilities which help prevent some security flaws.

[dom0]

Wasn't TdR statement before hardware virtualization on x86 became commonplace? Before AMD-V / Intel VT x86 virtualization worked through bizarrely complex techniques (binary translation...)

[milcron]

He said that in ~2007? So that may be correct. x86 hardware virtualization has gone through several generations so his comments may have remained accurate even as hardware features were added.

Hardware-assisted virtualization really took off in ~2008, but they've continued to add features over the past decade.

https://en.wikipedia.org/wiki/X86_virtualization

[waspleg]

I was very fond of OpenBSD 20 years ago when I ran it (still have the t-shirt). It had a simple elegance that struck a chord with me. I haven't looked at it in a long time, the last time I looked it didn't support VMs at all and didn't plan to which was a deal breaker ;/

I've never heard of pledge so went looking to find out what it is and found Theo's presentation: https://www.openbsd.org/papers/hackfest2015-pledge/mgp00001....

[JoachimSchipper]

GrSecurity has more kernel-level protection features, I think. If I wanted to argue that OpenBSD is more secure than e.g. Ubuntu with GrSecurity, I'd focus on OpenBSD's hardening/security-conscious design throughout the system. (ETA:) GrSecurity gives you great anti-exploit technology, but having fewer total bugs also helps.

(E.g. OpenBSD has beautiful code, most of the base system pledge'd, ASLR/stack overflow protection/W^X/prices/auditing everywhere, doesn't stuff tons of complexity into everything, ...)