FreeBSD – a lesson in poor defaults | Hacker News Reader

FreeBSD – a lesson in poor defaults

vez.mrsk.me

208 pointsran29064 comments

I'd be interested in hearing @cpercival's take on this. He was the FreeBSD Security Officer for a while (but stepped down some years ago) and is definitely properly paranoid about security.

I find that thumper's rule is very useful when dealing with zealous members of the OpenBSD community.

So the guy is talking utter nonsense and you'd rather not "feed the trolls" so to speak? Genuine q, security isn't my speciality

It's not all utter nonsense. Some things fall into the category of "we can't change this overnight because we have users, but it will be changing in the future".

Sure, he even acknowledges that by writing that in FreeBSD world back compat is more important than security. There's obviously nothing wrong with that as long as you're OK with this trade-off. He isn't, sucks for him then. :D And calling him OpenBSD zealot that is trolling is, well, trolling. ;)

The author writes:

   ###############################################################################
   daily_status_security_pkgaudit_enable="NO"
   ###############################################################################

   I most certainly don't want pkg (running as root, remember) going out to
   the internet every night to fetch a list of vulnerable ports.

   Who thought this was safe?

I’m confused. Why is this unsafe? Is it because the author doesn’t trust `pkg` to do the auditing job safely as root? Remember, this isn’t automatic updating/installing. This job just adds a section to the daily email that tells you which packages have security updates to them.

I think it's more of a defensive thing, where pkg should drop privileges unless it's performing an operation that absolutely requires root access. Technically, `pkg audit` doesn't need to run as root, since it only downloads a package catalog and compares it to the list of installed packages.

Yes, making this change is bad for security, unless you have some other means of being informed of vulnerabilities.

If you think pkg has vulnerabilities, fix them. (For instance, running as not-root is a great idea!) The author's argument that pkg is bad because Debian apt has vulnerabilities is ... really stretching.

Isn't that still assuming that the information that pkg provides is generally trustworthy?

I assume their consideration is that the list might not be trustworthy, so knee jerk updating based on a potentially faulty list is itself a vulnerability. Would a 24h delayed updated list of security updates be worse than an incorrect one?

The fact that pkg isn't least-privileged in its operations sucks, but the idea that this somehow makes the contents of a cryptographically signed vulnerability list, fetched via SSL with chain-of-trust verification "untrustworthy" is nonsensical.

Since it runs as scripts as root what happens when through malice, mistake, or odd configuration a script gets through standard review and trashes a system? What if one of the official maintainers doesn't exercise due diligence?

You're protected from MITM and hacked repos, but what if the problem is in the official repo?

Defensive programming is useful.

Yeah, but that's not the argument. I'm specifically responding to the parent's assertion that you wouldn't want to run audit because the list might just lie to you.

That's separate from the idea that the list might be maliciously crafted to exploit an overflow and gain root privileges (which presumably could bypass signing checks) -- if your threat model involves loss of control of FreeBSD's signing keys, pkg running as root is irrelevant. You can't ever trust anything outside the box, or update at all. No binary is trustable and even if you heavily audit the source you're in trusting-trust territory.

