51–60 of 67 posts
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.
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…
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.
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
Earlier quoted context omitted.
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.
You're protected from MITM and hacked repos, but what if the problem is in the official repo?
Defensive programming is useful.
Earlier quoted context omitted.
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.
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)
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.
Earlier quoted context omitted.
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
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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...