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
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.
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.
> 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.
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)
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.
While SELinux enabled distros usually comes with a targeted mode by default Gentoo hardened has strict mode in it's policy rules, everything is confined with that policy.
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.
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.
"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."
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).
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.
>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
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.
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:
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.
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.
I'm not sure that containers will help with security profiles. They should help with (for example) privilege escalation, but you will still be left with managing what systems/programs need access to what resources.
While containers can't help against privilege escalation, they help against information leakage.
For example, even assuming privilege escalation isn't a possibility, www-user can read /etc/passwd, getting all usernames. Containers help mitigate this.
If your www-user can read /etc/passwd without 'avc: denied' appearing in your selinux log, you are doing it wrong.
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.
There has been no shortage of ways to escape Docker containers. If you want to lock down applications, SELinux will be much more useful, even if far from perfect.
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.
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.
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.
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.
ACLs are a terribly complex mechanism that would require a lot of new code added to the kernel
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...")
You do know that OpenBSD just recently introduced a hypervisor, right?
(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.)
Correct. Currently it can only run OpenBSD guests, and it only supports x86.
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.
Wasn't TdR statement before hardware virtualization on x86 became commonplace? Before AMD-V / Intel VT x86 virtualization worked through bizarrely complex techniques (binary translation...)
He said that in ~2007? So that may be correct. x86 hardware virtualization has gone through several generations so his comments may have remained accurate even as hardware features were added.
Hardware-assisted virtualization really took off in ~2008, but they've continued to add features over the past decade.
I was very fond of OpenBSD 20 years ago when I ran it (still have the t-shirt). It had a simple elegance that struck a chord with me. I haven't looked at it in a long time, the last time I looked it didn't support VMs at all and didn't plan to which was a deal breaker ;/
GrSecurity has more kernel-level protection features, I think. If I wanted to argue that OpenBSD is more secure than e.g. Ubuntu with GrSecurity, I'd focus on OpenBSD's hardening/security-conscious design throughout the system. (ETA:) GrSecurity gives you great anti-exploit technology, but having fewer total bugs also helps.
(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, ...)
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
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.
It was straight-forward on the first system to use it: STOP OS on SCOMP & XTS-400. The STOP OS broke OS into various components layered by how privileged they were into four rings with user-mode software on lowest layer. Then, the ring protection by itself prevents (a) writes by untrusted programs to trusted programs' data or code spaces; (b) reads of secrets from privileged programs by untrusted programs. Anything security-critical is mediated by security kernel that is formally specified, verified, analyzed, tested, and pentested against a clear, security policy.
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.
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.
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.
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.
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.
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.
> 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.
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."
> 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.
"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:
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.
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.
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. ;)
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.
It's not that bad once you have it set up. PaX causes most issues.
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.
I do manual upgrades on my machines because I only have a few and they're different enough that automation wouldn't help, buuuut... You can use release(8) and autoinstall(8) with pxe to deploy create and deploy OpenBSD upgrades/installs. In between releases, you can follow the -stable branch of the ports tree and use dpb(1) to generate updated binary packages, which all your machines can then install.
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.
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.
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.
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.
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.
How does that matter? Fact is you move from 5.7 to 5.8 and boom, no sudo. Check the release notes, and yeah, it's replaced with Ted's little side project. In 5.9 release notes it's "a little friendlier to use". Not as friendly as sudo, but ok, thanks, I guess?
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.
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.
> 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.
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?
Yeah, try to use CentOS when a vendor specifies Red Hat (all sorts of hell). So, I pay Red Hat. I did have a vendor that we didn't go with that specified Fedora but not Red Hat. The world is a bit weird, and I have no clue why that would make sense.
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.
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:
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:
It wasn't? Then why did they? As I've repeatedly reminded, sudo is in ports.
I thought credential caching was left out because it was another unnecessary bloated feature creep and doas is supposed to be minimal and more secure. Apparently people couldn't live without it, and it's added in three releases later.
If you followed development, sudo in OpenBSD was maintained by Todd C. Miller, the same person who maintains the sudo.ws version. The version in OpenBSD was years behind and had many features stripped out or disabled. It was a maintenance burden and people wanted the upstream version in ports to get features like plugins, LDAP, etc.
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