I installed OpenBSD on my laptop a few months ago, and the number of things that worked out of the box (screen resolution, wireless internet, touchpad) made a very good first impression. Since then it has yet to surprise me unpleasantly, something other *nix's were wont to do.
Same here. I've been using OpenBSD off-and-on since version 2.9 which I think was like 1999 or 2000.
I'd go switch to some new version of Linux for a while, try FreeBSD for a while, and each time I tried OpenBSD again - OMG it just works with no effort, whereas the others (besides a kitchen-sink OS like Ubuntu) would never quite get it right.
Even for things where super-new Arch Linux would have trouble with the hardware, or require lots of tweaking to get Xorg working on a super-new laptop or whatever, just stick in the OpenBSD CD or USB, hit [Enter] a bunch of times for the defaults, and voila! A perfectly working base system, including X11 and all.
I recently installed it on a Lenovo X1 Carbon 2nd Gen. The only headache was the Intel wifi chipset needing proprietary firmware (easily obtainable after install, but I wasted a bunch of time trying to get it working on install only to learn I really didn't need it despite thinking I did). Other than that hiccup, literally no other OS issues at all and no custom tweaking needed to get a solid setup in place.
My recommendation is to do the install using 'disk' option rather than 'http' skipping verification as needed. Then you don't need to worry about the firmware during install. The installer's ramdisk is only 2mb, so the 675k firmware for the wifi doesn't fit. Yes, you can have the firmware on a second USB drive, but as the installer unmounts all mounted volumes it takes extra steps that's more hassle than it's worth. Once you complete the install, you'd normally use `fw_update` to get the firmware, but as you are caught in a catch-22, you'll need to grab it from here [0] from another machine and then extract to /etc/firmware on your own manually.
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.
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'.
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.
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?
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.)
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) - 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.
Like I said, I'd be willing to stipulate to an argument that the OpenBSD and MAC approaches were merging.
The stuff going on with pledge is a step forward! I like 2016 OpenBSD more than I did 2010 OpenBSD.
(I was, as you probably know, involved in OpenBSD in the 1990s, and then, because I worked for a company staffed by Monkey.org people, shipped a demanding product on it --- both experiences left a bad taste in my mouth).
In [1] Ron Wilson examines two models almost in the same terms ("Internal security" and "Guarding the perimeter"), but the third is different
> That brings us to our third—and today, still experimental—alternative: deep learning. Connect the critical state variables of the system to a deep-learning neural network. Train the network with a blend of normal operation, known attacks, and randomly injected faults. You may never know how the resulting network operates, and you can’t prove that the network is sufficient or even correct. But in complex systems it is likely to out-perform human-devised rule lists
Linux with grsecurity is a pretty obvious alternative. There are distros which include grsecurity patched kernels in their repo (or use it by default) although going this route over a self-compiled one does loose out on a few security features.
Some grsecurity features are supersets of the features you listed such as the W^X protections (which I might add have been in PaX for quite some time now). While the situation certainly isn't perfect with getting more packages using PIE at least a number of important packages are now built with that by default. Arch Linux compiles all packages in its repo's with stack protection AFAIK and at least on Arch it's very easy to recompile things to suit your (performance) needs/threat model.
Perhaps OpenBSD offers more of these compiled protections by default in its base/ports but you can still get these options on Linux if you're willing to put a little effort in or use the right distro for your needs.
OpenBSD is less of an obvious choice when you look at what you can do with grsecurity if you put a bit of effort into it both on the side of grsecurity (RBAC) and setting up your distro. You can't just wave your hand and dismiss grsecurity because you believe it to be non-standard/non-upstream or somehow incomprehensible/complicated. It's not about what's enabled by default, it's about how much security/protection/defense in depth I can get from it and arguably you get more from Linux w/grsecurity.
The point is "optional security is bad security" because when stuff doesn't work it gets turned off. So _nobody_ turns those things on.
In OpenBSD all the mitigations are enabled all the time, and with pledge beeing the responsibility of the coder, no extra effort needed from the sys admin.
I was just trying to make a point that OpenBSD is not always the best choice for all possible use cases to expand upon tptacek's post a little. In may be for someone uninformed or lazy but my argument is if you're willing to put in a little effort you can get a system which is arguably better from a security and defense in depth standpoint than OpenBSD.
There are obvious benefits to both but I don't think that grsecurity is something which can be dismissed as easily as saying nobody uses it.
You just argued that OpenBSD is more secure because it has specific feature set. You didnt prove these are the right combo of features, that they in solo/combo work against strong attackers (instead of obscurity advantage), or even strongest ones of their respective classes (they're not). You started with OpenBSD's features, accepted the claims as fact, ignored all other tech/requirements, and then asked other party to prove their claim with evidence.
Wrong way to do an argument for or even against OpenBSD. You need to establish requirements for security in many areas, features/practices to support those, assurance they work, and then what each OS or system possesses. OpenBSD has only partly done this so I doubt uou have. I look forward to you posting that analysis for OpenBSD and its preferred hardware.
> You didnt prove these are the right combo of features, that they in solo/combo work against strong attackers (instead of obscurity advantage), or even strongest ones of their respective classes (they're not)
Security mitigations work best in combinations, the entire purpose is to make it as hard as possible to attack the system.. suggesting OpenBSD's mitigations aren't the strongest in their class clearly needs some proof on your part, but I don't expect you'll deliver.
> You started with OpenBSD's features, accepted the claims as fact.
I stated the facts, because I'm aware of and closely followed their development, having tested them. I accepted no claims as "facts". You can easily verify everything I've said, OpenBSD is open source.. and shocking, they pioneered that too.. having created anoncvs.
Not much left to reply to in your post, because you're just grasping at proverbial straws.
Exactly the kind of meaningless statement I was talking about. You've neither proven they work in isolation nor shown they're a strong combination against determined attackers. Almost all of those people are hitting Windows, Linux, iOS, and Android due to market share. Im not sure we've even seen thorough test of OpenBSD's defenses.
"suggesting OpenBSD's mitigations aren't the strongest in their class clearly needs some proof on your part"
Let's try a few memory or stack issues. SPARK can prove the absence of most of them. Concurrent Pascal and Eiffel could for concurrency. Rust can for dynamic memory and concurrency. SAFEcode does for many C-related errors. Example uses are in Muen, Redox, and SVA-OS. Softbound + CETS goes further with total spatial and temporal safety for C but not in OS's yet.
These are all stronger than OpenBSD techniques for similar use cases. Different tradeoffs involved in using them but definitely stronger. I mean, full safety without GC is strongest you can get in memory errors. Although SPIN OS did it in Modula-3 with GC and type-safe linking too.
"and shocking, they pioneered that too.. having created anoncvs."
Your lack of research is apparent as the first, secure OS with source was Burroughs B5000. It was proprietary but shipped source. Had stack checks, bounds checking, pointer protection, OS in high-level language, compile-time checks for function calls, and run-time checks for invalid arguments. Started high-assurance security by addressing root causes of most known issues... in 1961.
It's also not easy to figure out OpenBSD security effectiveness looking at source. The safer languages like Modula-3 or techniques of B5000/JX-OS/Genode are easy to follow since they are simple & fully preventative. Verify that then the rest inherits its properties if used or interfaced certain way. Not so with OpenBSD's scattered mechanisms: requires much more analysis given use of C and stuff in kernel mode.
Finally, bringing up AnonCVS, you might want to look at David Wheeler's Software Configuration Management security page to see what high-security requires in that. Shapiro's OpenCM (in architecture) or competing Aegis (features) were ahead in many ways with OpenBSD's SCM tactics not registering a blip due to missing requirements on Wheeler et al's lists. I even watched them replaced a distribution tool known to resist NSA per Snowden leaks for a simpler, but unproven, one.
OpenBSD has proven great at configuration, code quality, and minimalism. Burden of proof is still on it in terms of security engineering practices vs other methods or OS's. It's never been proven from requirements to methods to results. Fine with me as it has it's uses, esp where 0-days being low is top priority. Best not to pretend it is something it's not vs making the case with evidence as I described.
There's a lot of security research going on at lots of places in all sorts of ways and that's great. But most of it results in better theoretical understanding. It doesn't result in an OS that can be used on commodity hardware in a production context. Good luck running Firefox on top of a some research OS written in Modula 3.
I just gave that as an example to illustrate the point about those security measures. There's others in real OS's and products in production now plus more that existed decades into the past. And quite a few, including one I named, can handle Firefox. Good, wild guess though as untrustworthy browsers designed for untrustworthy UNIXen are hard. ;) Look up OP2 Web Browser or IBOS Illinois Browser Operating System next time if you want architectures designed for secure OS's. Chrome's security was a knockoff of a predecessor of one.
The key word is "by default". I have no idea whether the Linux kernel that each distro ships enforced W^X. For userland, the effort is undergoing. For instance, I recently packaged a C application for Debian. Then, by sheer luck I stumbled upon the Debian Wiki[0] where it explained that one needs to specify "DEB_BUILD_MAINT_OPTIONS = hardening=+all" to enable compiler hardening options.
Why isn't that on by default ? The wiki asks the reader to enable hardening if the program handles untrusted data. Doesn't that apply to 99% of the applications out there ? Even it only reads its own configuration file, there is a possibility of a bug in the parser. Why take the risk at all ? Enable it by default for everyone and be done with it.
Regarding the pledge(2) sandboxing, pretty much every userland application in the base install of OpenBSD where is makes sense to sandbox is using pledge. Ports/packages are another story entirely.
Arch Linux enables -fstack-protector-strong last I checked by default. I admit Debian often drags it feet on some things like this but I think Ubuntu has enabled it for a number of packages as well.
Well grsecurity's mmap protections are a strict superset of OpenBSD's W^X which we've had for what 10 years now?
>Literally every other OS out there has stack protector, and it was Windows pushing it to wide adoption
I don't know when OpenBSD or Linux distro's were starting to add SSP support but stack protection/BSC (buffer security checks) have been enabled by default in every Visual Studio version since (at least) 2005. The mitigation has been improved over the years as well.
DEP and ASLR became default in 2008 (not really relevant here though).
When I encounter comments like these, a common theme is something like ~"OpenBSD didn't even set out to be a secure system. They forked NetBSD intending to audit the codebase and write clean, simple code going forwards. That such a system ended up being relatively secure is just a bonus."
To which I reply, this doesn't seem like a terrible downside. I like clean and simple code. There may be other options which offer more technical security features (something with ACLs, for instance), but none come even close to OpenBSD's simplicity.
And simplicity and readability really are fundamental to a secure OS, especially from the user's standpoint. It seems this was the main point of the article.
Secure by default means I don't have to turn off a bunch of stuff to make it secure. Rather, I have to think about what it is I really need to run on this particular system for whatever it is I'm trying to do. It requires a little more thought, since it isn't usually one of the 100+ processes and apps automatically started after installation on most distros. No, I have to figure out what I need, and maybe even port something. (That hasn't happened to me yet, but it could.) But that starting point is far preferable to weeding out a bunch of shit some distro roller thought I should have and disabling or uninstalling it.
And as the OpenBSD team occasionally points out, there really isn't a way to know that you have a 100% secure system now that all hardware has binary blobs that do unknown things. (Well, I guess you could fabricate your own chips and build your own motherboards from components you made and ....)
Thomas, I would love to get some insight on OS choice from someone so well respected in the security community, and maybe a short mention of why OpenBSD's security laurels may not be well deserved.
Some of the hype exceeds reality. I think the OpenBSD team at least tries to keep it level headed (but that's hard, everyone's biased in their own way), but the forum chatter version tends to eradicate subtlety. Second, what the operator does to a system matters at least as much as what they start with.
I don't know if it's what Thomas is referring to, but I ran OpenBSD in production for several years at a previous job. I found that, in practice, actually getting our platform to do what we wanted involved large amounts of ports (ie, outside the base system) to be installed. Sometimes, dozens of them. And this is where obviously your mileage will vary, because that depends what your servers are doing.
OpenBSD's incredible code quality quite obviously doesn't apply to the ports tree (and that's not their fault) but we quite often ran into less popular products and third party libraries where the ports were updated in the order of weeks later than things like RedHat RPM for the latest vulnerability.
At point I backported a hotfix myself, the requirement of which was not conducive to security.
Disclaimer: This was years ago, things may have changed.
The ports tree is obviously not audited by OpenBSD. The code comes from all over the net and the only thing OpenBSD does is enforce security mitigations/64bit time_t/arc4random/other coding practices in the base system, fix broken ports, send patches upstream and try to drag the whole open-source software community to better coding practices.
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.
Their main web site is 100% completely unusable on my iPad.
The content is completely covered by a blue overlay with a couple of "spinny things" on it that never go away. I took a screenshot but can't upload it anywhere at the moment. I'll send it over to my laptop and upload it shortly.
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.
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?
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?
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.)