Seriously? I'd recommend doing some more research before making that claim. Your example in a later comment speaks to the area of Privilege Separation, discussed (and implemented) ad nauseam throughout nearly every application that is maintained by the OpenBSD project.

http://niels.xtdnet.nl/papers/privsep.pdf

http://www.citi.umich.edu/u/provos/ssh/privsep.html

https://www.openbsd.org/papers/ven05-deraadt/index.html

https://www.openbsd.org/innovations.html

Privilege separation is also a nice feature, but it is not the same as MAC.

I would have much greater confidence in an OpenBSD project that included lomac or capsicum.

Why do you need ACLs to run a few services on their own server?

So that a root compromise in one service does not escalate to the entire server.

As a concrete example: my personal mail server (on a modern operating system) has its SMTP handling in a separate process from mailbox serving. If the SMTP process is compromised, and the attacker reaches uid=0, it doesn't matter -- no data from the mailboxes can be exfiltrated.

Only SMTP is broken, because mandatory access control prevents the SMTP "root" from doing anything the SMTP daemon would not ordinarily be permitted to do. The SMTP daemon is not empowered to read mailboxes, even if its uid is 0.

I think in this hypothetical scenario the uid 0 attacker can create its own node for /dev/rwd0 and use raw disk accesses to get around filesystem limits.

It's also hypothetical in that there's no known OpenSMTPd exploit that will allow you to get root, and barring a single CVE its record is pretty damn good.

https://www.cvedetails.com/cve/CVE-2015-7687/

Then you compare its record to Sendmail...

It's a matter of defense in depth.

OpenBSD robs you of one of the layers that is standard on every other operating system in the world: Linux, FreeBSD, Solaris, even Windows.

Blind reliance on ACLs/MAC is dangerous itself. I've had the benefit of working on all of the above and ACLs aren't something people get right the first time. Most don't even get it right the 10th time.

We use SELinux in my current place and while it's fine, things break/fail in odd ways and we're always tweaking it.

In the 6-7 years I did Windows administration, I trained a couple hundred people on ACLs and specifically how the SubInACL tool should be used -- for all but about a dozen of them who truly grokked it, that training was an ongoing process over the course of those years...

OpenBSD's advantage is in its simplicity, which ultimately is the best security. If you have a system that you can clearly reason about and design for where it might fail, you are better prepared for "when" shit happens -- because it's not "if". If your entire system is properly architected, this isn't actually an issue.

Chances are if you have your own server for email you also want to run some other services on it, like a blog. Those may be less secure.

For that particular example it should be pointed out that OpenBSD chroots the web server by default which ends up running as a non-privileged user. OpenSMTP does as much work as possible in multiple tasks running as a non-privileged user. So even ignoring the access control provided by the pledge system it is really unlikely that anything is going to escape to root or even be able to affect each other.

Sorry, I learned this lesson a long time ago. One service per machine. Especially this day and age where that's easy and cost-effective.

It's also not permitted to do that. Again, that's the point of mandatory access control.

It doesn't matter that you have uid=0, you do not have the granted capabilities to do new things.