back

by zorked·6y ago·view on hn ↗
Isn't the sandboxing a good idea though? It feels that Linux got caught in the past and is actually one of the least secure OSes out there, and what keeps it safe is just its small desktop market share.

Disclaimer: I never used snap and don't use Ubuntu.

10 comments
Flatpak gives you a sandbox, and has basically skirted around any shortcoming of Snap (faster, open, extensible, adopted by every other distro, doesn't pollute /proc/mounts)
Flatpak refuses to respect the hosts value for XDG_CONFIG and HOME, making it impossible for some applications to share your configuration.
Flatpak's sandboxing is an absolute joke and entirely voluntary.
At worst the "joke" sandbox value of flatpaks is the same as deb/rpm packages and snap "clasic" confinement. So as a user, you don't lose anything security wise by moving to flatpaks.

Flatpak, as well as snaps through clasic confinement, allows the developers to "escape" the sandbox because they know that they don't have all the permissions required to provide feature parity with deb/rpm packages. Another reason this is needed is that application developers are not writing their applications with flatpak compatibility in mind. However flatpak is going in the right direction.

Mobile operating systems have proven the value of sandboxing apps.

> is an absolute joke

Please elaborate.

> entirely voluntary

Fedora Silverblue would like to disagree. And in any case all parties know it's still in flux, but the stable parts are stable in my experience. I would not want something like Snap or otherwise immature forced down my throat.

Entirely voluntary in the sense that flatpak enforces sandboxes which the application tells it to enforce. If the app asks for full system access flatpak doesn't deny that. It kind of destroys the purpose of a system built to run third-party code. If I download a malicious app from flathub or some other repo which asks for full system access flatpak doesn't do anything in the name of security.

Note: I'm not making a value judgement about flatpak's sandboxing, merely describing it to the best of my knowledge.

Enforcing permissions and auditing third party code are two different things. The point of app permissions is that when you know an app should never do something, you constrain it from ever doing that. Then if it has a security vulnerability, it's limited in the damage from the resulting compromise.

The people configuring the sandbox should be packagers that you trust. The upstream developers might provide some recommendations to the packagers, but if it's obvious that an application shouldn't need a permission, it shouldn't have it.

But permissions can't save you from an actually malicious app. Constrain it from accessing the camera and it will still be using your device to host pornography. Constrain it from accessing the filesystem and it will still run up your electric bill mining bitcoin. You either need to trust the developer or you need to get the app through someone you trust to have audited it for you.

I don’t want the sandboxing to be mandatory! Some software inherently doesn’t work in a sandbox, or works less well. A good distribution format should still cover those use-cases, the user just needs to be informed about the capabilities of what they install. Especially on Linux, which is supposed to be about user-empowerment.
None of the flat pack apps I’ve used on Pop_OS work correctly / as stable as installing a deb directly.

I’ve not been impressed at all.

I guess just to provide a counterpoint, I can't remember having had any issues with flatpak on Pop!, including both open-source apps and proprietary ones like Spotify.
How about zoom? Was the worst and completely unusable for anything more than viewing a meeting.
No issues for me--I've run Zoom pretty regularly, including participating in some fairly large meetings, plus screensharing, etc.

Occasionally I need to replug my headset in at the beginning of the meeting to get my voice audio working, but I'm not sure if that's actually an OS issue or not. Either way, it's never taken more than a couple seconds.

YMMV. Firefox is the golden standard, at least on Arch Linux. Never have I noticed it was running on a sandbox. I run Discord, Spotify, Thunderbird from Flatpak without any issue either.

Visual Studio Code is a regular package, just because its use case it not really suited for a sandbox (access to system binaries, libraries, etc.), but I honestly haven't even tested its Flatpak version.

VSCodium flatpak works fine for me. The caveat is that I use the operating system's terminal instead of the one from VSCodium (for things like make test, python environments, etc). VSCodium's terminal operates on a sandboxed environment and I haven't bothered to figure out how it relates to the OS environment that I get from the terminal app.
You set your shell as some wrapper which allow sandbox escape. It works for shell itself, but then you need to apply it to all external utilities extensions use as well and it gets annoying.
Interesting, are there any examples on the internet for that process?
The problem with flatpack is that many apps don't really run in a sandbox. Or at least not in something with isolation features which you might expect from a sandbox.
To be honest, to me the selling point is not the sandbox, is the reproducible environment that's common for all distributions, which is a first in the Linux world, the sandbox is just the icing on the cake.

The other day I pushed an update to some flatpackaged app, and guess what, it's available to all Linux users. Packaging has become incredibly easier for third parties with these kind of technologies.

Access control is a good idea, sandboxing on top of it is saying its too nuanced a problem so heres a kitchen sink of overhead.

Linux has had some of the best software security through MAC (SELinux, Apparmor) and cgroups. The problem is that there is no culture in free software to actually write specifications at the point of development, it generally falls on distros / maintainers to try to sort out MAC profiles or cgroups restrictions on a per-package basis.

That is why the packagers largely went with the Snap / Flatpak route of saying screw doing the grunt work heres a total sandbox with all the libraries built in.

It would be great if we could convince the whole ecosystem to start provisioning access specifications for libraries and binaries so upstream could start building apparmor / selinux profiles from provided files rather than having to do learning mode auditing that drove distro maintainers to not even bother.

It's not.

For instance: the Pinebook Pro just got gles3 support via upstream mesa, but all the flatpaks with mesa haven't or won't update with any alacrity.

Users are left having to abandon sandboxing in order to get necessary updates.

Pinebook pro is using an arm64 cpu instead of an x86. That creates a big list of problems that you don't have on x86 because that's what all linux desktop developers have (mostly) been targeting.

As one example, I was surprised to find that the tor browser doesn't have an arm64 build :o

I've installed a few dozen AUR packages that only needed aarch64 added to the arch list. I think only one, syncterm, required any other modifications to build and even that was just setting a preprocessor define (__arm__).

Thus far, it's my favourite laptop purchase ever. Beats the feeling I got with the IBM X series or the Ti Book. It's light, zippy enough, great Linux hardware support, and totally silent.

Even if you did swap a symlink to upgrade to GLES3, all the apps will still call the GLES2 functions. No matter what, the devs would have to go back and rewrite their app to actually use the new features.
Many apps detect GL level and adapt renderers accordingly.

Still, it's not just graphics drivers: there's the oft-cited security patches, but also features for user-facing interfaces; Ie, an update to a URL parsing library might add additional codepage support transparently to an app that uses it.

The freedesktop runtime updates Mesa faster than most distributions. The current version is 20.1.5.
And Arch let me build and install git HEAD, so I'm using 20.3.
Forcing Arch model on eveyone is a perfect way for Linux to forever stay minority platform. There's a reason why most people do not run rolling distros.

Might be nice for hardcore fans, but good luck supporting anything there.

There is a very real shift happening from Ubuntu to Manjaro.

If the sandboxed app package model is what you desire then there's already a great and popular Linux distro for you: Android.

I've observed a lot of recent Manjaro adoption lately (I don't know what the real numbers are). Anecdotal, but in my social circles I'm seeing people moving from Ubuntu to either Manjaro or Arch.
Don't be surprised when all the mainstream distros switch to sandboxed app model as the preferred one. Distro-based packaging of the entire world is hiting the not enough manpower problem today and eventually will be eventually relegated to super fans distro only, with similar status as Amiga has today.
What is Manjaro?
Best way to describe it is: a user-friendly version of Arch that is based on the AUR (Arch User Repository).
Why would you expect to have a git snapshot shipped as the official freedesktop flatpak runtime? Could you not build your own freedesktop flatpak runtime using mesa git head?
> Could you not build your own freedesktop flatpak runtime using mesa git head?

