Hacker News Reader

Comment by kelnos | Hacker News Reader

Linux security (another desktop user here) is... fine? You can get pretty great security on it, if you want, by running Wayland instead of X11 and running all your apps via Flatpak or Snap (assuming you only choose apps that aren't intentionally allowed to break out of their sandbox).

And none of these things require Linux (the kernel) to change all that much. Hell, Android has decent security by running all apps with different user IDs and restricting the parts of the filesystem it can access.

Obviously your default Linux desktop install doesn't work like this, but some motivated individuals could do it, if they wanted. Writing an entire new OS is hardly necessary. Google just wanted something it could control, when it comes to Fuchsia. And they're the last company that I would trust to build an OS that doesn't end up being user-hostile.

View on HN

Flatpak and Snap are an inherently bad model; they break stuff and fail to secure other stuff, and their design means this will always be a game of whack-a-mole. And even if you were to Flatpak/Snap-ify all your apps (really? Would you run e.g. Bash that way?), you'd still be left having to run a bloated kernel to support a bunch of cruft that you weren't using. Starting from scratch with a clean interface seems like a better approach.

(Qubes, OTOH, is interesting; I see it as one possible path to the future)

> you'd still be left having to run a bloated kernel to support a bunch of cruft that you weren't using

Would you? Linux is, in fact, quite modular, and perfectly happy to not load things until asked to (often as a result of hardware being discovered or plugged in).

Why are they a bad model?

Sandboxing is a much better approach to security than the Unix permissions model, which is nearly obsolete.

> Sandboxing is a much better approach to security than the Unix permissions model, which is nearly obsolete.

That's an incredibly low bar. They're a bad model because the Unix API surface is huge and underspecified; there are a zillion different ways apps could potentially interact with each other. Some of them are giant security holes. Some of them are vital to some obscure corner of app functionality. Most of them are both.

I'm not talking about syscalls, but that in modern times everything of value is in your account, and computers are rarely shared.

So when you download a game your threat model isn't that it might want to mess with the kernel, but that it's going to steal all your data from your browser cache. Dealing with that requires some sort of sandboxing.

> I'm not talking about syscalls, but that in modern times everything of value is in your account, and computers are rarely shared.

Huh? No-one is advocating using user accounts for security.

> So when you download a game your threat model isn't that it might want to mess with the kernel, but that it's going to steal all your data from your browser cache.

Why do you think this contradicts anything I said? And what mechanism do you think it's going to use to do that? Maybe not syscalls in the narrow sense, but certainly via one of the "zillion different ways apps could potentially interact with each other".

> Dealing with that requires some sort of sandboxing.

Is this the "something must be done" fallacy? "We need some kind of sandbox, snap/flatpak are some kind of sandbox, therefore we need snap/flatpak".

There is more to them than sandboxes though. They also package everything, if there is a security problem in a common library you are vulnerable in each sandbox until it is updated so updates become a much larger hole.

Sure the problem cannot escape the sandbox, but in the end i'm more concerned with my data in the sandbox.

It’s not necessary to include every library inside the package. Flatpak packages use runtime packages like Gnome, Freedesktop and KDE. Those runtime packages already include libraries like OpenSSL,libpng, libjpeg, gtk, qt and are updated very frequently to fix the bugs in those libraries.

Yeah, but that's because Linux doesn't have a stable ABI, and really everyone does that these days.

Both Mac and Windows just dump a whole bunch of libraries into the install directory.

I think on Flatpak you can update the base platform package and have the applications use that automatically, so there's that.

Linux has a stable ABI for user land programs. For drivers the ABI is not stable, but drivers are not sandboxed in linux.

I didn't mean just the kernel, but the userspace libraries as well. So GNU/Linux or whatever you want to call that.

So it's either AppImage/Flatpak/etc or it's building a package per distro.

I think the world is destined to move to a microkernel OS eventually. I am just mad that there is not national level funding of sel4, which is audited and available today.

You can have secure monolith and insecure microkernel. It’s not a silver bullet, and security nowadays is really complicated.

> You can have secure monolith and insecure microkernel.

Superficially, that claim sounds reasonable, but I'd have a hard time substantiating it. There is exactly one secure microkernel ready for production use today, and zero secure monolithic kernels. There's not even a "here's how one could secure a monolithic kernel in principle" whitepaper.

> There is exactly one secure microkernel ready for production use today, and zero secure monolithic kernels.

I'd be interested to hear your definition of "secure", and why OpenBSD doesn't qualify.

OpenBSD mostly operates on a hobbyist's idea of security, where they just make up attacks to defend against rather than being systematic or actually keeping up with the outside world. (https://isopenbsdsecu.re)

Although professional security people are also rather bad at this and like to eg stack multiple cool-looking mitigations even if they break each other. (https://siguza.github.io/PAN/)

Okay, so what threat model successfully attacks an OpenBSD box and fails on... I assume the one "secure" microkernel is seL4? Since OpenBSD only defends against made up attacks, this should of course be very easy to demonstrate.

It's not "an OpenBSD box" but "an OpenBSD box running a typical amount of third party services".

There are some technologies that are so good they can fix everything, almost as if by magic.

Functional programming, micro kernels, RISC (or, depending on the decade, CISC), cryptocurrency, etc.

cryptocurrency has fixed nothing.

Your sarcasm detector is broken.

Microkernels work great for virtualization guests, yet they aren't taking off in this kind of low friction environment. I don't think there's a killer app for them that justifies leaving behind Linux.

Android (well, the Pixel anyway) does a great job of isolating processes by using SELinux and seccomp. You can have processes running as root that are still completely isolated away from most of the system.

Reply on news.ycombinator.com