
Rethinking OpenBSD Security - zdw
https://flak.tedunangst.com/post/rethinking-openbsd-security
======
h2odragon
Good writeup, fairly made points. It'd be easy to laugh at OpenBSD finding
SMTPD vulnerabilities _even now_ (I did); but as TFA points out it's
complicated and often hard to see these things.

And that's in OpenBSD which has had the honest effort and passion of scary
geeks with no sense of proportion for how many years?

Compare that to the security posture inherent in projects that install with

    
    
        sudo bash <(curl -sL someurl.wtf/thatredirectsanyway )
    
    

"Secure" computing today is just not going to happen. Not saying its a bad
goal, or a waste of time; just that its a metaphysical pursuit of perfection
doomed to beautiful failure.

~~~
pjmlp
It will happen, slowly but it will, liability law suits and media exposure
just need to increase, then more companies will start paying attention to
security.

~~~
jstimpfle
I think some people just need to step up instead of only evangelizing, and
actually build something that is useful _and_ "secure"

Oh wait... There are actually tons of such projects. Why did they not take
off? (I'm trying hard not to sound cynical because I don't really know that
there is absolutely no way that they could, but also I do feel cynical)

~~~
wyager
> There are actually tons of such projects. Why did they not take off?

Secure computing requires a relatively low time preference to be economical.
Or, more precisely, marginal demand for secure computing increases with a
marginal decrease in time preference. Most companies have (artificially
inflated) high time preferences, so it's not economical for them to adopt what
we consider secure computing.

This is, I believe, to the net detriment of human society as a whole (at
least, at my personal time preference).

I'm not going to get too much into _why_ time preferences are so
(artificially) high on here, but I encourage people to look into it
themselves. A lot of it has to do with government economic intervention,
especially around monetary policy.

~~~
wbl
Rates are low, which signals willingness to invest long term. Are you sure you
got the monetary policy right?

~~~
wyager
Long delay, but I just saw this: the availability of loans well below
“natural” market rates encourages consumption _now_ , because you can just
take out a honking big loan and you won’t have to deal with the consequences
for a long time. I.e. it inflates effective time preference.

------
api
There's a factor with OpenBSD that isn't mentioned here at all: it has very
few developers.

A single developer can hold much or all of the state and important security
considerations in their head. A small team can communicate well and can hold
to a single style, and members of a small team can ask each other things
easily. Single developers or small teams can write secure code in unsafe
languages.

The problem is that this doesn't scale. Add a large number of developers and
it becomes increasingly difficult to police security in an unsafe language.
Safe languages, unit tests, and fuzzing help a lot more here by making large
classes of errors difficult or impossible to manifest or catching them
automatically.

Linux is a bit special here: it has a lot of developers but a small number who
are responsible for approving things, and it's so massively important and
popular that it has a lot of eyeballs on it and gets a lot of automated
testing. Security issues still creep in though.

~~~
chasil
You might claim that the security design of OpenBSD does not scale, and the
observations of the parent article do cast some reasonable doubt on code
security.

However, a number of projects from OpenBSD have been widely adopted and are
successful in their own right, for example:

    
    
        C:\>ssh -V
        OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4
    

The two projects above, OpenSSH and LibreSSL, have been even more strongly
adopted by Apple, as I understand it. OpenSSH is adopted by just about
everybody.

Google Android's "bionic" C library is also based on OpenBSD, and I would
imagine that the coding concerns for libc will trickle down.

OpenBSD is not the sum of its parts, as so much of it is used in other
environments.

~~~
loeg
Bionic took pieces from OpenBSD, as well as other places[1].

[1]:
[https://en.wikipedia.org/wiki/Bionic_(software)#Components](https://en.wikipedia.org/wiki/Bionic_\(software\)#Components)

------
ainar-g
Honest question. Why not just completely outlaw code like:

    
    
      exec("/bin/sh", "-c", "...");
    

And its friends? It feels like it does way more harm than it does good.

~~~
peterwwillis
Because arbitrary "Thou Shalts" do not prevent security holes. Make a
restriction, and hackers will find the cracks around it. The only way to stop
them is to fill the cracks, and the only way to find the cracks is to look for
them. Now, certainly if there was an exec() _replacement_ that was more
secure, you should use that; but banning exec() entirely is doing more harm to
functionality than good to security.

Particularly, the exec() bug here is one of misunderstanding the security
guarantees of interfaces; particularly, that _there are none_. Not validating
inputs is the single most universally known security practice, and yet it
wasn't done here. On top of that, not using typed objects further increases
potential for attacks. This was just shit security design. exec() had about as
much to do with the bug as your brakes have to do with you locking up your
wheels when traveling too fast in rain/snow/ice. (that you should have been
going slower, not that the brakes are defective)

~~~
ainar-g
I haven't proposed to ban exec entirely. I've proposed to ban exec uses that
just sends data into a shell.

~~~
loeg
When a user runs 'sh -c "foo"' on the command line, how do you think that is
executed?

Taking a step back, Unix's programming model is heavily influenced by the
design requirements of interactive bourne shell. It's hard to outlaw shell-
like things without breaking shells.

------
smitty1e
> Privilege separation is a key component of OpenBSD security, and
> interprocess communication is at the heart of it. More focus on what can go
> wrong with corrupted processes would help. Secure browsers are evolving
> longer and longer kill chains. smtpd in particular is supposed to be secure
> against memory corruption in the network processes, but the ease with which
> it can control the parent is pretty alarming.

This invites the sincere, honest technical inquiry as to why OpenBSD doesn't
have an SELinux-style Mandatory Access Control (MAC) facility, but is OK with
the traditional Discretionary Access Control (DAC).

~~~
GeorgeWBasic
They have pledge(2) and unveil(2) instead.

~~~
smitty1e
Excellent. Thank you.

~~~
beefhash
I feel like I should add a bit that pledge(2) and unveil(2) take the
"opposite" approach of SELinux. Instead of caging an application in _hopes_
that the cage is correctly set up, the responsibility for pledge(2) and
unveil(2) is intended to be with the application developer, who minimizes
system calls as much as possible and only keeps paths unveiled that they
actually require. As far as I know, the idea here is that the developer knows
best.

People seem to have been experimenting with applying these restrictions from
the outside, but it's generally hard to guess how a large program from ports
will behave.

~~~
floatboth
SELinux wasn't even invented for app sandboxing, even though e.g. Android uses
it for that. There are LSMs designed for app sandboxing, like Canonical's
AppArmor. SELinux (and MAC in general) comes from the NSA world of big
government servers with complex policies about which actual human users can
access which documents and so on.

------
patrec
> OpenBSD aims to be a secure operating system

Pretty idiotic aim if you're writing it in C.

------
st3fan
AFAIK (correct me if I am wrong) OpenBSD does not have a single unit test.

No unit tests.

There is so much code that parses text input and yet I can’t find a single
test that actually shows that the code works and that it properly deals with
malicious input.

How do OpenBSD developers test? How do they make sure changes do not regress
things.

Why is unit testing just not a thing? (Same for many other C based projects)

~~~
clarry
Which one of these bugs would have been prevented by unit tests? Probably
none, because you'd have to know about the bug in order to craft a test that
exploits it.

~~~
sildur
Unit tests could prevent reintroducing old bugs.

~~~
clarry
You have regression tests for those.

[http://cvsweb.openbsd.org/src/regress/](http://cvsweb.openbsd.org/src/regress/)

------
jancsika
Hi Ted,

Please change your page design so that the content is centered horizontally.
Otherwise we have to swivel ourselves toward the left side of the screen to
read the article.

Sincerely, My Eyes