It was easier to build it and not use flatpak.

Almost no apps are actually delivered via the Apple or Microsoft app store. Apps from outside app store apps aren't obliged to use the sandbox although mac apps can and they do have a line of defense against unsigned applications. Its harder but not impossible to end up pwned by signed apps on mac.

The number one and two attack vectors have always been tricking users into installing malware and attacking old insecure software.

Distributing virtually all software via app stores substantially solves acquiring safe software and ensuring it receives updates.

Defense in depth is virtuous but Linux is already more secure than windows in the ways that actually count and unlike MS they are actually positioned to in the future sandbox software because its all already mostly coming from app stores.

You don't need snap-style distribution for sandboxing.
Containers, chroot jails and whathaveyous have existed long before snap came along. Like other have said, flatpak is a more sane alternative that doesn't impose idiotic requirements like systemd or x server.
> doesn’t impose idiotic requirements like ... x server

How are you going to sandbox graphical apps without knowing about (and having capabilities around) the system by which a containerized app would communicate with your OS’s graphics subsystem?

I mean, if you’re not going to run any X11-client graphical apps, it should probably be optional to have an X11 server installed; but either way, you’ll need the X11 wire-protocol libraries (“xorg-common” in most package repos) for the sandbox to link in.

> How are you going to sandbox graphical apps without knowing about (and having capabilities around) the system by which a containerized app would communicate with your OS’s graphics subsystem?

Wayland is the way forward.

> you’ll need the X11 wire-protocol libraries (“xorg-common” in most package repos) for the sandbox to link in.

Today, runtimes do contain client x11 libs. However, nothing in flatpak requires it and it is possible to phase them out in the future releases of runtimes.

> Wayland is the way forward.

Wayland has been "The Way Forward(tm)" for 10 years now.

That may be. But nobody in RedHat/Canonical/etc. believes that enough to put sufficient manpower on it to make it true.

> But nobody in RedHat/Canonical/etc. believes that enough to put sufficient manpower on it to make it true.

It is default display server in RHEL8. If that is not believing enough in it, I don't want to even know what would be sufficient to prove otherwise.

Right, sand-boxing should be made at OS-Level not in User-space.
> is actually one of the least secure OSes out there

Linux is one of the most secure platforms to run web applications on, however, because more man hours than I can comprehend were spent hardening that use case.

All of those hardening measures can transfer over to the Linux desktop use case.

For example, seccomp, cgroups and MAC can all be used to harden a Linux server, and they can also be used to harden the Linux desktop. It's just that no one has thrown the same billions of dollars at desktop Linux that were thrown at solving web application security.

If you really wanted to, you could run a lot of your software in unprivileged containers secured with seccomp.

>If you really wanted to, you could run a lot of your software in unprivileged containers secured with seccomp.

We've come full circle, because Snap does run software in unprivileged containers.

They are not the same thing, however, and the complaints people have about Snap don't stem from its use of unprivileged containers.
Not if it slows down things as much as it does, especially launching. What are you doing on your machine that things like apparmor and selinux (for app isolation) aren't enough? Just use a VM. Not everything needs to be sandboxed if it ruins the zen of interacting with your machine
Can’t you actually sandbox any app you want with chroot and cgroups yourself?
chroot is not the same as lxc (linux containers)

You can do very similar, but if it's a gui app, or has specific system dependencies there will be issues to work around.

Sandboxing is great in theory, but last I checked the snap daemon opened Internet connections as root. I'll take my chances with traditional Unix permissions over that.