[ch0ic3]

For anybody wondering about the new pinsyscalls(2) suggest having a look at https://isopenbsdsecu.re/mitigations/pinsyscall/ . To be clear: I use OpenBSD on all my external-facing systems. I trust it infinitely more than any GNU/Linux distribution (esp with the recent xz.. "issue"), but I think it's important to do your own research and see what the contrarians say from time to time.

[lenerdenator]

Would it be correct to say that OpenBSD is far more of a unified approach to kernel and userland development than GNU/Linux? As in, both ship as one unit, end-to-end, instead of interchangeable modules that make up GNU's ecosystem?

[alberth]

That's correct for all BSD's, not just OpenBSD.

BSD = kernel + userland

[beanjuiceII]

Yep you can pick from any distro you want.. freebsd openbsd netbsd pcbsd dragonflybsd etc etc etc each special petals like lisp languages or something

[lproven]

PC-BSD is long dead.

It's much simpler than you represent.

There are only 4 real trees here:

* FreeBSD

* NetBSD

* OpenBSD

* Dragonfly BSD

In very approximate order, and I suspect that there are (wild approximation) half as many users for each step down the list.

One estimate I've seen is that there are ~7K users of openBSD, in total, worldwide.

There are a few distros of FreeBSD. None of the others have distros, AFAIK. PC-BSD was a FreeBSD distro. iXsystems acquired it, turned it into TrueOS, and then killed it 4Y ago.

https://www.truenas.com/trueos-discontinuation/

[lenerdenator]

I might throw it on a VM soon.

Maybe it'll finally scratch the ultimate nerdy OS itch.

Probably not though.

[nutrie]

Having had some experience with FreeBSD, I'd pick BSD over Linux any day, the primary reason being its unique consistency, which is after a few days a breeze of fresh air even to a newbie. The vast majority of software that runs on Linux is available for BSD as well. Sadly, hardware support is not that great.

[nanolith]

This site is often fairly balanced, but I think the author often jumps to conclusions. The pinsyscall feature is one place where many security researchers have jumped to conclusions, because they only see it from their narrow x86 oriented view.

Yeah, on x86, I can craft a ROP attack that allows me to discover relocations for functions fairly trivially, especially for coarse ASLR, because I can read the text segment. But, ARM64 has execute-only support so that it's possible for code to execute, but not read, a text segment. In this situation, pinsyscall does add a valid defense in depth layer. It's still imperfect, but this does in fact raise the bar necessary to carry out a ROP attack when combined with randomized re-linking on boot ASLR. Further, once dynamic linking has occurred, the text segment for a binary is made immutable so that no mapping changes can occur, including mmap.

I think that OpenBSD still has a long way to go before all of these defenses align, but they are far less trivial than the author makes them out to be, because none of them are meant to be used alone. OpenBSD developer decisions like these can sometimes appear to be casting about randomly, because they are making small improvements instead of building toward a particular goal. Sometimes, they hit gold as with W^X, which was widely adopted. Sometimes, their ideas stink, like systrace. But, I don't think it's wise to just dismiss these ideas out of hand.

Instead, I recommend that people look to the history of OpenBSD, which has been more of an evolutionary approach to security instead of a revolutionary approach (i.e. Fuchsia). From an evolutionary perspective, pinsyscall makes sense as it is low-hanging fruit that can buy some security and can force applications to use a standard interface (libc) instead of making raw system calls. From a revolutionary perspective, pinsyscall just seems like a dead end. Revolutionary design has convergent effects -- all of the pieces come together in a perfectly engineered defensive shell. Evolutionary design has emergent effects -- fixes and features build on each other until they co-evolve into strong defenses.

[brynet]

> ARM64 has execute-only support so that it's possible for code to execute, but not read, a text segment.

OpenBSD does xonly by default on multiple architectures (arm64, risc-v, ... g5 powerpc), including even amd64 on recent Intel/AMD CPUs supporting MPK/PKU:

https://marc.info/?l=openbsd-cvs&m=167423045918820&w=2

On machines that lack hardware-enforcement, at least on CPUs that can differentiate between traps for instruction-fetch and data-fetch, there is still benefit:

https://marc.info/?l=openbsd-cvs&m=167517831914525&w=2 (msyscall(2) part is now handled by pinsyscalls in -current)

[alberth]

Since you're clearly knowledgable ...

What's your take on http://cheribsd.org (and CHERI as a concept overall)?

[nanolith]

