Hacker News Reader

Comment by cm3 | Hacker News Reader

I still have hope some or all HardendedBSD features might get ported or reimplemented in FreeBSD 12. Too much low hanging fruit, and now that linux has been steadily closing the gap to grsec, the competition in mainstream kernel branches is on.

View on HN

HardenedBSD is one of the bigger jokes in the BSD community. If you really care about the things it claims to do, I highly recommend using OpenBSD because it actually has competent and sustainable development.

Are you saying that the measures listed here http://hardenedbsd.org/content/easy-feature-comparison do not work properly?

I'm not GP, but yes. They do not work properly and likely introduce additional vulnerabilities.

Do you have any evidence for this? I've heard rumors here on HN and else where that HardenedBSD's code quality is lacking and that they didn't incorporate all the fixes and suggestions from the FreeBSD community during the various code reviews. But none of that is definitive, do you have any proof or evidence for this statement, "They do not work properly and likely introduce additional vulnerabilities."

Here's an example of poor code quality:

https://github.com/HardenedBSD/secadm/commit/3dd7584b70804cf...

If this check did anything, it appears susceptible to time-of-check, time-of-use attack.

See also https://reviews.freebsd.org/D473 , where Shawn pretty cleary does not incorporate feedback from the FreeBSD community.

Fair enough. The more important part of my question: isn't there a focused effort to complete FreeBSD's security feature checklist?

No one is paying for completion of checkbox security features in FreeBSD. So the community is really only interested in effective mitigations and not checkbox features.

We would love to merge in Konstantin's ASLR work. Reviewers have pointed out performance issues and memory fragmentation issues, especially on 32-bit platforms, but it's still better than nothing. I think we should just merge it as is, maybe default to off on 32-bit platforms, and improve from there. With the intent to have it polished for 12.0-RELEASE.

One such mitigation receiving community attention is Capsicum. The Capsicum security sandbox is a viable way to constrain applications. Unlike OpenBSD's pledge, rights are limited on a file descriptor basis. It has been ported to Linux and DragonFlyBSD (although merged to neither). There has been a lot of work in FreeBSD lately to restrict base programs, especially setuid programs, using Capsicum.

What has Linux done to close the gap to GRsec?

Kees Cook and others have been porting or reimplementing features exclusive to grsec in upstream linux.

https://outflux.net/blog/archives/2016/09/26/security-things...

https://outflux.net/blog/archives/2016/09/27/security-things...

https://outflux.net/blog/archives/2016/09/28/security-things...

https://outflux.net/blog/archives/2016/09/30/security-things...

https://outflux.net/blog/archives/2016/10/03/security-things...

https://outflux.net/blog/archives/2016/10/04/security-things...

And naturally some stuff is exclusive to linux upstream, though grsec will benefit from those automatically if they deem it good enough.

Reply on news.ycombinator.com