Live data from Hacker News

HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

hardenedbsd.org

41–50 of 81 posts

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#41
post #16

It's easy to invent a chart that only you can get a nearly perfect score on. This does nothing to explain what any of these features are, what are "Boot hardening" and "sysctl hardening"? At least OpenBSD's innovations page makes an attempt to explain new concepts and features that have been developed over the years, and people can make any comparisons for themselves. https://www.openbsd.org/innovations.html

It says "Please note that this page is out-of-date. For a more detailed and up-to-date guide to HardenedBSD's features, please visit our wiki." at the bottom. So I tried that.

I'm guessing that "sysctl hardening" is https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/wikis/...

There's no clue on the wiki what "boot hardening" is, though.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#42

Earlier quoted context omitted.

> Sandboxing™ Writing it like this is kind of funny, hoenstly, but not for the reasons you probably think. > give you that pledge+unveil doesn't? Not requiring the cooperation of developers to opt-in, for starters. You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lo…

> Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? FreeBSD has capsicum and Linux has seccomp-bpf & landlock. Of the three, pledge and unveil are the least horrible execution of the same idea (though capsicum is alright, too). Obviously it's not a "run any random machine code on my system safely" type of sandbox, rather it's used by e.g. bro…

> Of the three, pledge and unveil are the least horrible execution of the same idea

I don't think they are the same idea though. pledge and unveil are significantly more limited in scope.

> Obviously it's not a "run any random machine code on my system safely" type of sandbox

That's pretty much what a sandbox is though. Not every limitation or security augmentation is a sandbox, nor does it have to be.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#43

Earlier quoted context omitted.

I mean, both of these are really just lists of mitigations. What would really be useful is why each of these has been developed, what attacks it tries to stop, why that was chosen as something worth protecting against, and what is out of scope for each of them.

Good LLM prompt seed :)

I doubt it. Most humans do a pretty poor job at this already, and LLMs train on things other humans have written. If you have examples to the contrary for a novel mitigation I'd love to see it, but I will also only believe it when I see it.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#45

Earlier quoted context omitted.

> Sandboxing™ Writing it like this is kind of funny, hoenstly, but not for the reasons you probably think. > give you that pledge+unveil doesn't? Not requiring the cooperation of developers to opt-in, for starters. You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lo…

> Not requiring the cooperation of developers to opt-in, for starters. This is a good point. My initial thought is that the developers would know best what features their application needs? Furthermore, it's work that every user benefits from, rather than requiring an IT professional to reconfigure for each use case. What do you see as the downsides?

> What do you see as the downsides?

Legacy software, new security issues which has not yet been patched. As the operator you have no way to isolate the application, you just have to wait for the developer for both mitigation and bug-fixes.

In the real world I don't see that making much of a difference. Many sandbox solutions aren't really being used anyway, legacy software can go on it's own VM and network. Micro-segmentation of networks are in style for those types of companies anyway.

Pledge and Unveil seems like more pragmatic solutions to me, but they do require a certain level of care and engagement from the developers. If you don't have that, then things like SELinux, AppArmor or some type of sandbox that can be applied by the operator can help prevent an attacker from getting a foothold on a server or VM.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#47
post #5

Read these claims with a pretty big asterisk. Implementation quality of HBSD features is often poor or very poor. https://www.fabiankeil.de/gehacktes/hardenedbsd/ is just one example. Specifically some of the changes made to "harden" the system are pretty dubious and introduce new bugs, possibly security relevant, that did not previously exist. No one runs or pen tests HBSD. It's even more niche than OpenBSD.

Your example is 9 years old (2015) when the project was less than 1 year old:

https://hardenedbsd.org/content/about

It also sounds like the person wants to promote his own "ElectroBSD", but just in the form of a patch-sets because of "unresolved license issues" he reallyreally wants his GPL-Code in BSD:

https://www.fabiankeil.de/gehacktes/electrobsd/

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#48
post #26

> Executable file integrity enforcement I assume but don't know for sure that this refers to Veriexec in NetBSD, and I'm not sure what in HardenedBSD. Anyone know? https://man.netbsd.org/veriexec.8 My understanding is that Veriexec isn't enabled by default - the manpage says only that "[s]ome kernels already enable Veriexec by default." If you have this enabled, how do you upgrade binaries? The manpage says that in s…

> In either case, you just need root to update targeted binaries.

My understanding is that the difference is you would need to boot with a kernel with veriexec disabled to replace binaries and regenerate hashes. Root alone isn't sufficient, and you can't disable veriexec as root in strict mode.

Re: HardenedBSD Feature Comparison with OpenBSD, FreeBSD, NetBSD

#50

To clarify things a bit, HardenedBSD is a bit like Linux+Grsecurity, but for FreeBSD, yes, there are differences, but overall it's like Grsecurity+. BTW: For Linux, OpenPaX is on the horizon: https://www.phoronix.com/news/Edera-OpenPaX-Announced

OpenPaX looks great, but I can't find a patch anywhere, just an already patched forked kernel tree.
Post reply on HN