is adding guided encrypted root to their installer. 
. An Orange Site user asks if their security is any better than Linux 
my take on the OpenBSD question
I personally like OpenBSD because it runs on a lot of obscure hardware. I posted that extremely weird Chinese MIPS laptop (yes, not x86 or ARM, Intel or AMD - see this thread https://rdrama.net/h/slackernews/post/137520/homegrown-chink-laptop-marseyjewoftheorientnot-intel-or) and OpenBSD supports it entirely, the last remaining OS to do so. However, most of the OS itself is pretty meh. The filesystem situation is godawful and performance is balls on top of a lack of hardware support. The upgrade path is weird for anything but a server you’ll keep an eye on every six months (never got the obsession with “OpenBSD routers”). And I really don’t find the security posture to be anything but posturing - https://isopenbsdsecu.re/ is biased and troll-y but the info is good.
the drama
Good question: Is OpenBSD more secure than a mainstream Linux distribution, notably Debian, in their default configurations?
The code is less, but there are fewer developers too. For example, basic support for disk encryption (an important security feature) has been added to the installer in 2023 in OpenBSD.
Perhaps people familiar with the software development process in both could chime in.
Questioning OpenBSD’s security approach is bound to get bites.
Yes and No. Both modern Linux and OpenBSD have their pros and cons. For example, security works better in the onion layers, which can increase complexity. With Linux, you get a modern stack such as Linux containers or ZFS if you want those excellent filesystem features. Are you using containers for development and deploying apps? Using Linux would simplify the process (of course, you can set Linux VM under OpenBSD and run Docker). On the other hand, OpenBSD is a compact OS. Less code == fewer bugs (at least in theory). Some of their code, such as OpenSSH, is wildly used by Linux, Windows, and major IT vendors in their devices. OpenBSD devs do write reliable code. In short, use whatever gets your work done quickly, which also keeps you or your devs/users happy. That is all matter. Apart from that, it would be best if you took all other precautions to secure your OS, such as regularly applying patches, and firewalls, installing adblocker, not downloading unwanted stuff and clicking on the links, regardless of whether it is Win11, macOS, Debian/Ubuntu Linux, or OpenBSD.
Dude uses a lot of words not to say much or answer the question.
OpenBSD's default configuration has basically nothing running. Once you actually set it up for a use case, it isn't much better (you'll likely be running software you would on Linux that wasn't audited) and might even be worse given it lacks a lot of security features Linux has (meaning you have less control over how to lock down things in the case of a hack).
This is probably the biggest thing with openbsd that’s posturing -
Nothing besides the base system has security guarantees.
The second you install something with pkg_add you’re no longer running a “zero holes” system. Is it still cool the base system is designed with security in mind? Kind of. Is it really useful? Not particularly. Usually you have an OS to run other applications.
False. OpenBSD's daemons are patched, sandboxed and reviewed and lots of software it's compiled with secure CFLAGS and LDFLAGS among some tweaks for browsers with pledge and unveil.
It's not false. No significant services are running by default, and for it to do anything useful you have to install and/or enable whatever services you want. Semantics doesn't change that.
Again the dude is right. There’s some security shit they add but it’s mostly security theatre imo.
Linux has a richer set of security features available than OpenBSD, in some areas.
One is the mandatory access control of SELinux, used extensively in Android (probably the most widely-used Linux distribution of them all). This has no OpenBSD equivalent, as far as I know.
Another is that the Linux kernel has some compiled-in exploit mitigations enabled that OpenBSD doesn't, such as automatic bounds checks on fixed-size array access (based on UBSan).
That's not true. There is pledge(2) and unveil(2) (just to start) and the whole point of them is to make it usable. Some Linux distros have a basic config for SELinux, but if you need to change it for anything, it's so difficult that most people just end up disabling it, thus making it less secure than a default OpenBSD install.
Besides this, it changes the perspective of who is the best person to configure the secure features. OpenBSD makes this a decision for the developer of the application, who should know better about it than a random sysadmin who most probably won't even open the source code to know better (this is the approach SELinux takes).
pledge and unveil are not even close to being full alternatives to something like SELinux.
It’s pretty common in the *BSD space to come up with a couple good ideas and then beat them to death as though Linux doesn’t have a similar method or an older one that was invented first. 
…
Your comment is clearly sarcastic in tone, yet since the words are mostly truthful, I'll take your apology, and hope you actually learned something from this encounter, although it seems unlikely.
Best of luck to you.
New snappy quote? I saw this down thread and it’s very funny.
There’s plenty more seethe in the thread, including someone saying the OpenBSD community is very mean (they are).
Jump in the discussion.
No email address required.
The more pertinent and practical way to handle security is just to use simple daemons with well audited codebases as much as possible. That is basically the argument of OpenBSD, whereas the Linux argument is burying insecure software under layers of security.
Jump in the discussion.
No email address required.
But like…there’s only a couple daemons.
There’s not even a db in base.
Jump in the discussion.
No email address required.
Yeah, I'm not even arguing that either :) I'm arguing that rather than say, doing a LAMP stack with a standard config, the OpenBSD way is to go through and customize everything and also to skip kitchen sink applications like Apache or MySQL.
Jump in the discussion.
No email address required.
Rolling your own SQL server as a backend to openbsd
httpdwould be more secure than a LAMP stack on, say, RHEL you think?Jump in the discussion.
No email address required.
Or just using SQLite which has no network awareness with a dedicated _sqlite user :)
Or you know, just disabling network capability and running with least privilege on any of the rdbms systems
Jump in the discussion.
No email address required.
I do like the popularity of SQLite increasing but I’m not sure it’s a great fit for a lot of applications.
Granted OpenBSD isn’t know for it performance either.
Jump in the discussion.
No email address required.
For sure. I mostly do SQL server at job because Indians and Windows go together like lamb and Rogan Josh.
Jump in the discussion.
No email address required.
Oh in that case I can understand appreciating the simplicity of OpenBSD.
Jump in the discussion.
No email address required.
Even when I get to touch the Linux I don't like. There is no separation of package from base, so you hit apt -y upgrade and oh no! I uninstall glibc because package manager don't know what it doing fricking panchod debian!!!
Jump in the discussion.
No email address required.
More options
Context
More options
Context
More options
Context
More options
Context
More options
Context
More options
Context
More options
Context
More options
Context
This isn't a good argument imo, since you can have the best software in the world but still all it takes is one exploit and you get pwned. That isn't to say audited codebases are useless, for high security applications it should be done as much as possible. But even though it's a lot less "pure", the linux approach is better because it's progressively less likely the attacker will be able to chain together exploits to escape layers of isolation the more such layers there are. Qubes is even better since it stacks requiring the attacker to have a VM escape handy on top of other security measures. OpenBSD security is meme tier in comparison.
Jump in the discussion.
No email address required.
And ultimately you can bury all of that under that but all it takes is flaws in the hardware like meltdown to cause serious damage to applications.
I'm not arguing that openBSD is the best at security because I don't actually use it. I'm not system administrating outside of my work. I am saying that the Linux approach is not going to work because attempting to bury insecure problems is stupid. You might see it as good security practices but I just see it as adding multiple points of failure. It's like doing an evaluation on a building and seeing that one of the major support structures is cracked. Rather than replace it or as rebuild the structure you just stack bandaid fixes until you think that it's not going to fail because it can't possibly rip off 100 fixes at once. I'm sorry to tell you but in basically any other industry that's not acceptable practice.
Jump in the discussion.
No email address required.
It's not adding multiple points of failure; the entire point is that the attacker must chain together an exploit for EACH layer of security they are subjected to. On a Qubes OS system that might entail something like pdf reader exploit -> AppArmor escape -> Xen hypervisor escape -> ssh keys stolen. Having all three of those work against the target seems quite unlikely! But on OpenBSD, once they exploit the pdf reader ~/.ssh is theirs for the taking. It's just never going to be as secure.
And for the record, I don't think this is the best approach. I think there should be a bigger effort towards formal verification of normal software (no, rust doesn't count) so that it can be made impossible to pwn the pdf reader in the first place. But we live in a time period where almost all software is insecure so the only way forward is multiple layers of defense.
Jump in the discussion.
No email address required.
More options
Context
More options
Context
More options
Context
More options
Context