I've been following CHERI for years. I'm a fan of runtime mitigations in hardware, better process isolation, and capability models. This couples nicely with an obsession of mine, which is the integration of formal methods into system and firmware development.

That being said, CHERI has a long way to go before it makes it to any production system. ARM Morello has certainly breathed new life into it, as has its current push toward a RISC-V ISA. Going from R&D to synthesis on production hardware is a significant leap.

It has inspired innovation in hardware much as seL4 and similar projects have inspired innovation in the formal methods field. For that, I'm grateful.

[pjmlp]

While it might have inspired innovation, there is SPARC ADI that predates it, with Apple's PAC, Microsoft's Pluton, and ARM's MTE already being deployed on some systems.

Still looking forward to CHERI ideas to go mainstream though.

Only Intel and AMD keep messing up their attempts to hardware memory tagging, for several decades now, starting with iAPX 432.

[nanolith]

At this point, I think that Intel and AMD have designed processors that are hostile toward security and process isolation. The amount of work required by an OS designer to work around the default insecure and leaky behavior of these processors is staggering. Worse, there is always the temptation to optimize performance by turning off these mitigations.

Perhaps that's why I enjoy working on microcontrollers and firmware. Yeah, there are potential CPU attacks on these, but it's much easier to manage mitigations, and these mitigations don't come with steep performance penalty trade-offs.

[pstuart]

Would the evolutionary approach be an advantage in allowing existing code bases to run with minimal modifications? So not perfect but safer than linux with minimal effort?

[nanolith]

I think that it's difficult to quantify whether X is safer than Y. Instead, we should look at what safety measures X or Y have in place, and whether these can be reasonably improved. Certainly, a single comment on a forum would do this topic a disservice.

OpenBSD has clearly been in the business of making small improvements with each release. This model has worked for them, but it has also been part of what makes them controversial. I trust OpenBSD for my personal servers and my travel laptop. I use it as a build target for my projects.

That being said, do I think that people should switch from Linux to OpenBSD? I wouldn't do this purely for security, because Linux has not been sitting still either. But, I think it's definitely a good idea to take lessons that OpenBSD has taught when configuring a Linux server: disable things you don't need, use the most aggressively secure options for services you provide, and add as much isolation between pieces that you can. Regardless of which OS you choose, you should spend time familiarizing yourself with what is required to harden the security for servers you make available with a public IP address.

OpenBSD's "secure by default" idea is great until you need to enable a service, which widens its attack surface. Doing this safely requires research and knowledge. In this way, I don't think that OpenBSD is much different than the average Linux distribution. I openly admit that I like OpenBSD, but I don't want to steer people the wrong way by claiming that they would be safer using it. In fact, blindly switching operating systems could make folks less safe, because they will probably use the new operating system incorrectly. Instead, study and experiment.

[calvinmorrison]

Do you think there's more value in combining 2 heterogenous systems (like openbsd up front, linux behind) than using one 'more secure' system throughout? I feel like the number of critical issues that have faced two systems at once is far fewer than a single system.

Also I think it shows value in having independent implementations of standards. If you have 5x different xz tools or C compilers or Javascript engines, the threat is chopped in half, plus you can easily compare reference outputs between them (RE: on trusting trust)

[ch0ic3]

For sure! An argument in OpenBSD circles is that contrary to popular belief one can have security through depth. This means that even though you'll never be 100% secure you can definitely make an attacker's job harder and their life more miserable. Of course, if the NSA wants to attack you then they'll probably succeed, but for your average script kiddy / botnet scanner / worm exploiting some vulnerability having multiple layers might be enough of a deterrent.

I'm not a security person but I also think a lot of malware damage comes from companies / users using misconfigured or outdated software. As such, if you were a sysadmin, knew what you were doing and had the time, then running GNU/Linux is probably fine, but I'm not super knowledgeable. I just want to host a website or run a tor-relay on a VPS and not have to worry about updating my system as soon as some 0-day is announced in glibc or systemd; even if it's in the service itself, my hope is that by using a non-mainstream OS the exploit might not initially target it, hence giving sufficient time to see the news somewhere and patch / update.

[wannacboatmovie]

It's common practice for the ultra paranoid to use two firewalls, from different vendors, back to back, for this reason.

[terlisimo]

There is a name for this https://en.wikipedia.org/wiki/Swiss_cheese_model

[alberth]

Does pinsyscall mean Cosmo will no longer work on OpenBSD?

https://github.com/jart/cosmopolitan