The Insecurity of OpenBSD (2010)
allthatiswrong.wordpress.com
The Insecurity of OpenBSD (2010)
1–10 of 88 posts
Re: The Insecurity of OpenBSD (2010)
#2OpenBSD 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.
Re: The Insecurity of OpenBSD (2010)
#3OpenBSD 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 thes…
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, ...)
Re: The Insecurity of OpenBSD (2010)
#4There 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
Re: The Insecurity of OpenBSD (2010)
#5Aren't all of these solved by pledge ?
Also his counter-argument on secure-levels is not convincing.
"Securelevels are an interesting concepts and they do help with security somewhat. Securelevels can only be increased not decreased on a running system. The higher levels prevent writing to /dev/mem and /dev/kmem, removing file immutable flags, loading kernel modules and changing pf rules. These all help to restrict what an attacker can do, but do absolutely nothing to prevent reading or changing database records, obtaining user info, running malicious programs etc."
Securelevels are what they are, and should be used accordingly. This is just bad judgement of the technology. Please don't assume something does more than what it actually does, this is not a good practice, please read the documentation and/or talk with the community, securelevels are well documented. It is very bad to expect securelevels to protect your database from being changed or your code from being abused and use that as an argument against the OS.
(edited, small typos: added an "it" and changed SO to OS)
Re: The Insecurity of OpenBSD (2010)
#6OpenBSD 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 thes…
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.
Re: The Insecurity of OpenBSD (2010)
#7There 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 misconcep…
pledge, W^X are examples of the former approach.
Re: The Insecurity of OpenBSD (2010)
#8OpenBSD 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 thes…
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 clie…
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.
Re: The Insecurity of OpenBSD (2010)
#9OpenBSD 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 thes…
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 clie…
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.)
Re: The Insecurity of OpenBSD (2010)
#10Ah, the age old promise of MACs: perfectly secure, as long as you don't think very hard about the fact that somebody has to administer the access control rules.