The Insecurity of OpenBSD (2010)(allthatiswrong.wordpress.com) |
The Insecurity of OpenBSD (2010)(allthatiswrong.wordpress.com) |
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
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.
Most vendors and FOSS ignored them despite those methods getting consistently-great results but preferred method not doing so. They then pick and choose among lowest-level techniques for verification. They also slowly relearned independently some of the vast body of security engineering knowledge they're ignoring to this day.
In this case, one camp is about trying to make code in an insecure language perfect with probabilistic mitigations to stop problems. Another barely cares about code security but uses strong measures for containment to hopefully limit damage. Author of OP supports doing both as far as I can tell. High-assurance supports doing what was proven, mathematically and empirically, to get the job done going back to the 1960's-80's extended with what we've learned today. Commercial, CompSci, and a few FOSS projects attempt various levels of adoption of such techniques with safety-critical proprietary (eg aerospace, trains) doing it the most.
"There's not enough data / samples of secure operating systems to make an intellectually honest assertion that one approach is definitively superior"
There really is. Certain methods I outlined consistently worked better. Others didn't. OpenBSD avoids most of what worked outside code review, hardening, and pledge then continues to use language and architecture proven to cause problems vs alternatives for UNIX compatibility. One can definitely make predictions from that about kinds of issues they'll face or upper limits of assurance that can be provided.
There is no principle reason why these two philosophies - fixing bugs and explit mitigations - collide. You can strive for both - and I'd argue that that's probably what most infosec people would support. OpenBSD also does quite a bit of exploit mitigation, so they're not clearly on a "bug fixing" philosophy either.
I know Spender has a pretty extreme position in saying that fixing bugs is almost irrelevant. But I'd say he's an extreme voice in that debate.
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)
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.
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.
All priv-sep'd, simplified, pledged
Also, these days the preferred MTA is OpenSMTP, and the preferred name server is NSD
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.
The refrain of OpenBSD supporters is, "It's not necessary and won't help..."
The reality in field deployments, "It was and did."
QED.
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.
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. ;)
I see lots of academies, ISPs, and even Adobe is in there,
You run a custom repo with two packages, your compiled linux-grsec kernel, and a package that contains paxd and paxd exceptions for your typical binaries. Once you find a stable grsecurity kernel config you don't really have much to worry about.
When new updates are released, test them on your test tier with your existing PaX rules and exemptions, and if they pass tests push them into prod. Worst case scenario you disable PaX (and its memory protections) in emergency cases or rollback to the known good version. If you are running "unattended-upgrades" or something else and letting your tiers autopatch themselves, well, that's dangerous to stability in and of itself.
I run -grsec-patched kernels on all of my personal workstations as well. That's when grsec can be a pain.
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.
Also as far as I know pkg_add still doesn't know about restarting services, so vulnerable processes will be left running.
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.
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.
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.
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.
Started with this on Lobste.rs forum that's popular for OpenBSD developers:
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:
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.
Usually only targeted applications are confined by default and allowing unconfined applications to run without any protection.
Apparmor is easy and anyone can understand how it works after reading the wiki, while apparmor also has neat functions you need to compile them in sadly :(
OpenBSD is great, first you can leave it running for a long time without thinking about security bugs or updates, instead Linux you have to keep close eye to kernel updates & application patches, that's why things like mailservers & DNS & NTP and more are running OpenBSD because I know it doesn't need critical updates every week and uptime is critical for me.
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.
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.
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.
ACLs also make me as an administrator have to think much harder about, well, everything. Same problem with capabilities: each new layer increases the complexity of the reasoning required combinatorially ("so, the daemon isn't running as root, but it's in the daemon group, and the file has these capabilities, and those ACLs...")
(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.)
I've never heard of pledge so went looking to find out what it is and found Theo's presentation: https://www.openbsd.org/papers/hackfest2015-pledge/mgp00001....
(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, ...)
Complexity came when people wanted to apply MAC to poorly architected operating systems and programs. Especially monolithic UNIX. The LOCK program, which I link to in my main reply to OP, invented type enforcement in an effort to express vast majority of security policies for both their clean-slate, high-assurance TCB plus the UNIX VM's they were making for compatibility. Got applied to a BSD in Sidewinder firewall, then applied to microkernels at Utah in form of Flask architecture, and then ported as SELinux to Linux. As you can see, a series of tough compromises from Linux's insecure design plus the fact it was basically an academic hack led to its complexity and issues.
Simpler ones included LOMAC, rule-set based methods, Windows Integrity Control (similar to STOP's), and so on. TOMOYO and AppArmor at least did a learning mode that acceptance testing could feed. Capsicum brings capability-security model to FreeBSD on top of SEBSD enhancements. It's not kludgy MAC or nothing. There's middle ground.
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.
This is wrong, see the 'persist' keyword. It was also implemented as a kernel assisted feature, rather than filesystem tickets.
That is not how OpenBSD release numbers work. 6.0 is no more a major version than 5.9.
"download and apply patches by hand to a source install"
What the heck? I just use cvs. Its really easy http://www.openbsd.org/stable.html
The upgrading is not really that hard. I'm really at a loss given I find FreeBSD a pain in the butt to upgrade since it always breaks something but have had no problem with OpenBSD other than not reading their man hard link instructions which didn't kill anything but was annoying.
Oh yes, another hand-rolled "coming item," in the world's most secure operating system. Someday, someday OpenBSD will support critical security updates that don't involve recompiling by hand. After all, we finally got "signify" for the base system. That wasn't important at all.
> or you can use mtier.
Right. That's called "on your own." I was going to preemptively predict someone would mention that, but the fact that paid consultants provide a critical feature for security updates as a service that every single serious Linux distro built-in for free is not a point in OpenBSD's favor.
> What the heck? I just use cvs. Its really easy http://www.openbsd.org/stable.html
Ahahaha. NO ONE outside the OpenBSD bubble would say that other than as a joke.
And are you not forgetting that many of the critical security patches do in fact involve a series of additional steps that must be performed separately, manually? If you don't actually READ each patch, you can miss a necessary step.
And of course little things like restarting patched services automatically or knowing when a reboot is required, well, that's an exercise to the reader.
> The upgrading is not really that hard. I'm really at a loss given I find FreeBSD a pain in the butt to upgrade since it always breaks something but have had no problem with OpenBSD other than not reading their man hard link instructions which didn't kill anything but was annoying.
I'm not using FreeBSD as a point of comparison here. I love OpenBSD. I also am not going to wave off how crippled it is operationally out of the box and basically unusable for production in many nontrivial real-world settings.
There's also the little issue of getting your head bitten off and shit on for no good reason even when you're only being helpful in the meekest and most good-faith possible manner, but that's only a little worse than par for the open source world.
I addressed that myth in my main comment. See here:
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.
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.
The landscape is a little different now that hypervisors are no longer cutting edge, and the x86 architecture has improved virtualization abilities which help prevent some security flaws.
Hardware-assisted virtualization really took off in ~2008, but they've continued to add features over the past decade.
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.
Great. You need to give a process more or less root so that it can deny itself privileges.
Red Hat's has free updates? I was unaware of that. Mtier is free for the current version.
> Ahahaha. NO ONE outside the OpenBSD bubble would say that other than as a joke.
I have to patch Windows, FreeBSD, OS X (excuse me Mac OS), Red Hat, and Windows for my current job. I really don't get the problem with OpenBSD. I'm no super system admin. You have to read the patch notes with all of them so I thought it was normal. If you don't read the patch notes, you will end up in a world of hurt. Red Hat had some serious issues with the stupid software vendor that requires me to have Red Hat.
I'm not saying OpenBSD is perfect or even great, I just don't think it's that bad when compared to what I have to do with other servers.
Now, if you want bad patches, deal with "enterprise educational software" that requires me to run an 762 megabyte SQL file against an Oracle database then move files to specific locations.
CentOS has. RedHat is simply not free, so paid upgrades are par for the course. Any free distribution out there has free automatic updates - I think even Oracle came around.
> Mtier is free for the current version.
Yeah, for now (didn't use to be the case, might not be the case forever). Regardless, you're now trusting two entities, OpenBSD and MTier, rather than one. This second entity is not officially affiliated with OpenBSD, and they could shut down tomorrow. How do you trust someone like that with your most sensitive OS files?
I keep banging on about this, but it's the single item that prevents me from switching to OpenBSD as my "default deployed OS" for my generic web needs: the MTier situation is shady and undignified for a major project in 2016, let alone one built on security which requires trust; and my time is too valuable to waste it on reading release notes for banal patches and figure out what special-snowflake incantation I need this week. If OpenBSD does not have the capabilities to provide what MTier provides, they should broker an official agreement where MTier becomes the official channel for updates, with OpenBSD guaranteeing some quality control. If nobody wants to risk his reputation on this service, how can I ever trust it?
I haven't been screwed by MTier, but I would prefer a world where syspatch is done and working. So, I would guess the single item will fall away for you. Just a question of time I guess.
Although, if you don't read the patch notes for a lot of these OSes, you will get bitten in the butt. I got hosed by a combination of Microsoft and Oracle once. If I had read the notes I could have saved myself a weekend of WTF.
A kernel exploit executed in a Docker container would compromise all the other Docker containers on the same machine (and the machine as a whole).
SELINUX=disabledThinking 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.
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
Quicker, but not cheaper
For example, even assuming privilege escalation isn't a possibility, www-user can read /etc/passwd, getting all usernames. Containers help mitigate this.
The whole idea behind selinux is to prevent this scenario from ever happening. Apache has a policy written for it, that specifies precisely which paths and contexts apache needs <X> type of access to. If it tries to access anything outside those paths and context, the selinux module denies the attempt. It's foolproof if you use it. It's also incredibly annoying if you are on a system with selinux enabled, but aren't familiar with selinux.
seriously ?
https://selinuxproject.org/files/2008_selinux_developer_summ...
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.