Indeed, the OpenBSD guys said early on that hyperthreading should just be disabled for security reasons. It took everyone else to catch up, but see Greg KH's comments that if users are untrusted, one should do so: https://www.youtube.com/watch?v=jI3YE3Jlgw8
> 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).
You can do that with seccomp -- each filter is run along with the others and the most restrictive return value is used by seccomp.
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).
The kernel can pull "tricks" to mitigate speculative execution during context switches. But it can't do anything to prevent a process running on one hyperthread from using side-channel attacks against another process, or the kernel, or a secure enclave, running on the other hyperthread of the same core.
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 :)
Pervasive advertising surveillance is quite a bit different from ntp queries for "what time is it?" and confirming the time with HTTPS servers.
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.
That's interesting, and I completely agree. However, my comment was about whether the default OpenBSD install sends any data to any private US companies. NTP queries are a form of data :).
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.
Good article. I would disagree with his assertion that keeping time synchronized is not a security feature; since everyone and his mother adopted TLS, it definitely is. I'd also recommend changing the title to, "What security does a default OpenBSD installation offer?" While it deviates from what the author wrote, I'm guessing English is not his first language and that is what he intended, and it makes it clearer for readers.
As an aside, he mentions encrypted swap. Can any OpenBSD users comment on how that affects performance?
I have FDE enabled on a laptop with an m.2 ssd, and I don't notice much (if any) slowness compared to an unencrypted install. but since the m.2 ssd's are so fast, YMMV on other media types.
modern high class SSDs have a hardware encryption chip, sort of like Intel's AES-NI for CPUs, which greatly reduces the burden on the CPU. you only really notice a difference when accessing larger files and the SSD's internal buffer fills up and offloads
These rely on the vendors secret sauce and an analysis years back found these frequently horribly broken like my password is password levels of broken.
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.
To be clear the parent post and mine were discussing self encrypting drives. Drives which handle the encryption and decryption on drive instead of relying on your CPU. This is what is insecure.
Most of those are black boxes. If you have a compliance requirement for encryption, your hardware crypto probably doesn’t meet it.
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.
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.
She's French, I believe. I don't know how to easily/accurately measure the I/O performance of the encrypted swap in itself, but if it's to any value I do run OpenBSD with FDE (full-disk encryption) on an old mechanical 2.5" drive, on a somewhat modern low-power Celeron setup, and I see around 45-50 MB/s transfer speeds for both reads and writes. I don't know what the same setup and drive reaches without FDE.
I think someone said it costs +50% in time to swap out pages when it was enabled, but as soon as you are swapping, such timings have very little bearing on your experience, since any time a program have to wait for a page to get in from a disk, the process is already running 1000x slower than it should.
I'm old enough to remember back in 2002, Openbsd.org had a banner:
"Five years without a remote hole in the default install!"
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.
Are remote exploits in minimal server installs particularly common? Like for any OS? Feels like probably not very. I can think of one off the top of my head in 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.
Windows is sort of an easy one since it's hardly a minimal server OS, but idk, even then, post-Windows7 I imagine things started getting far less common.
OpenBSD's claim is fine and all it's just not all that important. No one just ships OpenBSD without adding something to it.
This was even the case with Windows 2000 and XP at some point. Installing a default 2000 or XP without any updates and then using Windows Update was a no-no as you'd have malware before you could install the updates.
Kids these days. Default redhat installs used to run more services than you could count. There were extensive post install howtos to guide you through turning it all back off.
Redhat used to ship running pop2, pop3 and imapd running by default, all open. Windows was SO exploitable that ISPs to this day block 137-139 and 445 just so people do not get hacked immediately.
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.
Well, do ISPs suddenly allow 137-139,445 nowadays or is this still considered to be a hole wide enough for a truck to drive through?
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.
137-139 was originally about the old lanman broadcast stuff more than "security". They did not want your "network neighborhood" to be populated with your actual neighbors because that's creepy. I assume MS fixed this at some point, and I also assume ISPs will never change this.
> Are remote exploits in minimal server installs particularly common?
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.
The reason why it's so controversial is because OpenBSD doesn't actually enable any services by default except for ssh, IIRC.
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.
It is "secure by default" but I find that phrase disingenuous when the "default" doesn't really do anything. Sure, it's secure, but that doesn't help me much if I have to immediately make changes that could instantly make it insecure.
"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".
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.
> Basically anything that you would want a computer to do.
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.
but most linux distributions also don't start a lot of network services.
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.
> 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.
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.
OpenBSD's "secure by default" slogan dates back to the days when you could install Windows NT/2000 or RedHat Linux or whatever UNIX from the CD-ROM, and end up with several very optional "exploitable by default" services running in the background.
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.
By that logic all software is 100% "secure by default" - if I don’t choose to add my own electricity into the equation, then there are no bugs in the running software at all, because no software is running :D
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.
> OpenBSD doing NOTHING by default is exactly what I want.
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."
Yes, that is "secure by default". It's a very reasonable claim to make.
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).
Any OS that shipped OpenSSH earlier than June 2002 could get infected within minutes of being connected to the network, which is basically a set of all Linuxes or their parents.
As you enable each thing, you have to think about it. Maybe you don't really need it. You probably won't configure whatever as wide open as most vendors do for ease-of-use, but consider your own use case.
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.
The fact they don't enable services isn't what is controversial, it's the claim that they have "no remote bugs in a heck of a long time" on an install that doesn't enable anything. OpenBSD has shipped several vulnerabilities in other network services included in base, including some which would be commonly enabled like FTP and HTTP daemons.
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.
There was an interesting talk by Ilja van Sprundel during 34C3 back in 2017 called "Are all BSDs created equally? - A survey of BSD kernel vulnerabilities" [1] where a comparison is done between NetBSD/OpenBSD/FreeBSD.
I tried setting it up a few times and gave up after having to swap hard drives twice for BIOS to load (?!). Maybe I will try again after reading these. Thanks! I also ran FreeBSD for some time but I couldn't get graphics to work right on my OPTIMUS laptop.
Depends on your usage. The biggest problem for me is the lack of Widevine and inability to play DRM media. There are also some other things that aren't easily available such as Docker or Vagrant; I don't really use these things myself, but sometimes it's handy to be able to run them for various reasons from time to time (for example I've seen projects where the test suite assumes Docker availability, and replicating that outside of Docker for just one patch isn't really a good time investment: easier to just run Docker).
It's quite doable, but it does have a tendency to require more tinkering than your average Linux desktop, and it does set some specific requirements in regards to hardware.
If you have some spare time and a spare laptop, I say go for it.
I don't know if Teamviewer or Anydesk support *BSD, but you can always use xpra - though they say "All BSD variants should work, but are not regularly tested." so you might find a couple hiccups maybe.
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.
I disagree about the tinkering, I've found it very straightforward to get a decent desktop experience. The only drawback is that it's perceptibly slower than Linux.
Your mileage may vary, depending on what you compare with. It's definitely not hard, but setting up OpenBSD does require more work compared to setting up something like Ubuntu or Linux Mint.
That very much depends on what you do. All the basics is not an issue, web browsing, email and so on is perfectly fine.
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.
> 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.
I still can’t believe I was lucky enough to not only grow up with the Internet, but also GNU and Linux and BSD existing as two very independent and thriving projects as OpenBSD and FreeBSD.
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?
91 comments
[ 3.5 ms ] story [ 161 ms ] threadThis 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 :)
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.
https://man.openbsd.org/ntpd.conf.5
https://github.com/openbsd/src/blob/master/etc/ntpd.conf
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.
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.
This was changed September 2019, when Microsoft pushed an update that defaults Bitlocker to software encryption.
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.
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.
"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.
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.
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
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.
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.
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.
Adding 3rd party packages sure: you’ve left “default” behind, but ones installed by the OS? They count imho
"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".
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 might not seem like a huge claim now, but it was actually extremely influential and operating systems now ship with inessential services turned off.
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.
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).
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.
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.
https://qubes-os.org
Edit: They have fixed it, and it now uses ChaCha20 (but is still called "arc4random"). https://en.wikipedia.org/wiki//dev/random#OpenBSD
[1]: https://media.ccc.de/v/34c3-8968-are_all_bsds_created_equall...
This blog was useful for me: https://www.c0ffee.net/blog/openbsd-on-a-laptop/#multimedia
and https://www.openbsd.org/faq/
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.
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.
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?