(also the only key that matters is the Security Officer's key for vuln disclosures -- not any random maintainer has signing authority)

No operating system, anywhere, has or can have protections against an official maintainer of their security update system screwing up and releasing a bad security update that has gone through all review and other checks.

The only possible defense is to turn off security updates entirely, and empirically, that is much higher risk. I can think of cases where signed and approved security updates have introduced regressions to valid use cases (e.g., LP #1058343 bit me badly at my previous job), not fixed a problem (e.g., the day after Shellshock came out), etc.... But I cannot think of a single case where a signed and approved security update, by an OS making even minimal attempts to have a decent process around updates (so, anyone better than Linux Mint), has been actively harmful.

Given that an operating system security update, by definition, is capable of changing the most privileged code on your system, there's no way to program it defensively. It needs to have the ability to make arbitrary changes your system (and thus the theoretical ability to trash your system) in order to be able to fix unforeseen bugs.

> Is it because the author doesn’t trust `pkg` to do the auditing job safely as root?

Even if one asks the question and arrives at "yes, I trust this program", there is value in eliminating the question itself.

Yeah, it seems pretty obvious to me that there's no reason pkg should be running as root just to fetch the list of vulnerable ports.

Some discussion here:https://www.reddit.com/r/freebsd/comments/4azhmm/freebsd_a_l...

Wow, that comment about OpenSMTPD. I highly recommend reading beyond the first message. The reddit poster links it as supporting their claim, but the rest of the picture sure doesn't.

I'm really torn on the issue of how tightly coupled the userland configuration is to the release cycle. I'm not sure that I'd be running FreeBSD today if it hadn't been that way, because having a well tested and widely deployed base image makes adoption so much easier. The common problems that novices get discouraged by are completely sidestepped: package conflicts, library incompatibility, missing drivers, etc.

But after several years of use I find the methods used to implement those thing getting in the way:

In the interest of security I want the kernel to have the smallest attack surface possible, and this isn't just a theoretical thing. Not long ago there was a very serious remote exploit that leveraged two default kernel compile options - SCTP and IPV6, and had those not been made default (few can even take advantage of SCTP) I'm sure the number of vulnerable machines would have been tiny. So to decrease your risk for a 0 day you want to get off the GENERIC kernel config, but now you need to constantly rebuild the kernel in order to keep up with the latest security fixes - and you can't safely automate the build/install process.

Building the userland is far worse. The mk scripts handle dependency through explicitly defined, and very fragile, rules. Don't want the base version of openssl? Well have fun figuring out how to get your build working after some uefi bins that you don't even want fail to find the missing openssl headers - because somebody forget to add that dependency to the mk file. I could go on for hours, the buildworld process is a trainwreck.

But there is good news! The problem is actively being addressed, as I understand it, a lot of that is being pushed into a sort of blessed pkg repo. So hopefully we'll have the best of both worlds - easy initial base, and unlimited customization that leverages the pkg dependency code. I've been working on my own solution, using dynamically generated dependency graphs at the compiler level, but extending the pkg system seems like the right way to go.

It seems that a lot f the issues the author has they can fix by moving over to OpenBSD. I'd be curious to hear what makes them stick with FreeBSD instead considering the complaint.

I'm not the OP but OpenBSD is missing some pretty key features. My reasons to use FreeBSD over OpenBSD are:

  - Virtualization (jails, bhyve)
  - Filesystems (ZFS)
  - beadm (which requires ZFS)
  - Linuxulator

Which really is a shame because philosophically I think I'd prefer the OpenBSD camp

And let's not forget that OpenBSD doesn't make use of modern hardware as well as Linux and FreeBSD or DragonflyBSD. SMP incompleteness is one of the issues.

Given the focus on security, don't expect to see SMP anytime soon if ever. It's a huge source of potential security bugs and attacks on the kernel.

I've never seen or expected to see "limit yourself to one processor for better security" as actual advice. Maybe this is sarcasm that I'm misreading?

Not at all, SMP opens a huge can of worms both for userland and kernel security. Suddenly you have all sorts of weird race conditions to deal with and in some kernels (cough XNU) logic bugs that stem directly from how kernel subsystems interact with threads. I don't blame OpenBSD for not going down that route.

Which is why DragonflyBSD was forked during the disagreement on FreeBSD's SMPng. Matt implemented more of a message passing system instead and Sepherosa Ziehau made all kinds of improvements to share as little as possible between cores and thus enable higher scalability in particular for networking.

OpenBSD supports multiple cores fine as far as userland goes. If you have 8 cores and start 20 userland processes, they'll be scheduled on all 8 cores. But yes, the kernel itself is not as fine-grain multithreaded as some others. Whether that matters depends on whether waiting on the kernel turns out to be a bottleneck for your workload.

The kernel is undergoing rapid work to distribute load among cores for major subsystems right now...

But in practice, partial fine-grained locking is as useless as partial security. Which is why nobody cares.

It might be ok for compute-only tasks that spread calculations over threads or processes in userland, but anything involving input/outpout (e.g. networking) will block.

As with all things in computer science, there haven been successful implementations of anything that we see as unsolvable in a Unix-derivative. It's sad that so little of even non-research results has been incorporated into mainstream operating systems. I'm sure nickpsecurity can expand on this in detail, but let's just say Burroughs, VMS, Eros, L4 are all things that come to minds as ancient production quality software which solved issues fundamentally. For a newer strain have a look at Barrelfish.

> Which really is a shame because philosophically I think I'd prefer the OpenBSD camp

The friendliness of the FreeBSD community is why I wouldn't even consider going over to OpenBSD.

Also:

  - LLVM
  - Arm support
  - The handbook

I do envy OpenBSD's pledge() and arc4random() though.

OpenBSD man pages and FAQ are really good too. LLVM is not in the base install, but you can install clang from ports and build a program if you need to.

I agree with pledge() and arc4random(). They are both ridiculously easy to use. FreeBSD has Capsicum but it doesn't seem to be integrated.

Oh, and FreeBSD has DTrace. Judging from some recent commits it looks like OpenBSD is going to get some sort of tracing framework.

> OpenBSD man pages and FAQ are really good too.

Absolutely! I didn't mention the man pages because all BSDs have really good ones and they all use OpenBSD's mandoc these days.

OpenBSD doesn't appear to have Infiniband support either. :(

It's unfortunate that Shawn and Oliver decided, after failing to upstream their ASLR patches, to make HardenedBSD a full fork. I wish they would reconsider, because Konstantin Belusov has begun an upstream from scratch implementation of ASLR. But HardenedBSD is so much more than just ASLR and for a network facing OS it's crucial to have as many layers of mitigation as possible. Jails with Capsicum and ZFS are so promising already.

Virtualization for amd64 and i386 is in progress. Rapid development is taking place on vmm/vmd. There is a port of dragonfly hammer fs which is less rapid.

Jails are a mechanism, not the mechanism. OpenBSD has chroot for most of the same use cases. Virtualization is long overdue but it's coming. ZFS is not my kink but I get it why people want it. Having worked on CoW file system for three years I came to the conclusion that its perceived appeal is what sells it, but use cases are very few (if any) without system-wide control service. :)

I have not used beadm though - what's the kicker?

I use FreeBSD for a fileserver because it has rock solid ZFS support. At least at the time I set it up (I haven't looked recently), neither OpenBSD nor Linux supported ZFS nearly as well.

In terms of tool/system integration FreeBSD's ZFS is miles ahead of ZFSoL and this is unlikely to ever change. FreeBSD has its own userland that does not need to run anywhere else; updating it to integrate new kernel capabilities is comparatively easy. This can simply not happen for ZFSoL in the same way, since it would split this integration over a myriad of projects and then still require a distribution to make all the right choices.

With regards to OpenBSD, I think it was at the last EuroBSDCon in Stockholm during Henning's talk when he said that "ZFS was not the solution" or something to that effect. Quite rich, I thought, coming from a platform where software-mirroring and disk encryption is an either-or decision (at least was at the time).

Author is an OpenBSD user/dev.

A lot of these really aren't "defaults" but things necessary for ABI compatibility in the -STABLE branches. I was expecting more on poor sysctl tuning out of the box (and that is a real problem).

I will say that for FreeBSD 11, where we can break ABI again, it would be nice to ditch sendmail and I don't know why it is taking so long to do it.

I believe there's work underway to replace it with Dragonfly's dma.

dma is already in base, just not default

> (About SSH "none" cipher) The trade-off in performance isn't really worth it either, as the bottlenecks one might experience have a lot more to do with the MAC than the actual encryption.

Maybe that's just my experience, but I've used patched OpenSSH (scp, to be exact) that had "none" cipher on GNU/Linux, as a no-brainer tar+netcat pipe replacement for two PCs connected with a patch cable (so, no security was necessary), and it had saturated the link well. Default cipher suite ate the CPU and gave terrible performance. So I doubt the author's statement about the worth.

Pkgng and poudriere can very neatly be used in conjunction. You can use pkg to fetch and install all your binary packages from FreeBSD in the same way that apt-get is used in Debian. Most people will do just that.

But, if you'd like to have some ports built by yourself with special options, you can setup a poudriere builder and tell it to periodically make the ports you're interested in. The ports are compiled and packaged into pkgng packages. The final result is an additional private repo which you can totally use along with the official FreeBSD one.

I've heard time and again that you should either build everything from ports of install pkg binaries? I believe it's because of different use flags (in Gentoo lingo), so maybe you mean that one would build everything privately in a consistent poudriere repo with personal settings and only ever install packages from there. Is that right?

Uh… no? Unless you really customize all the options I guess. There's no reason to rebuild the exact same package you'll get from the repo.

E.g. I install all firefox's dependencies from pkg, then I build firefox from ports with the GTK3 option. Same with packages that use openssl (I use libressl). Never had any problems with that.

As floatboth said, there's really no reason to build every minor package by hand. Only those that you want to change the config or their dependencies.

You can mix and match. The only problem comes if you have flags in a dependency that don't match the flags in the package pkg wants to install. A bit bothersome, but it allows you the best of both worlds.

Last time I checked, poudriere and other similar tools didn't have the option to ONLY build ports for which you have customized options, i.e. fetch their non-customized dependencies from pkg repos >_< That was possible on Arch Linux with yaourt… back when I used Arch as my primary OS, and that was when the Eee PC 900 was still relatively new.

You can specify poudriere which packages to build, it does not have to be all of them. This is in addition to the custom make.conf and options files. The resulting repository catalog will contain only the packages you specified, plus all their build- and runtime dependencies.

What it can not do is infer the list of ports from the custom make and port configurations.

Yes, that is correct. But this isn't a characteristic of Poudriere, but of FreeBSD ports in general. If you try to build a port and it has dependencies, it will build them as well. Doing pkg search -f yourpackage will fetch the build options that were used when building the remote package if I remember correctly. So one could theoretically ascertain what are the local Poudriere and the remote repo build options.

And yes, I agree, it would be more efficient to just download the packages if the default options are unchanged. But in practice I hardly notice, because for most packages the dependencies are not too deep.

Besides, doing all the dependencies yourself adds a level of consistency. If your package depends on libwhatever.so.6 and there is a major/minor version change in that library, that might introduce a subtle but important API change, I guess you would rather prefer building libwhatever yourself to make sure that everything will work out ok.

Best default ever: https://shiro.apache.org/static/1.2.2/apidocs/src-html/org/a...

See DEFAULT_CIPHER_KEY_BYTES

Because no major companies forgot to change it when they used it?

This reads as unnecessarily nasty and mean-spirited. Sure, I am biased, I am a FreeBSD developer.

i'm a FreeBSD user since 4.3 or 4.4, and to me it reads quite fine. sure, the frustration shines throught, but he's got a bunch of valid points there.

The OP certainly wasn't trying to be neutral (wikipedia-style), but most of it reads as 'it is 2016, do you know what your operating system is (not) doing to protect you?'

I find it direct and nasty, but not mean-spirited. I think he does that because he cares about this, and hasn't managed to get his message across.

And I think he has good points. In particular, ports running make as root makes every buffer overflow in your C compiler, linker, and whatever other tools build scripts run a potential root exploit. Yes, other security measures such as pledge can decrease that risk, but why run the risk at all?

Lower your defenses, consider the issues, address them.

My personal aphorism (for at least 20 years now):

Warman's Law: That which _can_ be configured _must_ be comfigured,

Corr.: Defaults Aren't.

Impl: running any program on its defaults will get you in trouble somewhere down the line. This is no different. Configurations are there precisely to accommodate each users' individual needs, and we are not all the same. Typically defaults try to achieve useability by naive users, and usually do so in a way that is wrong for the sophisticated users. As well as often not chosen very well and really wrong for everybody. Then there is code written by naive programmers who code the naive default and do not provide any configuration because they are unaware of any other way to use the system. And the other extreme of course - Windws anyone? Multiple places to configure different aspects of a specific vehavior, and selection dialogues that "help" by not showing sub-options not used by the current settings, making it impossible to know the full set?

At least the /etc paradigm lets us get a canonical view of everything, explorable with a simple text editor. This article actually shows the advantages.

"I don't know anythng about IPFilter, nor do I know anyone who uses it, so we'll pretend it doesn't exist."

If alternatives exist that would address the author's complaints (and they do), but he doesn't know anything about them or anyone that uses them then does he pretend they don't exist? What do you think?

A lot of good points, but several ignorant ones, too (what's wrong with tcp_wrappers or PAM? also OpenNTPD is _not_ a drop-in replacement for ntpd). And if the author is someone coming from OpenBSD, they ought to know at least something of the history behind IPFilter, as it is the raison d'etre for OpenBSD's pf.

Speaking as an infosec guy myself, I'd dearly love to see the TrustedBSD MAC Framework or the Audit Implementation (OpenBSM) being used by default. I'm surprised the author didn't mention it.

Has the MAC framework reached sufficient maturity that root need no longer be especially privileged, but instead just-privileged-enough?

(this would attenuate many of the OP's complaints)

11/10 on arrogance and narcissism.

The defaults about swap and openssh are reasonable for high-performance networking servers, which is what FreeBSD is for. Yes, compatibility and performance matters. Ports are supposed to be installed before server is put for production, and at that time running shit as root is not a big deal.

BTW, OpenBSD, with all respect for code quality and attention to details is nowhere near in networking server performance and stability. Once I made an OpenBSD/spark64 firewall, which, I think, is still in production, but apart from packet filter and DNS server it was hardly usable for anything.

I am oldfag^W^W remember FreeBSD 2.0

Reply on news.ycombinator.com