Hacker News Reader

Comment by lmm | Hacker News Reader

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)

View on HN

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

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.

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.

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.

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

Reply on news.ycombinator.com