KernelTrap offers a summary of a lengthy debate on OpenBSD’s -misc mailing list comparing the security features built into OpenBSD versus the security offered by the Linux kernel’s SELinux feature. The main arguments presented against SELinux centered around its complexity and the difficulty of defining a secure policy. “The first thing people usually do with SELinux is turn it off”, suggests the article, noting that the ease with which it can be turned off is another security shortcoming. By contrast, OpenBSD offers numerous security features that are always enabled with minimal overhead, including propolice stack protection, random library mappings, proactive privilege separation, W^X, and systrace.
Since when is the ability to easily turn off the security system a bad thing? It can only be done by root and requires a reboot. That doesnt make it any less secure, just less of a hassle to those that dont need it on.
Correct me if I am wrong, but you are referring to this:
It was pointed out again that SELinux is part of the 2.6 kernel via LSM, to which Jason Dixon noted, “SELinux is a button. Buttons are easy to turn off. Darrin went on to say, “compare that to a complete operating system (OpenBSD) where security is part of code quality, and part of the normal mainline development.”
I don’t think the point is that it can be turned off easily. In the full context of the statement, I think what he is getting at is that you can’t just “turn off” a securely designed operating system (where ‘securely designed’ includes extensive code auditing).
To put it another way, here’s a hypothetical scenario:
Sysadmin A receives his RHEL box with selinux policies enabled, but with little else done to harden the box. After becoming baffled by selinux, he shuts it off.
Sysadmin B receives his OpenBSD box, which is already relatively secure following a default install. He does not have a simple option to “shut off” secure design and code auditing. (i.e. There is no turnoffsecuredesign=1 option to pass to the kernel.)
Given that neither is particularly wise in the ways of *nix hardening, which Sysadmin is likely to now have a less secure box?
————————–
edit: For the record I don’t intend to turn this into another useless flame fest. I use/like both GNU/Linux and BSD (FBSD to be exact).
Just wanted to clarify what I felt was a misunderstanding by the first poster.
Edited 2007-09-26 20:07
Well they try to say that Linux doesn’t have anything comparable. If you want to pit obsd vs the only distro that really ships SELinux by default (RHEL/Fedora), you will see that isn’t the only security feature.
Things like hardened compiler toolchains, c libraries, Exec-shield which is very similar to Obsd’s W^X, auditing, etc… Make it pretty decent actually.
http://fedoraproject.org/wiki/Security/Features Take out SELinux from this list and you still have a pretty secure system.
You don’t see OpenBSD getting certified as common criteria EAL4+ with LSPP now do you? The LSPP is only possible with a MAC solution such as SELinux, but you don’t see Obsd getting certified even EAL4.
Maybe that’s because the OpenBSD team doesnt care about being EAL certified and havent submitted to it. In fact, I dont know anyone who cares about EAL.
http://en.wikipedia.org/wiki/Evaluation_Assurance_Level
So, much like being ISO900x certified, it doesnt really mean jack.
LSPP means you have Mandatory Access Control that controlls security through Labels. Hence “Layered Security Protection Profile”. OBSD doesn’t have anything close whether they want to flame it or not.
It is a security feature they lack.
There’s actually a missing case here:
Case 1: The unexperienced Sysadmin doesn’t need to do something “non-standard”. In this case, Sysadmin A wouldn’t have an SELinux problems (unless it’s a RedHat bug) so turning off SELinux wouldn’t happen. So Sysadmin A and Sysadmin B likely have equivalent security (I’m making the assumption that OpenBSD code audits are as flawless as SELinux, which doesn’t seem to have any data to support or refute).
Case 2: The unexperienced Sysadmin wants to do something “non-standard”. In this case, Sysadmin A would turn off SELinux (more likely use permissive mode) and default to regular Unix security plus other GCC and kernel security features. In OpenBSD’s case, non-standard means that it isn’t audited as well (e.g. there’s no way the can audit something as big as OpenOffice or the complete GNOME or KDE desktop with any real rigor) so it would default to regular Unix security plus other GCC and kernel security features which also exist in Fedora.
In short, there’s really no difference (at least none backed up by concrete data that I’m aware of).
SELinux reminds me a lot about Internet Explorer Enhanced Security. Basically, Microsoft creates a technology that is completely unusable and then follows it up with an easy way to uninstall it. It is in this context that “options” are bad. If you are going to make something an option, please really make it an option. And for the majority of users, using SELinux is not an option.
That’s very true but I don’t think that SELinux was ever meant to be used by the vast majority of users.
Basically, the whole framework seems like it’s intended for mission critical and/or potentially vulnerable systems, i.e. web and FTP systems. It also seems mostly intended for server systems as the complexity of SELinux does not easily lend itself to desktop tasks, at least not yet.
Sure, it would make for a safer internet if every system on the planet had a similar framework with sane defaults but in reality, the usability trade off would end up hindering people from doing there work more than it would help.
I think that, for a desktop system, AppArmor is probably a better choice, at least for the time being.
May I ask, when was the last time you used an SELinux-enabled distribution?
All my machines run Fedora (development), CentOS5 (testing) or RHEL5 (production) and all are SELinux enabled.
Contrary to what you say, unlike Microsoft, RedHat has a huge array of CLI and GUI SELinux management tools that make using SELinux far less complicated then it used to be. (Back when Fedora started shipping with SELinux enabled)
Yes, SELinux does require some manual intervention from time to time, but by design, a secure platform can never be fully automatic. (Mostly because the same automation that’s being used by the user to open up SELinux or a firewall port can also be used by worm/virus/root-kit/etc)
– Gilboa
Edited 2007-09-27 05:09
I think the argument being made by the writer of the article is that SELinux isn’t an after thought, rather than a native ‘built in’ Linux solution – to which I agree in a certain level given how badly some binary drivers, for example behave when SELinux is enabled.
With that being said, however, Linux offers many of the OpenBSD features either as an ‘addon’ or part of the vanilla distribution. IIRC stack protection can be downloaded off the IBM project website, for example – its just that many projects don’t take advantage of it.
So in retrospect, the issue shouldn’t be a bout ‘Linux’ but distributions who don’t take advantage/bundle security enhancements which are out there. Also, the question needs to be asked whether complexity within itself can be a security hazard – as seen in Windows, for example.
One of the OpenBSD security “features” they trump in this thread is systrace. Systrace was proven to be insecure by design. Notice how this says unpatched:
http://secunia.com/advisories/26479/
http://sysjail.bsd.lv/ They also agree systrace should not be used.
Note that they have some very good points on complexity of SELinux policies without mentioning things like setroubleshoot or the new policy wizard that makes it easy enough for anyone to write SELinux policies.
https://hosted.fedoraproject.org/projects/setroubleshoot/
http://james-morris.livejournal.com/23021.html
Yes, they aren’t wrong in what they say. However, they don’t tell the entire truth. If they weren’t so obviously biased, my mouth would be shut.
Yes, I am biased. My job is a SysAdmin and I’ve worked with SELinux.
don’t get offended by this but you should really read more carefully. Where in the Secunia site does it say that this still applies for recent OpenBSD version like 4.1 and 4.2? It actually only points out the 3.x series and 4.0 and it is also a less critical problem meaning that even in those version it really isn’t such a big deal. That said yes SELinux is very complicated and could cave used a little bit better design. But it does work and the these Linux vs. BSD articles have to stop.
This is a total flamerbate especially since the post only points to a discussion on which one is better and not some at least semi structured testing of both with feature comparison shortcomings and such. For crying out loud they are both OSS projects and there is no need to fight. The MS vs. *nix war is enough!
Well, I’ll bite: With the slightest bit of research on my part through the OpenBSD manpages for -CURRENT, I found the following:
http://www.openbsd.org/cgi-bin/man.cgi?query=systrace&apropos=0&sek…
In case you miss it (which would be somewhat ironic), see the section named ‘BUGS’. I’m a big supporter of systrace (and AppArmor), but I wouldn’t recommend using it until whichever system you use updates to use the recommended lookaside buffer.
By the way, though this may seem like a flamewar now, getting on OSnews seems more to me like good publicity for all security features involved.
Edited 2007-09-27 00:09
Nice sleuthing! Modded +1
Correct me if I’m wrong, but “processes that use clone() like system calls” means anything that uses threads. THe difference between clone() and fork() is that of a new thread vs a new process. With the advent of multiple cores and whatnot in modern cpus, it makes me never want to use systrace if it can’t be used with mulithreaded code. A local priv escalation bug is pretty serious.
The openbsd team does a good job writing secure code, but that doesn’t mean it is pretty. Has anyone actually tried to look at the openssl code? Macros of macros of macros made me want to puke in record time.
As my manager would say, “Girls, girls, stop fighting. You’re both pretty”.
OpenBSD didn’t make OpenSSL, take a look at real OpenBSD code, it’s pretty
Edited 2007-09-27 06:47
Here is a more complete list.
http://fedoraproject.org/wiki/Security/Features
Many of the exploit preventions in OpenBSD have equivalents in the Fedora security features. Exec Shield does the random library mappings and NX protection. The GCC 4.1 stack protector is based on ProPolice.
“Here is a more complete list.
http://fedoraproject.org/wiki/Security/Features“
Here is a _more_ complete list
http://www.awe.com/mark/blog/200701041544.html
That link is available in the wiki if you haven’t noticed. The point being merely turning off SELinux doesn’t mean that your system is now insecure. SELinux is one among many layers of security available in Fedora. SELinux is pretty important and having it enabled by default is a major advancement in security. The fact that it allows the choice of being turned off just like many of other security features like a firewall is IMO not a disadvantage.
I guess they’re talking about the stack-smashing protection in GCC? Most modern Linux distributions uses that too, except that they are using the more effective reimplentation in gcc 4.1. OpenBSD is still using gcc 3.3 with a patch.
selinux is complex because it’s f*cking amazing. It’s one of those “unixy” toys – a very powerful mechanism, but it’s hard to get the “policies” right…
Equivalents are available under linux. You can make the argument that they should be enabled in more distributions by default, but they are available.
The whole thread is sort of a troll though. There is no equivalent to SELinux in OpenBSD. The closest thing is systrace, which is vulnerable to race conditions by design. I guess you can argue that a policy based mandatory access control framework is a bad idea, but I’d point out 2 things:
1.) At least it’s available in Linux so experienced admins and security professionals can take advantage of it.
2.) MAC is required for a number of levels of US govt certification as a trusted operating system (see orange book). In other words, it’s a prerequisite to being used in certain government installations.
TrustedBSD (MAC including) project started in 1999
FreeBSD implemented TrustedBSD in 2003 (same year as linux added MAC to kernel), however you could add TBSD to any BSD since 2000.
any other “discoveries” aside from MAC?
propolice stack protection, random library mappings, proactive privilege separation, W^X
Equivalents are available under linux. You can make the argument that they should be enabled in more distributions by default, but they are available.
Not only that but the Linux versions of these protections are actually better. PaX is better than W^X. GCC4’s SSP is better than the old propolice by a long shot. Right now I am using GRSecurity with PaX, ssp, and pie. This is on par or better than the security offered by OBSD. Systrace is garbage and grsecurity ACLs are more effective and can be generated automatically.
OBSD is definitely more simple which makes bugs less likely but that also means their security protections are simple and not as advanced as what Linux has to offer. I think people have this incorrect assumption that OBSD is just the most secure thing out there when Linux and others can be MORE secure if set up properly. The real big win for OBSD is that it is simple and small, with a good track record and decent security tools.
SELinux happens to be only one element of security: Mandatory Access Control. Enterprise OSes like RHEL and Fedora offer a whole array of security innovations on top of SELinux.
SELinux is troublesome because of it’s inability to dynamically train/optimize itself for the changing requirements of users–or at least in a seamless and discreet manner. If a program violates a policy rule, the program just wont launch and the user will have no clue why until he happens to discover audit.log and can read verbose data or if they happen to have the “settroubleshoot” daemon and notify utility installed.
Making SELinux more flexible requires manual training. This involves creating policy modules based on security denial error logs and bypassing protection for certain “safe” applications and libraries, by using tools like audit2allow, chcon, restorecon.
The above is an unideal solution because its time consuming and unintuitive to the user. The ideal solution would be for SELinux to evolve into a more automated and dynamic MAC system that can learn and optimize security policies based on computer usage patterns and scenarios.
Edited 2007-09-26 20:59
Fedora is not an enterprise distribution …
Fedora is a stable test bed for an enterprise distribution.
Therefore, except for a long product life cycle and a commercial support infrastructure, Fedora contains most of the properties (features) of the enterprise version.
> Fedora is not an enterprise distribution …
But RHEL is. And RHEL is “only” a fork of Fedora. RHEL 5 is based on FC6. RHEL 4 on FC3…
The word “enterprise” has lost all meaning to me… Using rpmfind.net to get stuff? Yikes. Just because it meets a goverment certification doesn’t make it good (possibly the opposite). I would take Debian Stable over RHEL/Fedora any day if nothing else due to the ease of installing updates.
I think everyone is looking at this all wrong.
SELinux is too hard, but the security framework itself is very good.
I’m still amazed that SUSE is the only distribution to include Apparmor http://www.novell.com/linux/security/apparmor/
It is also “open source” and uses the linux security framework and is MUCH MUCH MUCH more easy to use.
Darren
> and is MUCH MUCH MUCH more easy to use.
I really don’t care.
I use Fedora, SeLinux is enabled and I don’t touch SeLinux policy. My OS should be secure, I don’t have to make it secure.
If i manually install a program and it trigger SeLinux policy, then I remove this program because this program should have security flaw. Period.
This only appened one time. Many many many programs work out of the box with SeLinux enabled. Some not but they are a very few number.
While I agree that Apparmor is easy to to use and configure, there are a number of (in my opinion valid) critisisms leveled against it. On the whole it is not as solid a sollution as SELinux.
Personally I don’t currently need the sort of security that SELinux offers, and as such I’m quite happy doing things the ‘old’ way (I run OpenBSD and Debian on a couple of servers). However if I needed the type of features SELinux offered then I would take the time to learn SELinux and do it right. AppArmor seems to fill some kind of in between niche that no one really needs.
Apparently Ubuntu’s next release, Gutsy Gibbon, is going to use Apparmor as well.
It’s my understanding that apparmor is going to be implemented in the upcoming Ubuntu release:
https://wiki.ubuntu.com/AppArmor
But yes, I tip my hat to SUSE for being the first to do this.
Novell brought AppArmor off another company so it takes the shine off it somewhat, it’s not like it’s there innovation.
Maybe Novell couldn’t be arsed to setup selinux and try something of their own, reminds me of another company.
Well, if the various comments I see here are indicative of anything, maybe it wasn’t such a bad idea to come up with something less Labyrinthine.
So the author is claiming that OpenBSD is MORE secure than linux because its so called “secure by design”?
This is the first I’ve heard someone call linux security an “afterthought”. Linux was also said to be MORE secure than windows because it was secure by design…and microsoft market windows as being more secure than previous versions of windows because its…well (apparently) secure by design..etc. etc.
I think the term is being used a bit loosely in all cases.
Just because OpenBSD security has been ADDED into the main kernel and Linux security as been ADDED as an optional feature of the kernel doesn’t make either of them any more or less an afterthought. All thats being stated is that linux is more modular. Both OpenBSD are being constantly developed. How do you tell the difference between an afterthought and a core feature?
How about stepping back for a second and realising that while we are human and make mistakes, be it with code or how we use our computers, there will be no such thing as total security. Both BSD’s and linux do an excellent job on security. Why start flamewars over petty stuff like this?
“Why start flamewars over petty stuff like this?”
I wasn’t a flamewar until the “responsible” “news” sites decided to pick it up. I’m a bit disappointed in kerneltrap really. Usually they do good stuff but why they thought summarizing this uninteresting thread would be a good idea is beyond me.
In other news, people have arguments.
How is this news? It’s a damn mailing list thread, not an objective comparison or anything.
Edited 2007-09-27 03:37
Well I personally am biased towards OpenBSD, and I largely agree with the OpenBSD dev’s but the discussion was rather lopsided as it compares all the security features and processes of OpenBSD to *one optional* security component of Linux.
Also as a previous poster noted, systrace was mentioned as being beneficial by one of the OpenBSD devs in that thread, despite it having been shown to be relatively easy to bypass. While the OpenBSD man page has given warnings about its weaknesses, I am lead to wonder why it is still included in the OpenBSD distribution despite not being enabled by default…
It is used by ports to rein in and catch misbehaving code. That actually seem to be it’s main use these days.
Systrace is also a good tool IF you are aware of its weaknesses and know how to use it. It’s no silver bullet though but neither is any other security solution.
Edited 2007-09-27 06:11
Well I personally am biased towards OpenBSD, and I largely agree with the OpenBSD dev’s but the discussion was rather lopsided as it compares all the security features and processes of OpenBSD to *one optional* security component of Linux.
You have a point there. One security mechanism implementation for linux is compared to an OS as a whole. Wouldn’t it be fair to bring the other possible defense mechanisms in to the equation too?
Security is a process with an awfull lot of facets. SELinux being only one of them. The OpenBSD devs have a point by saying SELinux in it’s current implementation state is a button. Which is true. To highlight an other MAC implementation namely grsecurity. During kernel compilation one can specify wether to enable sysctl support or not. They ( devs) do however say it’s a possible security decrease (i wouldn’t say breach). In addition if you don’t enable sysctl support you can only disable certain features if you recompile your kernel.
It’s a no brainer not to connect to the internet as root. Why not implementing features similar to grsecurity socket and executable restrictions.
By default on an average user box i can’t think of a legitimate reason why some process with root credentials would need socket access. While a lot of deamons can and should be disabled by default why not restrict their ability to communicate to the outside world as well? For example you can easily restict user man any connection to the internet. And if any user would have a need to disable the said restrictions he or she most likely is capable the recompile the kernel in the first place.
Gentoo is a very good example of a linux distro that is highly compatible with grsecurity. In “/etc/make.conf” you can specify user-fetch,user-priv ( emerge drops the credentials to user and than fetches update,ebuilds,etc..and installs them).In case you have restricted any object with root credentials internet access, “emerge -avuDN” will still work.
Thereis a lot more than both OpenBSD and Fedora have implemented. The problem is the difficulty to make decisions for a possible usage scenario of any OS.
Edited 2007-09-27 07:58
Yes and no. One of the points is that there are no other possible mechanisms on OpenBSD. You get “the whole shebang” and you can’t turn it off. There are no if’s and but’s.
If you wanted to be totally fair you’d compare the OpenBSD kernels security features with the stock Linux kernel’s features. Of course, that would mean no SELinux, no AppArmor, no grsecurity etc.
“Why not implementing features similar to grsecurity socket and executable restrictions.”
OpenBSD has pf which can restrict traffic based on user.
What real world problem does executable restrictions solve?
Because it adds unnecessary complexity?
You could do this with systrace if you really wanted to but (aside from the clone- problems) it’s hard to create good systrace policies.
Edited 2007-09-27 08:56
OpenBSD has pf which can restrict traffic based on user.
What real world problem does executable restrictions solve?
Can pf look in to encrypted traffic in real time? Pf is a firewall and a very good one if properly configured. It’s only a very small member of the security chain so to speak. And if you look at all the security related work the OpenBSD devs have done you know why.
Nothing, other than the end applications, can look into encrypted traffic in real time. Unless you encrypt with ROT-13 or something.
Yes, I’m perfectly aware of all the security related work they’ve done. I’ve used OpenBSD for years.
OpenBSD has pf which can restrict traffic based on usename.
What real world problem does executable restrictions solve?
You can download but it doesn’t execute. Furthermore if thereis a vulnerabilty in for example thunderbird you can click on anything and download the attachment. And even if the attachment contains malignent software and elevates the credentialls of the user running thunderbird to root, it can´t connect because the user root is added to the nosocks group.
The more compatibility between different platform the more cross platform malware you will see. Take for example the .NET framework. It is possible to make the linux kernel execute CIL-Code without any further interaction by using the binfmt modules. Xbox360 can execute CIL-Code and MS provide a stripped down version of .NET for WindowsCE.
So a real world scenario? An e-mail worm for example.
Not being able to run executables from any place most notably /home /tmp. Trustedpath enables you to launch only what has been installed by root and only from the proper locations.
Because it adds unnecessary complexity?
You could do this with systrace if you really wanted to but (aside from the clone- problems) it’s hard to create good systrace policies.
In order to restrict objects (deamons, processes, users, etc) and the way in which they connect can be steered by three options in a grsec patched kernel.
a) no sockets allowed (you have to specify a GUI, any user added to that group with specific group ID cant’t connect )
b) no client sockets allowed ( no outbound connections allowed and as said you may specify an group ID))
c) no server sockets (no inbound connections allowed for the specified group with a specific ID)
Once the distro maintainer/admin has set those UID’s it is easy to apply restrictions. For example xorg is a server but does it self have to connect? Similar does the man user need internet access at all. Do you need an inbound connection from anything with root credentials?
All can be nicely integrated in a GUI with 4 or 5 security levels 1) no extra security up to level 5 all on, you get the idea. For example in a way similar to Mandrivas msec control panel.Ofcource you can´t predict every possible usage scenario. But the user/admin doesn’t have to be bothered with to much details. All that he has to know is the level setting and the advanced knob if necessary.
I don’t see why a nicely engineered GUI can’t hide:
groupadd -g <guid> <user> or gpasswd -a <user> <group>
And provide the user if he pleases with additional information about what has been enabled/disabled. All he has to do in the end is logout and login to enable the new settings.
Edited 2007-09-27 09:44
Or you could just mount /home and /tmp noexec.
Root can mount them rwx
The beauty (or sometimes pain) of mechanisms such as SELinux and Grsecurity,Lids etc is once rules have been applyed even root can’t circumvent (you can echo whatever you want to fstab, with trustedpath only what has been installed by root can be executed regardless of other system settings. You can pretty much render your system useless.
As with security you unfortunately can’t have it all. I keep on dreaming of an OS such as *BSD/Solaris with the repository and hardware compatibility of Ubuntu. running tvtime,kradio and such on OpenBSD or Solaris would be nice.I’m sure others can add a lot to the equasion too.
Edited 2007-09-27 10:27
If a random process or untrusted user has gotten root access you have bigger problems than that.
I just don’t see the point in these fine-grained complex schemes but for each their own.
Heh. OpenBSD actually support my hardware better than Linux
Hmm…any particular reason those cant run on OpenBSD?
running tvtime,kradio and such on OpenBSD
>> Hmm…any particular reason those cant run on OpenBSD?
Thereis no v4l on OpenBSD?
This is not a debate because there is nothing to debate. OpenBSD’s security features are nothing like SELinux and are not comparable. OpenBSD’s approach to improved security would be a good thing for Linux to have but it would not replace SELinux. You simply cannot compare architectural, design choices which improve security with access controls.
Hi,
yeah, the security features list of fedora and RHEL clearly state that they include stack protection, but if you do test things out properly, you will easily find that they don’t work properly.
After a lot of testing, the way to go for me is hardened gentoo and grsec!
Also, OpenBSD shines for being an extremely well written OS. That also means security. Maybe the features list is shorter, but a proper written OS is superior to a list of features that… don’t work that well!
Edited 2007-09-27 19:52
”
yeah, the security features list of fedora and RHEL clearly state that they include stack protection, but if you do test things out properly, you will easily find that they don’t work properly. ”
Where is the references? Where are your bug reports?
Tested with standard minimal install from Fedora and CentOS (RHEL clone).
Just write a simple C program to smash the stack and compile with the stack protector flag. As easy as that!
If your C skills aren’t that good, you can easily find code for it in google.
No hand waving folks. If you want to make a claim, the burden of proof is on you. Show us the code.
Look at the code I just wrote
Try an unbound strcpy.
Try an unbound strcpy.
They are providing code you’re providing more talk.
I just want to highlight that.
Like this:
jeff@omniscience:~/src/c$ cat gets.c
#include <stdio.h>
int main(void) {
char instring[20];
printf(“Please overflow my buffer: “);
gets(instring);
return 0;
}
jeff@omniscience:~/src/c$ gcc -fstack-protector -o gets gets.c
/tmp/cc4h1VDd.o: In function `main’:
gets.c:(.text+0x2f): warning: the `gets’ function is dangerous and should not be used.
jeff@omniscience:~/src/c$ ./gets
Please overflow my buffer: Hello, my name is jeff the script kiddie and next comes metasploit to own your box
*** stack smashing detected ***: ./gets terminated
Aborted (core dumped)
jeff@omniscience:~/src/c$ Maybe it is time to go get some milk and cookies…
jeff@omniscience:~/src/c$ gcc -fno-stack-protector -o gets gets.c
/tmp/cciF3xXu.o: In function `main’:
gets.c:(.text+0x24): warning: the `gets’ function is dangerous and should not be used.
jeff@omniscience:~/src/c$ ./gets
Please overflow my buffer: Next comes the shellcode to own the box
Segmentation fault (core dumped)
Define well written… How well does OpenBSD handle my numa capable 16 processor server now-adays?
“How well does OpenBSD handle my numa capable 16 processor server now-adays?”
That has nothing to do with how well-written it is.
It’s a matter of whether it is supported or not.