Live data from Hacker News

Maybe you shouldn't install new software for a bit

xeiaso.net

481–490 of 497 posts

Re: Maybe you shouldn't install new software for a bit

#481

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…

While not receiving a response isn't ideal, I note that we actually have two secteams: secteam@ and ports-secteam@; something like luatex should go to the latter, but their level of activity has been kind of hit or miss in my experience. Curating security issues in ports is kind of hard due to the size of it and we probably more often than not end up getting hit with patching things a little after disclosure because of it.

Re: Maybe you shouldn't install new software for a bit

#483

Earlier 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.

Do you honestly think stackghost doesn't know what the "D" stood for? They were making a point, not seeking information. My answer directly responded to the point they were making.

Re: Maybe you shouldn't install new software for a bit

#484
post #42

Earlier 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.

> 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

#486
post #455

Earlier 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.

Where are you messing with userland-only options? In my experience a Linux distro not only comes with a kernel, it's almost always a kernel specific to the distro. So I don't understand that reason.

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

#487

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…

https://news.ycombinator.com/item?id=48077971

Re: Maybe you shouldn't install new software for a bit

#488
post #39

You 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.

That's why I only do passwordless sudo ;)

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

#489

Earlier 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…

> "capability based programming languages fix everything"

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

#490
post #191

Earlier 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.

How else are you sure your team does not conflict with itself?

/s

Post reply on HN