
The Insecurity of OpenBSD (2010) - rev
https://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/
======
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

~~~
danieldk
_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".

------
HugoDaniel
Aren'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)

~~~
dispose13432
pledge and, say, SELinux solve two different problems:

Pledge stops trusted software from being exploited. I trust Apache (I run it
as root) but the authors can't guarantee that it can't get exploited, so it's
protected by pledge. If I didn't trust Apache, I wouldn't trust that it
pledged anything.

SELinux secures un-trusted code. So if I download a program off the internet
and run it as nobody, it shouldn't exploit something to get root. This is
useful when downloading random closed-source programs (such as on Android).

Unfortunately, Linux relies on SELinux to solve problem #1 (how do I know
which files does Apache really need, and which won't help security exploits),
which is why it gets such a terrible reputation.

~~~
djsumdog
I've had to make AppArmor profiles in the past and they can get a bit painful.
I've never had to configure SELinux so I don't know how much better/worse it
is.

That being said, I think Docker and other container systems are going to
remove the need for these security profile systems.

Yes, if there is exploitable code in the container, it can read/write to other
things in the container. But so long as you keep the docker daemon up to date
on its security patches, application exploits shouldn't be able to leak beyond
the container, with the exception of volumes and linked containers/ports.

~~~
ams6110
The typical configuration I see in /etc/selinux/config is:

    
    
       SELINUX=disabled

~~~
protomyth
Its definitely one of the things that shows up when you call about a lot of
vendor's software support. I find it rather annoying that a company tells you
to buy a specific Linux distribution then pulls exactly what you say.

Thinking about it (maybe because I am watching a update go as I type), what
the heck does this say about how we program? I guess in some ways its why I
like the idea of pledge. It makes me think better of the programmer because
they have put some thought into their program. I'm not sure what I should
think when I see SELINUX=disabled as a possible solution.

~~~
dispose13432
>Thinking about it (maybe because I am watching a update go as I type), what
the heck does this say about how we program?

SELinux is not complex because we program in complex ways, but because we
don't know the target program.

For example, (again, nothing against Apache but...) if I want to secure
Apache, there's no way for me (as a sysadmin) to tell exactly which files,
exactly which syscalls, and exactly which libs does it need to function, and
there's no way for me to stay on top of it.

And the same applies to any other complicated software. How to I lock down X?
Firefox?

Really, the beauty of a "pledge" like system is that the programmer/PM of the
code (which he should understand) should know how to lock it down

~~~
nickpsecurity
You can do that in a SELinux-like system. There's been tools and policy
languages for it. Even better, if the language is high-level & declarative,
then it can be used to generate security policies on many different OS's and
mechanisms instead of just SELinux or pledge.

~~~
protomyth
Which projects are doing this with SELinux?

~~~
nickpsecurity
I haven't followed SELinux in a while. I recall Tresys made tools with dialog
boxes to make it about as easy as Windows firewalls. A quick Google leads me
to Lobster being an example of what I was thinking of:

