Alternatively, switch to an operating system like FreeBSD which doesn't take a YOLO approach to security. Security fixes don't just get tossed into the FreeBSD kernel without coordination; they go through the FreeBSD security team and we have binary updates (via FreeBSD Update, and via pkgbase for 15.0-RELEASE) published within a couple minutes of the patches hitting the src tree. (Roughly speaking, a few seconds for…
I'm somewhat skeptical here, because I notified the FreeBSD security team of a vulnerability a few years ago, and I never got a response, even after a follow-up email a few weeks later. To be fair, my report was about a non-core component, and the vulnerability wouldn't be very easy to exploit, but Debian, OpenBSD, SUSE, and Gentoo all patched it within a week [0]. That being said, I'm not suggesting that anyone shou…
Maybe you shouldn't install new software for a bit
481–490 of 497 posts
Re: Maybe you shouldn't install new software for a bit
#482Re: Maybe you shouldn't install new software for a bit
#483Earlier quoted context omitted.
That's more of a historical artifact. The BSDs started as just "BSD": a set of patches for AT&T Unix that were _distributed_ by Berkeley. Eventually the patches became complete enough to be an entire operating system. _Then_ the various BSDs that we know today (FreeBSD, OpenBSD, NetBSD, DragonflyBSD) all forked and became completely independent operating systems. For decades, FreeBSD's kernel and userland has been de…
This seems too long and it does not even answer the question. The question was specific, and the answer could be only one word long.
Re: Maybe you shouldn't install new software for a bit
#484Earlier quoted context omitted.
If you are switching to a BSD for security reasons, why FreeBSD? Isn't OpenBSD the super secure one? Sorry, it's been a while since I've looked at those projects
The person suggesting FreeBSD is a FreeBSD developer (Colin Percival - actually according to Wikipedia FreeBSD engineering lead), would be weird for him to suggest openbsd.
Okay. But the question isn't about him, the question is about the actual merits. And he's a good person to ask for a compelling argument about the merits.
If you ask Bill Gates why you should use MS-DOS in particular, not DR DOS, the answer is not "it would be weird for Bill Gates to suggest DR DOS".
Re: Maybe you shouldn't install new software for a bit
#485Re: Maybe you shouldn't install new software for a bit
#486Earlier quoted context omitted.
Distros are operating systems.
But operating systems are not distros. Less laconically, distros generally refer to the userland parts of the operating systems rather than the actual kernel. FreeBSD does not use the Linux kernel so calling it a distro, which typically refer specifically to Linux distros, wouldn't be accurate.
As far as Linux versus not Linux, "distro" feels fine to me for Unix systems.
Re: Maybe you shouldn't install new software for a bit
#487Alternatively, switch to an operating system like FreeBSD which doesn't take a YOLO approach to security. Security fixes don't just get tossed into the FreeBSD kernel without coordination; they go through the FreeBSD security team and we have binary updates (via FreeBSD Update, and via pkgbase for 15.0-RELEASE) published within a couple minutes of the patches hitting the src tree. (Roughly speaking, a few seconds for…
Re: Maybe you shouldn't install new software for a bit
#488You don't need a kernel LPE to root a Linux developer machine. Just alias sudo to sudo-but-also-keep-password-and-execute-a-payload in ~/.bashrc and wait up to 24 hours. Maybe also simulate some breakage by intercepting other commands and force the user to run 'sudo systemctl' or something sooner rather than later.
Actually now I use my yubikey to authentice so I don't have to type my password for sudo. Take that!
Re: Maybe you shouldn't install new software for a bit
#489Earlier quoted context omitted.
> If you can confuse or buffer overflow the FS process by sending it messages, you can then edit state inside that process you weren't supposed to be able to access, and as that process controls the security system for everything it's game over. The assumption here is that the FS is the root of trust for the kernel. (A claim I consider dubious, but what do I know about knowing things?) It's another way to say that if…
Ah, I'm not saying we can't have nice things or build more secure software. I think we can build more secure software! But the argument I'm responding to is one that I've seen many times over the years on HN and elsewhere, which is some form of "capability based programming languages fix everything". It's always posited as obvious and easy, as if merely saying "capability based language" is the only explanation requi…
There is some truth to this idea, though. Setting aside the unsafe boundary, (FFI, direct MMIO access, etc.) a capability system in a programming language would solve some kinds of these problems. Not all; it doesn't solve logic bugs when a capability is in scope.
> It's always posited as obvious and easy
I do believe it's probably pretty obviously true, by now. But not at all easy.
> Moving the FS out of the core kernel wouldn't change much though - if you have a bug in your FS code at runtime then you're just SOL even if everything is arranged in a Merkle tree.
Perhaps, but that's only because traditional file systems are global state. A capability system turns that notion on its head specifically because global state is really the problem. The combination of capabilities and user mode file access would be quite a strong isolation boundary. The bug(s) would have to be "trivially flawed" in a way that these subtle exploits are not.
> A threat model isn't the same thing as a root of trust.
Ah, I didn't say that. I said (roughly) that security relies on a strong root of trust for every thread model. I think the distinction is important. They are not the same, but the thread model can be completely ignored (because it doesn't matter) until the root of trust is secured. In other words, a weak root of trust fails all threat models.
> I don't think Apple or Microsoft care much about Linus' opinions tbh.
True. macOS and NT are (or were?) "microkernel-ish" the last time I was in those weeds. No idea how they've evolved since.
You've made some good points, as well. I see where you are coming from.
Re: Maybe you shouldn't install new software for a bit
#490Earlier quoted context omitted.
I worked for one company where we were super conservative. Every external component was versioned. Nothing was updated without review and usually after it had plenty of soak time. Pretty much everything built from source code (compilers, kernel etc.). Builds [build servers/infra] can't reach the Internet at all and there's process around getting any change in. We reviewed all relevant CVEs as they came out to make a…
You forgot case #4: Worked at a startup where the frontend team thought it was a good idea to use lock files during development, but to do a "fresh" install of all dependecies during the deployment step. And yes, they still thought they were doing the right thing.
/s