
Why we use OpenBSD at VidiGuard - protomyth
https://blog.vidiguard.com/why-we-use-openbsd-at-vidiguard-4521f217b2b7#.d1q9kgvba
======
sivers
For those expecting a little more content, here's a better "why":

[https://deftly.net/posts/2016-05-31-why-i-run-
openbsd.html](https://deftly.net/posts/2016-05-31-why-i-run-openbsd.html)

(I agree and have gone 100% OpenBSD on all servers and even all my laptops
now. Love love love.)

~~~
na85
If you don't mind: which laptop models do you run it on and how is the
performance compared to other OSes?

I found openbsd ran horridly hot and sluggish on my thinkpad so I've been
trying to find a laptop that will work well with it.

~~~
sivers
Lenovo ThinkPad W520 = my main

Lenovo ThinkPad T440s = a clone of my main

Both work great. I had some issues before OpenBSD 5.9 but since 5.9 everything
is wonderful, which is why I finally switched over 100%.

Doesn't run hot. Only a miniscule slower than my souped-up super-fast Arch
Linux was on the same laptop, but that's a fair trade.

Happy to answer any questions and offer any advice. Click my username here and
get my email address from my HN profile.

~~~
jvoorhis
Does it run on those old SPARCs?

~~~
sivers
Ha! Hi Jeremy. Can't believe you remember that.

Sold those big Sun machines with the company, unfortunately.

------
tptacek
It is --- let's put it this way: --- not uniformly the opinion of software
security pros that OpenBSD is your obvious-choice best bet for secure
operating systems. It may depend on what you're doing with the system, too.

~~~
notaplumber
Why isn't an obvious choice? What other system has enabled by default the
following security mitigations:

* Enforced W^X in the kernel on i386/amd64/sparc64.

* Enforced W^X userland as of 6.0 (..exceptions must have a special ELF PT_* flag and be on a filesystem mounted wxallowed).

* arc4random(3), which backs rand(3), random(3), and drand48(3), with an audited base/ports tree. Software must opt-in to deterministic broken POSIX behavior.

* Stack protector (..which OpenBSD pushed into wide adoption).

* bcrypt password hashes only, with an automatically selected rounds value based on system performance.

* PIE by default for base and ports.

* Static-PIE for self-relocating static binaries.

* SROP (sigreturn(2) oriented programming) mitigation by default.

* C shared library re-ordering at boot time, i.e: libc.so is re-linked at boot time so objects are randomly ordered.

* System-wide sandboxing (pledge(2)) of a large percentage of the userland, incl. privileged part of the X server, most networking facing daemons included (..with increasingly reduced pledges, thanks to the next part..).

* Privilege dropping and separation for most of the base system as a matter of policy, new stuff doesn't get enabled without it.

Plenty of other innovations in programming interfaces, widely adopted outside
of OpenBSD.. which leads me to disbelieve your claims of non-uniformity in
opinion of any reputable 'security pro'.

[http://www.openbsd.org/innovations.html](http://www.openbsd.org/innovations.html)

~~~
tptacek
Here's something I wrote a few years back here. What's changed in the 6 years
following is that I think we're down to just two approaches, unless you feel
OpenBSD is assimilating the MAC approach.

[https://news.ycombinator.com/item?id=1997385](https://news.ycombinator.com/item?id=1997385)

~~~
ghshephard
I read through your 2010 post three or four times - but it doesn't really seem
to be as relevant to 2016 OpenBSD. 2016 OpenBSD assumes that there will be
errors in the code, and furthermore, there will be errors that have downstream
security effects that the authors can't envision today. A lot of the thinking
around pledge (2) is that behavior that an SElinux MAC audit would record, and
therefore allow moving forward, should _not_ be allowed. The entire operating
systems seems to be designed in the belief that there is no way to write bug-
free applications, so at every level, the operating system, and kernel, should
be designed with the expectation that an attacker has broken applications in a
manner _not envisioned_ by the application writers of the time.

As such, a number of attack/bugs found in other operating systems, don't
impact OpenBSD because they were forward looking.

I'm wondering if you've had a chance to review the change in thinking that the
OpenBSD organization has had in the last 6 years, and how it might impact your
original 2010 post?

~~~
danieldk
_A lot of the thinking around pledge (2) is that behavior that an SElinux MAC
audit would record, and therefore allow moving forward, should not be
allowed._

There are important differences. _pledge_ requires you to modify an
application. SELinux can sandbox any application, including untrusted
applications (see the use of SELinux in Android).

Since SELinux is external to the application, a system administrator can
specify/refine a policy, while pledge calls are compiled in.

 _As such, a number of attack /bugs found in other operating systems, don't
impact OpenBSD because they were forward looking._

This vision is not exclusive to OpenBSD. Red Hat Enterprise Linux has included
many of the same mitigation techniques for a long time (starting at RHEL 3 in
2003). Moreover, they have shipped SELinux, which is arguably more powerful
than pledge since RHEL 4 in 2005.

(I don't want to discredit the work of the OpenBSD developers, which is great.
I just want to point out that there are Linux distributions with similar
features, wider hardware support, and wider vendor support. Many OpenBSD
supporters just seem to ignore work by others in order to push their favorite
system.)

~~~
ghshephard
Yes - it's a good point that pledge(2) requires that you modify the
application, and, that's too some degree a downside of the model. On the
flipside, you can't turn off pledge(2) - which has been the default behavior
of every (admittedly junior) sysadmin I know who ran into a problem with
SELinux that I've seen. The point I was also trying to make (and I'm not sure
if I was successful) was that the use of pledge sometimes results in the
application being modified to prevent overly permissive behavior
([http://www.tedunangst.com/flak/post/going-full-
pledge](http://www.tedunangst.com/flak/post/going-full-pledge)) - whereas in
the SELinux "audit" mode, that permissive behavior would be noted, and
permitted.

I"m just wondering whether tptacek has rethought his comment from 2010 about
OpenBSD _" its model depends on shipping bug-free distributions "_ given a lot
of success OpenBSD has had in the past several years dodging exploits that
resulted from bug-present distribution issues, that its OS
compartmentalization approach has successfully avoided.

------
phantom_oracle
I'm guessing if you're going to blog about security, it would make sense that
vidiguard.com (the main site) should be, _at the very least_ , HTTPS-enabled.

~~~
microcolonel
Why does their marketing website need to be HTTPS-enabled? I mean, they will
need to do it to appease Chrome in a few months, but really it has no effect
on just about anything. They don't administrate the drones through their
marketing front page.

The website has other problems though, mainly the excess of effects and
reliance on hover states for presenting useful information. Nothing that HTTPS
is going to fix.

~~~
subway
Marketing sites often provide contact information for your organization. A
MITM on your marketing site means Mallory can alter your contact details and
potentially intercept your communications.

This is one reason to enable HTTPS on your marketing site. There are many many
others. What reason do you have for _not_ enabling HTTPS?

------
joshbaptiste
Wish he went more into how exactly OpenBSD is keeping their customer data
safe, are they running a database on OpenBSD? Storing data on the file system?

------
ysleepy
SSL seems to be broken.

[https://vidiguard.com/](https://vidiguard.com/) Failed to load resource:
net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH

------
thepumpkin1979
Well, I was expecting a little hit of more information out of it.

