What security does a default OpenBSD installation offer?
dataswamp.org
dataswamp.org
Then, later that year OpenSSH had a critical, remotely exploitable vulnerability that allowed an attacker to gain remote root access. They changed the banner to: "One remote hole in the default install, in nearly 6 years!"
It stayed that way almost 5 more years when in 2007 a flaw in IPv6 was discovered that resulted in a kernel-level buffer overflow, and the banner was updated to: "Only two remote holes in the default install, in a heck of a long time!"
At some point, that slogan was removed, probably because of the fierce criticism and debate it sparked. Even still, OpenBSD pretty much designed the idea of "secure by default" and still to this day, probably lead all modern software OS in this ideology.
I can't think of any other major software distribution where I can count exploits on a single hand after many, many years.
Which means that the attack surface for OpenBSD is just their TCP/IP stack and SSH. The slogan, while technically correct, sounds like (and dare I say, is often taken as) saying that there have been no security bugs/network RCE bugs in OpenBSD. OpenBSD has shipped with many RCE vulnerabilities over the years (in its included FTP and HTTP servers, for example). Simply in services not enabled by default. Because none of them are enabled by default.
I'm not particularly impressed by OpenBSD in this particular regard because if you want to do something with your computer, you will eventually end up needing to enable services, some of which have had bugs shipped with OpenBSD. And once you install 3rd party software, all bets are off.
One thing OpenBSD has focused on recently I am a huge fan of is their documentation and focus on making consistent and easy to read and write config files. That is a huge bonus to security IMO. Making it easier to learn how and to write configs makes the chances of misconfiguring a server much lower, which is more often the bigger security risk.
I mean, historically, some OSes might as well have had the slogan "insecure by default", like Windows XP before service pack 2. Just enable everything and make it wide open. In that era, Linux distributions weren't much different. Possibly, OpenBSD moved the needle in the right direction on that sort of thinking.
Sounds reasonable. Why is it controversial? Enabling stuff by default is not only in bad taste, it is also insecure.
Many Linux distros also don't enable services at boot, and use OpenBSD's SSH client/server. They would essentially be just "as secure" out of the box as OpenBSD is, with the exception of RCE vulnerabilities in the TCP/IP stack of Linux itself, which are about as uncommon as those in OpenBSD itself.
Giving you a minimal install base is a nice touch, and I greatly prefer it myself. I do not see it as a great security feature, however, since almost (not all, but almost) everyone will immediately install or configure additional services.
OS security should be about mitigating exploits and protecting that other software you're running. OpenBSD does do other things to increase security. I just think their tagline is a touch deceptive.
"Secure by default" would be most meaningful IMO when describing a "fat" OS with services and such already enabled, and configured securely.
OpenBSD's "secure by default" is nice and useful so far as you can trust it's extremely unlikely someone will be able to nail you with a 0-day when you're doing your OS install and early setup, but that's the biggest part of that.
Not to say OpenBSD doesn't do other secure things. I'm just not impressed by their claim of "secure by default".
It might not seem like a huge claim now, but it was actually extremely influential and operating systems now ship with inessential services turned off.
This is an unbelievably absurd statement. What do you mean it doesn't """do""" anything? I can boot up my openBSD desktop machine and write computer software, edit graphics, play media files, etc. Basically anything that you would want a computer to do.
Before that computer starts interacting with other computers over the network however, I generally have to ask it to. That's GOOD.
Some people will be okay playing uncompressed WAV and Sun AU files cat'ed to the audio device. Other people are going to want to play other audio formats.
This kind of reasoning is a bit reductionist. Sure, as long as my computer has a compiler and basic interfaces, I can "do anything that you would want a computer to do", given <x> amount of work on my part to re-implement the functionality I want.
Unless I want to write my own MP3 decoder, though, I'll need to install 3rd party software from ports.
> Before that computer starts interacting with other computers over the network however, I generally have to ask it to. That's GOOD.
Right, it is -- but most linux distributions also don't start a lot of network services. Linux has had a few more TCP/IP stack vulnerabilities than OpenBSD, but not many. And of course (mostly) Linux distros uses OpenBSD's SSH package.
Your empty Linux install and empty OpenBSD install will, from the network, appear mostly identical. And the bug in Firefox that pops a shell on your system likely won't be either Linux or OpenBSD's fault, but Firefox's.
While that is mostly true today, it certainly didn't used to be. Back when OpenBSD was really earning its security reputation, a default install of Red Hat would be rooted almost as soon as you connected it to the internet.
But if mg has a bug allowing malicious files to run code, then this won't increment the"remote holes in the default install"-claim, just to name an example.
If I go to the CVE database and search for "Windows 10" or "FreeBSD" then I might find 200 security holes of varying severity, and people will say "Windows 10 has had 200 security problems" Not all those problems will affect everyone, but this is the common-sense way most people would understand it.
But OpenBSD has a subtly different definition, and I think this subtly distinction is lost on many. I have nothing against OpenBSD and generally like it, but I always found this claim to be a bit misleading (even though it's technically correct). It's not a meaningless metric though; I remember installing Windows 2000 back in the day and it had malware before I could install the updates. But it is a very incomplete one.
It’s technically correct, but a meaningless metric :P
OpenBSD doing NOTHING by default is exactly what I want. Somebody said that sshd starts by default, but actually it doesn't unless you specify that you want it to during installation.
When you finish an openBSD installation, you are presented with a fully functioning system that will boot up to a shell, which has a networking stack available, and will allow you to then install the things you want.
That's what I want a computer to do. I don't want it to start up the kitchen sink unless I ask it to.
True, but that does not have anything to do with the metric.
For example, see https://xkcd.com/641/ . Cereal being asbestos-free is definitely a good thing and "exactly what I want". Yet, people will complain about that advertisement.
Or "No vulnerabilities in the webservers turned on by default^1. Also, all default-enabled webservers are giraffes."
1: There are none, so this is true.
Adding 3rd party packages sure: you’ve left “default” behind, but ones installed by the OS? They count imho
This was a contrast to a fresh install of Windows which would get infected within minutes of being connected to the network (I'm assuming this is no longer true, but have never used windows).
But like, let's imagine a minimal Linux server install, not even something hardened - I feel like there probably aren't too many RCEs in there. Even fewer that are legitimately exploitable with a bit of work to harden.
It's not really to diss OpenBSD so much as to say that, yes, a lack of RCE in a default install is cool, but you also have to wonder what anyone is doing with a default install, and if that's really something you should care much about.
Par for the course was to get owned within hours (or minutes) if you were on the net, that was the context where not-getting-random-remote-admins was a differentiating factor.
If those are still blocked, then the major OS in this world still proves that there are bad defaults and good defaults, one which leads to compromise and one that leaves you secure until you screw up in some other way.
If other OSes have "caught up" with not starting and exposing lots of random* daemons just because they exist on disk on a default install, then that is for the better of the world. That doesn't take away the idea that some OSs did it long before others, and hence have given their users a safer experience for a longer time.
*) random in the sense that "running a pop2 daemon when your box wasn't even intended to be a mail server" is beyond silly. Same for httpd, ftpd, ntpd-claiming-to-be-stratum-1-on-motherboard-clock (happened) and all other services a full default installation might provide.
OpenBSD's claim is fine and all it's just not all that important. No one just ships OpenBSD without adding something to it.
OpenBSD ships X and a window manager in the base system
Extremely common, windows was infamous for this.
You couldn't do a fresh install of the OS and patch it because by the time you downloaded the patch it had already been rooted just by being on the network.
"Only two remote holes in the default install, in a heck of a long time!"
My old greybeard eyes completely missed the red text, centered right under the top banner.
Unisys marketing? Safer than any UNIX you want to trust your government most valuable documents.
Or closer to home, DoD security assessment of Multics and PL/I language features that prevented exploits similar to UNIX systems.
Everyone has an opinion. This presenter claimed Windows is the most secure (for his particular use case: "COMSEC").
If you care about security today you should consider Qubes OS instead. It provides security through isolation. Snowden uses it.
[1]: https://media.ccc.de/v/34c3-8968-are_all_bsds_created_equall...
edit: looks like it only queries cloudflare.
Having multiple sources improves NTP and prevents a single distorted source from breaking things, and large companies have good security reasons to tell the truth about the time.
Also, if it ever became profitable for some reason to give incorrect NTP results, then I doubt Google et al would continue to do so.
It uses TLS timestamps to constrain the possible time values. This prevents spoofed NTP packets from changing the time.
Many sub-projects forks and derivations have come and gone over the years. Long may they continue.
It actually brings into highlight though that despite the fecundity of OSs, we only have one Internet (unless you count v6 as separate?).
In another timeline, just as GNU and BSD coexisted, perhaps there was also an Internet and alongside it a parallel and equally thriving online network... Transcom? Worldmesh? Digizone?
This sounds very nice, is there anything similar on Linux?
> SMT disabled
Well, this is one way to deal with spectre and friends.
> This sounds very nice, is there anything similar on Linux?
Seccomp is the closest thing we have to pledge, and it is used by some programs to restrict the set of operations they can do (but the most common use of seccomp profiles is containers -- pretty much all container runtimes apply a default seccomp profile to reduce kernel attack surface reachable by containers).
As for unveil, you could implement it with mount namespaces (or an LSM like AppArmor -- which isn't actually that hard to set up, but unprivileged users may have to go through extra hoops) but most programs don't do that themselves.
But in short, not really. Most security mechanisms in Linux are intended to be managed by administrators or system services rather than the program itself (with some exceptions, but even those exceptions end up being managed by system services in practice).
If a program in a seccomp sandbox couldn't add a new secxokp filter to itself, you wouldn't be able to run programs like OpenSSH inside containers (which you can).
Aren't these caused by speculative execution? How does turning off hyperthreading help there?
That's right, if you don't have hyperthreading disabled right now, you are technically vulnerable. All the major players have decided that it's not worth the performance cost (or maybe just the feeling of loss of giving up that hyperthreading) for such a niche, difficult-to-exploit vulnerability.
A popular idea is to only allow threads of the same process to run on hyperthreads of the same core (or of processes in the same "security domain"). Patches to do this for linux have been floating around for about 2 years, they might have been merged recently, I'm not sure. But the performance cost of the logic that enforces this is greater than the performance benefit of hyperthreading in most cases.
IMHO either give up hyperthreading, or give up security against the "MDS" vulnerabilities. I leave it enabled for my gaming system, I think there are bigger problems if attackers have local execution on my system ;)
> IMHO either give up hyperthreading, or give up security against the "MDS" vulnerabilities. I leave it enabled for my gaming system, I think there are bigger problems if attackers have local execution on my system ;)
I made a similar tradeoff for my non-critical systems. But maybe that's a reason to not pay the extra for a HT CPU for my servers :)
All of the development tools I need are in the ports tree, but it may depend on the languages you want. There's currently no .Net port for instance. If you want to do 3D animation or AI related work, then you're going to have a bad time.
I found OpenBSD to be a slower than Linux, but on modern hardware, that might not be as much of an issue as on my crappy old laptop.
In my experience over the years, this is a bit of a reverse bell curve. For very very old hardware (Pentium III era and first/second gen Intel Atom machines) OpenBSD is actually faster than Linux. I currently have a Atom N450 based netbook and OpenBSD is the only OS that is usable on it, even including its originally shipped Windows 7.
Anything from the early Core2 days up through the second and third generation Core i-series (Sandy Bridge/Ivy Bridge) tends to run much slower in OpenBSD vs Linux. After that, the curve swings upward again; I've noticed practically no difference in day to day tasks between the two OSes on modern (Skylake+ and AMD Ryzen) hardware, to the point that running Xfce on both OSes on a Ryzen 5 3600 based system were pretty much indistinguishable.
Of course there are obvious outliers; some tasks are heavily driver dependent and OpenBSD's drivers always lag behind Linux and Windows as there is no commercial interest in OpenBSD as a major OS.
This blog was useful for me: https://www.c0ffee.net/blog/openbsd-on-a-laptop/#multimedia
If you have some spare time and a spare laptop, I say go for it.
I've found xpra --shadow to be almost on par with Anydesk on Linux - even passing through an ssh proxy. But obviously that might depend on GPU encoding which might not always be available on BSD.
As an aside, he mentions encrypted swap. Can any OpenBSD users comment on how that affects performance?
https://www.tomshardware.com/news/bitlocker-encrypts-self-en...
Bitlocker by default on windows will happily depend on these broken implications in favor of actually secure options that are now and for years specifically accelerated by your cpu.
They are also potentially worthless at protecting data in suspended laptops which for some is a machines condition 99% of the time when it is apt to be lost or stolen.
This was changed September 2019, when Microsoft pushed an update that defaults Bitlocker to software encryption.
https://www.tomshardware.com/news/crucial-samsung-ssd-encryp...
https://ciso.uw.edu/2018/11/16/bitlocker-ineffective-on-self...
https://borncity.com/win/2018/11/06/ssd-vulnerability-breaks...
Self encrypting drives are have been insecure for years.
For modern devices, there is no performance impact from software FDE. To be meaningful, you need to have specific configurations in place as well as appropriate handling. If you’re not doing that, don’t bother.
Ha! https://blog.cloudflare.com/speeding-up-linux-disk-encryptio...
At least since october last year the story around dm-crypt seems to have changed with their patches. I dropped FDE last year in spring after a tormented year of often caused ui freezes. With an SSD mind you.
I just think that in this particular case dm-crypt devs don't actually encrypt their drives and haven't experienced the degraded performance.
Otherwise, I'd agree with you. Had no problem with FDE and my smartphone.
Edit: They have fixed it, and it now uses ChaCha20 (but is still called "arc4random"). https://en.wikipedia.org/wiki//dev/random#OpenBSD