Hacker News Reader

Comment by maayank | Hacker News Reader

I’m genuinely interested to hear criticism re: security in openBSD if any one has an interesting link or take

That's easy: OpenBSD pioneered OS-wide dragnet code audits, and also an ethos of minimally-invasive, parsimonious OS security features (PID randomization and syscall pinning are two emblematic examples). The rest of the world caught up to OpenBSD on dragnet audits, and then surpassed it; meanwhile, the OpenBSD ethos of minimal, modest security features was probably less effective than the Linux approach of features that bend the whole universe around security challenges or that thread deeply through the operating system.

More than anything else though, it's not so much that OpenBSD is less resilient than Linux (I think a case could be made), and more that OpenBSD isn't materially more secure.

They should have killed the "only N K holes in Z time" tagline a long time ago.

I have written poorly worded criticisms of the OpenBSD project on HN before. They boil down to this: from my observation, it looks like the approach to security in the OpenBSD project is adding more code to solve security issues when it should be the opposite. Code is a liability. You should write as little of it as possible to solve the problem at hand and not spare a single line that isn't needed. In this case the problem is getting a shell on a remote host. Why do you need so many configuration options to solve this single problem?

The OP is a prime example of the opposite happening - it's adding code to prevent repeated authentication failures. Why would this be needed in the first place? If you have configured OpenSSH correctly (that is, using public key authentication instead of password auth, which should not even be an option), then repeated authentication failures should not be a problem. At worst, they take up some CPU time.

Much of the code in OpenBSD and the wider OpenBSD projects also address memory safety issues which would not be issues in the first place if they just used a memory safe language. Yet they push ahead using C in the full knowledge that there are better options available. Java, Go, Python, Rust, I literally don't care, anything would be better than C. Developers should not need to spend hours carefully poring over each others patches to find critical mistakes when it comes to memory. They should not need to spend hours reading C development guidelines or rely on mailing list oracles. By eliminating memory errors as a class, mental capacity is freed up to identify logic errors.

I can't speak for OpenBSD specifically but I can speak to some of my thoughts in why an operating system continues to use C. Supporting a language ecosystem is not easy, the less "default" languages needed to bootstrap the core system the better. The nice part about C is that it's one of the few languages suited for both kernel space and user space. Out of the alternatives you listed the only language that could even seriously be considered for kernel space is rust, and even that took a lot of back and forth to get it to that point in the Linux kernel. Higher level languages have a larger range as assumptions and you have to tow those accomodations in to kernel space if you want to use them. There is also the issue of the memory management in kernel space being much more of a complicated environment than user space. How do I teach the borrow checker about my MMU bring up and maintenance?

I am also skeptical to your claim about removing memory bugs freeing up brain space for logic bugs, at least for Rust. Rust has grown quite a number of language features, that in my experience, result in a higher cognitive load compared to C. If you seriously reduce your reliance on the C macro system (as Plan 9 has shown possible), the language itself is quite simple.

In very simple terms, their approach to security is auditing to try and remove all bugs, but offering very little to protect against the case where there is a remote root hole, such as they have had in the past.

Things have gotten better in recent years with things like pledge and doas, but they are quite lacking compared to proper MAC or sandbox implementations. Worse, many of the OpenBSD devs don't seem to know much about those technologies and are kind of dismissive. I remember an OBSD user or enthusiast trying to argue Pledge was equivalent to SELinux which was pretty bad.

I'd take a slimmed down hardened Linux install over OpenBSD any day of the week.

> In very simple terms, their approach to security is auditing to try and remove all bugs, but offering very little to protect against the case where there is a remote root hole, such as they have had in the past.

I'm not sure what is meant by "protect against the case where there is a remote root hole". Do you mean, to mitigate harm from existing holes? They secure things from top to bottom, but maybe you mean some kind of authorization issues? To proactively prevent holes? They do a lot of engineering around the latter (and around other attacks) - to the extent that many question the wisdom of solving 'problems' for which there is no proven exploit. And they have had very few remote holes - whatever the reason, there's not evidence that they fail to prevent them.

> I'm not sure what is meant by "protect against the case where there is a remote root hole".

I don't understand how this is ambiguous. I mean limit the damage that an attacker can do if they get root - this is something RHEL can do and OBSD pretty much refuses to.

> They secure things from top to bottom

Eh. Kind of. The devs are against security technologies that they think add too much complexity to their system regardless of benefits. That's why they don't have any kind of RBAC or MAC, just plain old DAC. You get root, you get everything - pledge and unveil won't help too much there.

> I don't understand how this is ambiguous.

It wasn't an attack, but a genuine question, for which I provided two possible interpretations. I was (am) interested in what you were saying.

> That's why they don't have any kind of RBAC or MAC, just plain old DAC. You get root, you get everything - pledge and unveil won't help too much there.

Thanks for explaining.

> It wasn't an attack, but a genuine question, for which I provided two possible interpretations. I was (am) interested in what you were saying.

No worries at all! I wasn't taking it as an attack and apologies if my response seemed combative. I just honestly didn't understand where the point of confusion was.

> Thanks for explaining.

My pleasure! If you're still interested in discussing, I am interested in the point you made that 'They secure things from top to bottom' - if I may ask, why do you think this is the case? It's not a statement I would ever make myself.

Reply on news.ycombinator.com