[https://selinuxproject.org/files/2008_selinux_developer_summ...](https://selinuxproject.org/files/2008_selinux_developer_summit/2008_summit_white.pdf)

~~~
protomyth
Given how fast pledge was able to be put into production, I think it was the
right move. I get SELinux can and has (2008) had tools for this, but it really
doesn't seem to have caught on.

~~~
nickpsecurity
SELinux was a demonstrator of Type Enforcement by Mitre. It got put into
production because why not. There's simpler schemes out there for MAC even on
Linux. I'd have recommended OpenBSD clean-slate something like them.

I do like pledge, though. I promoted API reduction a long time. Even deleting
the code in kernel for appliances a la Poly2 project. Only so much can be
gained with it, though.

------
gbrown_
I would simply say OpenBSD runs.

It runs with it's hardening mechanisms always on. Ports are considered in
whether a new mechanism or aggressiveness of an existing mechanism is
suitable. The idea is to have a platform where good quality software runs and
bad quality software crashes. See the evolution of the default malloc.conf
options or more recently the explicit enforcement of W^X.

It's true OpenBSD was not founded with the intention of being "the secure OS"
but the ethos of designing secure software is very much something that is core
to the developers today.

Others have already pointed out cons as well as pros of MAC style systems
which this post laments the lack of in OpenBSD. I'll simply say I prefer the
approach of pledge. Yes you need to build it into the application but I think
that kind of upfront explicitness is better than a policy system and I hope
other platforms adopt it.

------
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.

------
elchief
Ports might be unaudited, but OpenBSD base has lots of useful stuff that many
people don't know about. Like OpenBSD's own web server, LDAP server, IPSEC/VPN
implementation, time server ...

All priv-sep'd, simplified, pledged

Also, these days the preferred MTA is OpenSMTP, and the preferred name server
is NSD

------
bandrami
Ah, 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.

~~~
danieldk
MACs come in many different flavors. E.g. AppArmor is very easy to
administrate an provides security over running 'random' applications without
MAC.

~~~
bandrami
There's two separate issues here, both of which apply:

1\. A knob that can't be configured can't be misconfigured (IIRC Debian had a
hole in its default selinux config for years that created a vulnerability
selinux-less machines didn't have)

2\. (This was more what I meant) the promise that makes people like MACs is
that you no longer need a single all-powerful root user to do everything (this
bleeds into ACLs and capabilities, too), but keeps running into two icebergs:

2a. Somebody still has to administer those controls, and so can effectively
become that all-powerful root, and

2b. The only stuff I actually care about is the actual data that the
application being sandboxed can access to begin with.

This gives us the particularly pointless exercise in which somebody who steals
my laptop can impersonate me on gmail and social media, empty my bank account,
and delete all my github repos, but can't change the laptop's time zone. The
system files that I can download for free at any time are protected, but the
manuscript for my novel is not.

~~~
dom0
> capabilities

Well. There just aren't many useful caps to begin with. For example, consider
backups. You'd want the backup system to have full read access to everything.
Well. You can't do that with capabilities. You only get DAC_OVERRIDE, which is
one of the many root-equivalent caps in Linux. Probably half of them are.

~~~
ori_b
Even better, in my opinion, is that many of the caps that you would use to
sandbox an app (like PID and FS namespaces) require you to have the sysadmin
capability set on the process.

Great. You need to give a process more or less root so that it can deny itself
privileges.

~~~
dom0
The idea is probably that the service manager ( _systemd_ ) manages the NSs
for the applications contained therein. _systemd_ of course doesn't have to
check it's own privileges.

~~~
bandrami
GNU PIES, however, does check its own privileges. I have no idea why it didn't
get a harder look during the init wars. I get that Shepherd "isn't there yet",
but IMO Pies is.

------
wyager
> There is no good reason to avoid implementing extended access controls when
> the greater security and control they provide is irrefutable.

Disagreed. MAC is a crutch and a hack, not a solution. We should prefer not to
rely on half-assed, overcomplicated, and formally unverifiable palliative
measures.

If you want security, you fundamentally must use secure software. No amount of
sandboxing or access control wrapped around a vulnerable garbage heap is going
to stop the garbage heap from getting hacked in the first place.

~~~
nickpsecurity
There were numerous examples of MAC, esp SELinux, stopping vulnerabilities.
There's also plenty of examples of bugs and vulnerabilities in software with
OpenBSD even fixing bugs regularly. The claim that one should reduce bugs and
have damage limitation to reduce overall risk is rock solid with proof in the
field.

The refrain of OpenBSD supporters is, "It's not necessary and won't help..."

The reality in field deployments, "It was and did."

QED.

~~~
wyager
> There's also plenty of examples of bugs and vulnerabilities in software with
> OpenBSD even fixing bugs regularly.

As the OpenBSD devs will tell you, there have only been two known
vulnerabilities in default OpenBSD installs in the history of OpenBSD. This
strongly suggests that having decent software quality is an effective way to
prevent vulnerabilities from existing in the first place.

> The refrain of OpenBSD supporters is, "It's not necessary and won't help..."

No, the refrain is "it's better to spend effort curing the disease than
treating the symptoms". If we put half the effort we put into palliative
defense measures into formal verification or doing things right the first
time, I suspect it would be drastically more effective.

~~~
nickpsecurity
"As the OpenBSD devs will tell you, there have only been two known
vulnerabilities in default OpenBSD installs in the history of OpenBSD. This
strongly suggests that having decent software quality is an effective way to
prevent vulnerabilities from existing in the first place."

I addressed that myth in my main comment. See here:

[http://pastebin.com/6cW3FyJE](http://pastebin.com/6cW3FyJE)

They just assess and count differently than most folks. ;)

" If we put half the effort we put into palliative defense measures into
formal verification or doing things right the first time, I suspect it would
be drastically more effective."

I agree being on side of high-assurance security. OpenBSD doesn't so I don't
know your statement supports what they do. They systematically avoid formal
verification like what you described, safer languages, coding styles for
static analysis, etc. It's people from my side of things promoting or building
on those. They just hunt bugs in C code by eye and hope their probabilistic
mitigations always work. Totally different.

------
module0000
What mission critical systems is OpenBSD running _anywhere_? I'm talking about
the OS itself, not one of the pieces of software developed as part of the
project and ported to other platforms(eg openssh). Not trolling, but genuinely
curious where OpenBSD is running outside of our basements.

~~~
nickpsecurity
Genua on milcron's list is probably most significant. They are a defense
contractor that sells firewalls, VPN's, data diodes, etc for business and
government (including military). You can bet significant applications are
protected with them.

This is the kind of role most of its users put it in. Others just use it like
any other server OS with better reputation for reliability and security. Less
patching... a time-consuming activity... at the least. Last one was similar
reason for adoption of Argus Pitbull and SELinux w/ Tresys tools in their
niches. Less worries when malware is going viral on the Internet and in media.
;)

------
atmosx
Out of curiosity, anyone ever worked with an hardened OpenBSD or Linux + GRSec
server farm? How do you handle updates? It must a sysadmin deployment
nightmare.

~~~
milcron
I don't operate a server farm but OpenBSD updates are pretty easy. Just do
`pkg_add -Uu`.

If your dependencies are minimal, keeping OpenBSD up-to-date is actually
pretty relaxing. Don't need to install security patches all the time as with
Linux.

~~~
countingteeth
pkg_add -Uu won't address a single update under
[https://www.openbsd.org/errata.html](https://www.openbsd.org/errata.html) ,
i.e. the very most important ones.

Also as far as I know pkg_add still doesn't know about restarting services, so
vulnerable processes will be left running.

------
youdontknowtho
This guys makes some good points, but the OpenBSD guys have been able to
improve the security of OBSD with code quality.

It's also not completely accurate to say that OpenBSD hasn't contributed
anything to security. They have. Maybe it was more true in 2010, but it's
certainly not the case now.

I have found lots of Unix people (devs and admins) don't really seem to care
much for MAC. I don't really understand it, but its true.

~~~
ams6110
Admins in particular like to (a) understand how things are configured and (b)
avoid changing things (creates work and potential update conflicts).

MAC configuration is complicated, tedious, error prone, and seems to bite you
in the ass with every update. All things that make a bad day for an admin.

~~~
youdontknowtho
I'm an admin. Have been for many, many, moons. I've found that when things
seen to behave that way it's because I have failed to sufficiently adjust my
understanding of them. Often, we can be guilty of expecting that everything
should behave like the least common denominator set of features between all
host systems. Often, there is great value in finding "the way" that a
particular system is trying to exemplify instead of forcing it to match my
own.

To be fair, that least common denominator set of features can be very powerful
and capable. It's not a slam, I'm just saying that finding out the in depth
method of operation for a given system can often be rewarding.

------
countingteeth
Much to like, but one point is somewhat outdated and another is missing.

1\. The lack of an AppArmor-type MAC implementation is somewhat outdated since
Theo rolled his own with "pledge". I'm not a huge fan of how a cabal of Theo
plus one or two guys basically hacks out something of new cloth on a whim to
solve a problem that's been done many times before, on the arrogant
supposition they're doing it better than anyone else has ever done, and then
promptly stuck it into production. This has happened many times before.
Certainly some results have been good, but case in point, "doas". You upgrade
one point release and suddenly sudo is not there any more, you have a new tool
lacking basic features with completely different semantics. Yes, you can
install sudo as a package if you want. Yes, maybe doas is smaller and easier
to audit. But was sudo really a problem? Sure the fanboys will love it, but
most normal UNIX people are probably not going to appreciate something like
sudo just going away. It lacks little "features" like credential caching,
which I am sure the fanboys will tell you is bad to begin with, but which most
of the rest of us will find a pain in the ass. This sort of thing happens with
OpenBSD semiregularly.

Of course, many of these homegrown solutions are produced after years of Theo
& cabal insisting that there was no need for it and it was wrongheaded.
There's "pledge," but then there's little things like full-disk encryption,
which is basically a requirement for use on mobile, but which OpenBSD never
had any use for, until it did, and came out with its own homegrown thing
(which still doesn't work that great, especially when upgrading).

*And since so many others have brought up pledge, it's not really a solution on the same scale since you have to build the pledges into the application, there's not an easy system for imposing pledges on an application externally. This makes maintenance and adoption much harder, basically nonexistent for most of the package tree.

2\. The big reason OpenBSD is insecure, is its lack of any meaningful update
mechanism to their supposedly rock-solid secure base system. Literally the
official way to do security updates is to monitor OpenBSD's website, download
and apply patches by hand to a source install, rebuild, and run a series of
listed commands by hand. If you want to automate this further, you are on your
own. It's been this way forever. It's craziness, and it a big reason that
OpenBSD is basically not an option for production in many settings.

Upgrading to new releases is a similar deal. The homegrown sysmerge hack has
made this slightly less awful, but manual hackery is still required,
unreliable, can wipe out customization, and doing a clean reinstall is still
urged as the best path in many cases.

~~~
notaplumber
> It lacks little "features" like credential caching

This is wrong, see the 'persist' keyword. It was also implemented as a kernel
assisted feature, rather than filesystem tickets.

[http://www.tedunangst.com/flak/post/doas-
mastery](http://www.tedunangst.com/flak/post/doas-mastery)

[http://marc.info/?l=openbsd-
cvs&m=147283992915418&w=2](http://marc.info/?l=openbsd-
cvs&m=147283992915418&w=2)

~~~
countingteeth
For some reason my post was deleted, but to repeat, you are pointing to a
recent commit made to CVS.

------
nickpsecurity
Interesting for this post to turn up as I was drafting and getting review for
my own rebuttal to OpenBSD propaganda on Schneier's forum. I couldn't find it
as I needed it. (shrugs) Quick attempt at redoing it here.

Started with this on Lobste.rs forum that's popular for OpenBSD developers:

[https://home.nuug.no/~peter/blug2016/img1.html](https://home.nuug.no/~peter/blug2016/img1.html)

Similar to some of the BS allthatiswrong counters. I'm just focusing on a few
as it will already be a long writeup with many examples from history on where
secure coding and UNIX really came from. In this Pastebin:

[http://pastebin.com/6cW3FyJE](http://pastebin.com/6cW3FyJE)

