FreeBSD – A lesson in poor defaults
vez.mrsk.me
vez.mrsk.me
- https://news.ycombinator.com/item?id=11318508
- https://news.ycombinator.com/item?id=12484248
- https://news.ycombinator.com/item?id=16008688
Note that updates to this post are listed as addendums at the bottom, rather than removing sections that are no longer true in current versions of FreeBSD.
I found it interesting, anyway, but didn't come away with any inclination to use OpenBSD on my next deployment.
I've been quite negative in this thread because the overall debate on these topics is pretty frivolous. We already have the tools at our disposal to do magnitude greater secure software and splitting hairs over which BSD has better defaults is missing the forest for the trees.
Do you have a specific language in mind that offers improvement? Or am I reading too much into the sentence?
>We already have the tools at our disposal to do magnitude greater secure software
Mind sharing more details on the tools? Specifically with respect to System / OS Level programming.
Any language with memory and type safety should comprise as much as possible of the whole system. See the Singularity OS from Microsoft Research, or whatever that Rust OS project is called.
Almost all the major, nicknamed, headline-grabbing RCE bugs in the last two decades are memory or type safety issues in C or C++ code.
Every C or C++ developer claims safe code is possible or even easy in their favorite language, but history has proven them very wrong.
syskaller is in use by the major BSDs and stricter compilers and other static analysis tools have been a far bigger impact IMHO than the OpenBSD style mitigations. I would like to actually see some kind of case studies where OpenBSD mitigations have protected a user where they'd have been let down by say Linux or FreeBSD or OpenBSD without them.
I think a less snake oil approach to security is done by the seL4 folks, the difference in approach makes the *nix security mitigation people somewhat cringe worthy.
Maybe - and I'm only saying this because I care - there are a lot of decaffeinated brands on the market that are just as tasty as the real thing.
Maybe - and I'm only saying this because I care - you should consider through hiking and come back to the discussion when you are less easily offended by the facts at hand into low grade trolling and have requisite attention span and reading comprehension to participate meaningfully in the conversation.
Now what Linux, and to a lesser degree FreeBSD, can do is survive real world usage at scale. OpenBSD cannot. It would fall over or require magnitude more machine count to do the same workloads that people use Linux and FreeBSD to run. So all the exploit mitigation diatribe and "great defaults" and pet projects are cute but funny when you try and throw shade onto others with them. As I said, there are some kernels of truth that pertain less about security and more about overall health in FreeBSD this doc accidentally hits on, but running some hobby software like opensmtpd on openbsd isn't going to save the world from real cybersecurity issues.
As someone who has run web servers with both FreeBSD and OpenBSD, I think some of your criticism in this thread is valid, but you really crossed the line into blatant fanboyism with that one at the least.
LibreSSL isn’t really in widespread usage outside of OpenBSD and has still been vulnerable to some of recent the OpenSSL exploits.
OpenNTPD is more widely used but lots of people still go for other alternatives and frankly I’m not convinced OpenNTPD offers anything significant over the competition anyway.
pf is barely used outside of OpenBSD and frankly why should it be when Linux has iptables (which does the job well) and FreeBSD has ipfw (which also does the job well). pf is also a decent firewall but it’s also a crowded market with lots of really decent alternatives written by their respective platform hosts.
I do actually quite like OpenBSD though. But outside of OpenSSH, OpenBSD is slowly becoming less relevant to the wider industry as other platforms catch up on security and even over take in terms of enterprise features.
(Also, I’m missing what’s so “funny” and “hilarious” about it.)
Do you have a better synthetic benchmark to suggest?
And "speed" does depend on expectations. Compute tasks should be approximately equivalent, right? And os-limited tasks with many syscalls less so. You don't specifically state your expectations. Just that you are disappointed.
I installed FreeBSD last night, you can just tick/untick these options during the install which addresses most of the article.
[ ] enable sendmail
[ ] enable sshd
[ ] enable ntp
[x] encrypt swap
Author thought that having ASLR is absolutely must (hint: it's not[1].) HardenedBSD is poorly reviewed ASLR implementation by a person who didn't take criticism well + recommended new defaults from subj.
Later hBSD added neat things like different update mechanism (hint: it's the same minus delta patches), retpoline enabled by default a little earlier than FreeBSD and probably still haven't disabled it.
It's a fact that FreeBSD had poor defaults for ages and only recently (last couple of years) started cleaning things up. That said I never seen FreeBSD user running default system settings. Many not even running GENERIC kernel, me included.
I think FreeBSD has a lot of issues, but 90% are political bullshit.
[1]: https://arstechnica.com/information-technology/2017/02/new-a...
By far the worst offender i ZFS. Having ZFS as an option on FreeBSD (or Linux) is wonderful, but it's extremely clear where ZFS has its origin. ZFS feels like it was just bolted into FreeBSD and no one has a plan for making it feel like it belongs.
OpenBSD has been incredible successful in building a base system that feels like everything belongs together and working in a similar fashoin
I think we are missing some context here?
The author never explains how 3 firewalls are bad. It seems this is probably some Linux hack trying to slander FreeBSD.
"There should be one-- and preferably only one --obvious way to do it."
But unless you also wish to argue that "there should be preferably only one programming language", it also follows that there are other sentiments upon which to base languages.
Here's one that seems to fit the continuing analogy: TMTOWTDI.
https://en.wikipedia.org/wiki/There's_more_than_one_way_to_d...
Now, you may not like that one, and that's fair. I frankly like Python less the more I use it, but it still has its place in my toolkit.
I wasn't trying to say that there should only be one programming language, and I don't think it follows from the statement I quoted. I take it more like this: You use the correct tool for the job, and if there are inferior tools then just get rid of them.
In the context of the discussion, I happen to think that one packet filter/firewall in an OS is the correct number, unless each has significantly different uses. Such is not the case in FreeBSD.
It would have been interesting to have some more info on this part too:
>It does not go in depth about changing FreeBSD's more serious low-level problems that require code changes.
Does anyone have any resources to read up on this? I’ve been reading “The design and implementation of the FreeBSD operating system” by the way.
OpenBSD developers almost always change features for security reasons. They aren’t afraid of writing their own utilities or maintaining entire projects to do things in a cleaner way. This can lead to compatibility and/or performance issues, but at the same time you get a very nicely integrated base system.
I know less about FreeBSD, but they seem to place more responsibility on the user for building a system using their primitives. The choices they make with regards to backwards compatibility and defaults make sense in this context. FreeBSD is also usually the first stop for ex-Linux users who have become disenchanted by systemd or other changes to the system.
Linux as a whole doesn’t really have to choose a side because distributions have their own opinions and there’s enough eyes across popular packages to have decent security while maintaining a huge number of features.
I feel very at home with FreeBSD and it has been a consistently good experience over many years.
I'm curious about this statement. Which languages do you think indicate greater security, which ones tend to indicate the opposite?
However, knowing what bugs exist or other issues that effect security is hard. Let alone comparing.
I agree. For example, according to [1]: "In the autumn of 2004, [Dan] Bernstein taught a [University of Chicago graduate level] course about computer software security, titled "UNIX Security Holes". The sixteen members of the class discovered 91 new UNIX security holes. Bernstein, long a promoter of the idea that full disclosure is the best method to promote software security and founder of the securesoftware mailing list, publicly announced 44 of them with sample exploit code."
This was 15 years ago, but it does reveal just how hard it is to know how many vulnerabilities are out there.
And quite frankly, deliberately shipping a product with gimped security, especially when it comes to OpenSSH, is kind of not very excusable and has nothing to do with "stability".
I’d go so far as to say that you shouldn’t touch a FreeBSD or OpenBSD install unless you’ve already done and maintained a gentoo, arch, or LFS install.
And by "post install configuration," I mean adding XFCE or other DE or WM, along with whatever apps you like. No tweaking needed to close security holes.
I’d say it’s about equivalent to a simple Arch install on easy hardware, although OpenBSD comes with quite a bit more security stuff pre-configured.
While you're doing the initial configuration, you get to learn a good deal about what the OS is made of. I found investing a little time to get familiarized with the system components results in more confidence as a user, rather than simply letting the OS do its magic and then wondering how it works later on. Like moving into a new house... You want to know where the fuses are and how to shut off the gas valve.
As general purpose operating systems go, there was another interesting article from earlier this year comparing popular Linux distros which found that Ubuntu (18.04) had the best overall posture with regard to use of hardening and mitigation mechanisms out-of-the-box vs. versions of CentOS/RHEL, Debian, and OpenSUSE at the time. Some of this was due to the newer Linux kernel version being used, but also thanks to hardening of binaries, etc.
> Our experiments indicate that Ubuntu 18.04 shows the largest adoption of OS and application-level mitigations, followed by Debian 9.
https://capsule8.com/blog/millions-of-binaries-later-a-look-...