FreeBSD – a lesson in poor defaults(vez.mrsk.me) |
FreeBSD – a lesson in poor defaults(vez.mrsk.me) |
###############################################################################
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?
Even if one asks the question and arrives at "yes, I trust this program", there is value in eliminating the question itself.
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.
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?
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.
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.
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.
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.
See DEFAULT_CIPHER_KEY_BYTES
Because no major companies forgot to change it when they used it?
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?
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.
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?
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.
(this would attenuate many of the OP's complaints)
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
- Virtualization (jails, bhyve)
- Filesystems (ZFS)
- beadm (which requires ZFS)
- Linuxulator
- LLVM
- Arm support
- The handbook
The friendliness of the FreeBSD community is why I wouldn't even consider going over to OpenBSD.
I have not used beadm though - what's the kicker?
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).
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.
What it can not do is infer the list of ports from the custom make and port configurations.
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.
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.
Absolutely! I didn't mention the man pages because all BSDs have really good ones and they all use OpenBSD's mandoc these days.
You're protected from MITM and hacked repos, but what if the problem is in the official repo?
Defensive programming is useful.
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)
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.