Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.
We know some things are *objectively* better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake.
Just the people who are stuck to 1970's way of doing things and fear new things oppose sandboxing.
I get that some packages do actually have sandboxing, but unless it is mandatory and enforced I feel like I'm better off avoiding the ecosystem entirely and dealing with app isolation myself, using containers or VMs.
It may be too hard today. But that's less "Flatpak is a security nightmare" and more "we're not using the features we have very well yet". I feel like some people expected 100% targeted profile for each app or will declare sandboxing a failure. This stuff will take years.
- have complicated permissions that users misunderstand or can be tricked into misconfiguring through inattention, misleading user interface or fatigue
- aren't actually sandboxes because the isolation they claim isn't actually achieved (I usually call these "security holes")
- are used to artificially force markets (e.g., Microsoft's UWP)
Other than that, they're great.
Signed, cranky, pre-morning-coffee programmer speaking ex cathedra from the 1970s
Absolutely. That's why the comment that makes you characterize me as a luddite explicitly referred to the "sandbox everything wave".
Sandboxing has its place. Sandboxing everything (i.e. the "Flatpak way") is what I'm commenting on.
Flatpak, for all of its many faults (and there are a lot of them), is still a strict improvement over the current security model running on most desktop Linux computers. Sandboxing native applications (even partially sandboxing them) is objectively better than the status quo.
It is embarrassing that the Linux community is still having this debate. It is exhausting, it feels like the community has to be dragged kicking and screaming away from a 20-year old security model that every other platform has moved on from.
https://www.acsac.org/2002/papers/classic-multics.pdf
I don't understand how you can honestly, truly say it's "technological ludditism" when it's clear that nobody in this thread is opposing the features that Flatpack and Snap claim to have, which in many forms predate UNIX and predate Flatpack/Snap -- they are just opposing the half-baked implementation that Flatpack/Snap have created.
Because that's what we do on the web. Every app only has access to it's own files and 10 or so standard clipboard formats (and ONLY through the clipboard).
There are security models that allow sharing files that don't give direct access to the entire filesystem. A word processor might need access to my Documents folder, but I might choose not to give it access to anything outside of that folder. Or I might choose to tell it it's been given access to a Documents folder, but really it has access to a VFS mount that is a composite of several folders inside of Documents including some shared folders outside of Documents.
This kind of "portal" idea is incidentally also what browser manufacturers are considering as they start to explore offering native file access[0] (although this is obviously an area that in browsers needs to be approached with a lot of caution). I don't think Google's proposal is the best way to handle this, I think it could be better. But it's still better than what's happening on desktops with native apps.
This has been the sandboxing method or choice since the 70s. Filesystem permissions were designed around users and groups, and now everybody's trying to bolt on intra-user access control lists and wondering why the experience sucks so much.
Create a `browser` user. Add yourself to the `browser` group. Maybe give `browser` read access to an area in your docs folder for convenience. Modify your browser launch script. Done.
In the default settings other users could not access the X server. I forgot how that is changed. I changed it once and now just copy the config
Biggest is getting the sound to work. Pulseaudio in system mode should do it. Although it is not recommended to use. And now my headphones do not work reliable anymore. Not sure if it is caused by system mode or by another setting.
And sharing files. Good that the browser cannot change my files, but it works both ways. My normal user cannot change the browser files, sometimes not even access the downloads.
That sounds funny given the facts about Flatpak.
App has access to its own config/cache folders, and is implicitly and temporarily granted access to a file or directory on a process-lifespan basis when that file or dir is fed to that app through the file browser or through the application's "open file" file dialog box.
Possibly something more liberal could be granted for read permissions for like a gallery app or a music library thing, but that's what I'd expect for write permissions.
I’m not sure if it’s temporary or process-lifespan basis, but AFAIK macOS’s sandbox does have a model where the user must grant access by using the system-provided out-of-process file dialog for the application to be able to access the files.
Pretty interesting. For an example, try renaming a file in MS Words by clicking on the document icon — you’ll see MS office asking for permission for the access of the parent directory. (Apple does provide rename functionality by it’s APIs, but MS Word does it by it’s own, which requires the permission.)
I skimmed the article and it looks like one thing they do is have a daemon in the background to intercept data in and out, when they could just make user groups and normal file permissions.
I know it's almost a meme at this point, but plan9 had a great system for this.
You were able to define a filesystem layered on top of your own, exposing and linking files/folders however you please to any process.
So say you have a web server. You can make a layer that only has /www and /configs, linked to some folder in /var/foo/webstuff, and /etc/fooserver/configs or something.
No reason why you couldn't standardize an interface for systems like flatpak to safely use your filesystem.
What is wanted is some system that allows one to run untrusted sofware in without fear of it compromising one's system. — the problem is that the set of software that can be so ran is smaller than expected, as most software by design is capable of making changes to one's system, as one typically uses software for such tasks.
A text editor that cannot edit every file in one's home directory would be rather useless, but in doing so, it is of course capable of completely destroying one's system as well.
The dream of being able to run “entrusted software” is not a very realistic one.
Spot on. Distros exists for good reasons: you need someone to configure things to work well together and manage security for you.
Including sandboxing: it's being already done with system daemons by systemd and for applications by firejail and similar.
Desktop users want the newest version of their UI apps and don't care so much about stability. Ideally, the developers of e.g. Inkscape would offer the newest version on each Ubuntu version via apt, but that does not seem to be feasible.
I am no Arch user myself, but I think a rolling release is much more suitable for desktop use. I don't have the feeling most people use Snap/Flatpack for their sandbox, but much rather for getting a new version of some software.
Canonical started developing sandboxed packages for Ubuntu phones ("click" packages which evolved into "snap" packages). At about the same time, Canonical was interested in getting other big distributions (RedHat, Suse...) to align on what software (kernel, glibc, GNOME, KDE...) to offer LTS on together, but there wasn't too big of an interest from other distributions (and tbh, I think that's a good thing: upstream open source projects would be strong-armed into caring about only a few versions that monopolist distros decided to base their LTSes on).
It is my guess that Canonical has (post-phones) invested in snaps to reduce the burden of maintaining the desktop and trying to earn some money in the process through the Snap Store. Flatpak seems to be Red Hat's slightly more open response that quickly followed.
The only benefit of Snaps/Flatpak for delivering newer versions of apps over just simply statically compiling everything into an app is that some of the things are shared between snaps (like frameworks, glibc...). You still get all of the same problems (theming, fonts,...).
That's the case for everyone I know (though they mostly use appimages)
[Citation needed]. Can you imagine telling this to someone who is about to present on a conference call, but zoom updated automatically and fails to start now?
I imagine MS has crunched the numbers at some point, and decided that the amount of lost work and interruptions due to forcible updates (especially contrasted with the benefits of updates) is not causing a significant number of people to ditch their OS for a competitor.
I'll answer my question: Companies make decisions on the margin. They don't care that they have 85% of the market. They want that next percentage point.
The users who might switch to or from competitors are precisely the "swing voters" they have to consider.
Any app that needs to save files in your home directory, which all the traditional apps do (Gimp, Inkscape, *Office...), has to have r/w access to your home directory (duh).
So I would venture to say that this is all misleading marketing, which is mostly what the OP complains about too.
It all boils down to the same discussion we had 20 years ago: Linux proponents talked about how much better it was when it comes to viruses because only your $HOME would be affected, somehow missing to realize that in mostly single user desktops, that was the only thing anyone really cared about.
(I've exclusively used GNU/Linux systems since 1999, but not for made-up reasons like that :))
Flatpak/snap model is the one where app controls your data (which allows them to only need access to a certain subdirectory of $HOME—think Steam or Spotify), instead of allowing you to group files related by topic instead.
And that's exactly the model I don't subscribe to :)
Of course, this would be a considerable effort. But it's probably where we're going.
Somewhere I've got a screenshot of a Linux system I had with half a dozen applications trying to open a file. Each used a different GUI framework or widget toolkit, each of which had its own file dialogs, and so the user gets presented with half a dozen different file choosing UIs. It was completely ridiculous.
Making the UI suck less was not a good enough reason to get any of the major GUI frameworks to support separating file choosing from apps. Maybe improving security will be a good enough reason.
The problem is what haplens when the program does not use standard file choosers, file APIs, etc.
Suddenly, it's now on app developer to support the packaging system and not the other way around.
macOS can get away with solutions like this because they control the kernel and userspace but on Linux it’s a much tougher problem.
It wouldn't surprise me however if sandboxing is only a good model for GUI not console app.
IIRC the Windows 10X approach will be to put all non-sandboxed apps in the exact same environment.
I use a messenger installed via Flatpak. So whenever I receive a file in it I cannot save it anywhere outside my Downloads folder. So every single time I then have to open a file manager and manually move the file somewhere else. Similar for the other way around - I have to copy any file I want to send into either ~/Downloads or ~/Pictures. Not a single other path is visible or accessible, if I click on "Desktop" in the list of favorites nothing happens. This is confusing and annoying for me, this would be super confusing for a user who doesn't know and care about file permissions.
I like flatpak as it can nicely fill gaps in official repositories whitout being bound to a single distro family once again. But honestly I understand why apps would just go "allow all", because anything else drives the user insane the way it is implemented now.
[0]: https://flathub.org/apps/details/com.github.tchx84.Flatseal
I see flatpak more as a distro independent package format than a way to secure my system.
Even a horrible and annoying pop-up dialog saying something like "file access error" would be better, at least it would be easier to google.
Assume that you are running Steam as a flatpak and you want to add an extra drive to store your Steam library on and you have your extra drive already automounted inside your home directory and the correct flatpak permissions set, Steam will not find it anyway.
You have to use a mount point outside of your home directory to get that to work.
The response article did also note that the most popular flatpak apps are often ones that really need filesystem access in order to function properly, e.g. an IDE, an image editing program, an audio editing program, etc.
It's really hard to conceive of how these programs would work without some of the requested permissions. I remember the hazards of trying to get a proper IDE on ChromeOS some years back because of Google's own sandbox restrictions on allowing extensions to access the chromebook's filesystem. IIRC there was a company that even created "cloud-IDE" environments to get around this limitation.
Also, it could integrate with the open file dialog and only allow the application to access files selected by the user, and nothing else. That would be tough because the developer would have to integrate with flatpak APIs, and I don't think flatpak is big enough for developers to care. But that would be ideal since it's safe but also not annoying.
For GTK apps, they don’t need to do anything different, as GtkFileChooserNative[1] is recommended for non-sandboxed apps as well. GtkFileChooserNative has glib call the D-Bus API (which is proxied inside the sandbox) for the FileChooser portal[2]. The backend running outside the sandbox (xdg-desktop-portal-gtk for GNOME/GTK; there are also backends maintained by KDE and wlroots developers) shows a file chooser and makes any file (since March 2020, there is also support for folders) selected by the user available inside the sandbox using the Documents portal.
Also the portal APIs are not specific to Flatpak. They can be used by any sandboxing framework that wants to benefit from the work already done to integrate them.
Some apps don’t use GTK or Qt, some apps (like GIMP) still use GTK 2, which doesn’t have GtkFileChooserNative, and some apps haven’t been ported from GtkFileChooserDialog to GtkFileChooserNative (or can’t be ported yet because of missing features in the latter). And the Documents portal doesn’t work perfectly for all use cases: There are issues with getting notified when a file is modified externally and with getting the path of the file outside the sandbox (to display it to the user, if that’s desired).
[1]: https://docs.gtk.org/gtk4/class.FileChooserNative.html
[2]: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
And a couple of sentences after it goes on to explain that it’s not too many because most of those 23 need those permissions.
I think they are, simply based on the fact that we can run untrusted stuff inside VirtualBox (and with quite good performance).
It's really not an issue with flatpak itself, it's the maintainers who give permissions that are not restrictive enough. It's understandable because it makes it easier to package and maintain.. but it also kind of makes the whole concept useless.
What I personally want is apps which are as, if not more restricted than mobile apps.
For example, OP says:
> Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions
The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many.
I haven't used Flatpak (or Snap) before, but my impression of the technology was that it isolates apps and strongly sandboxes things so if you accidentally run something malicious, you're covered. But that doesn't seem to be the case, really. I get that this is a hard problem, and some things aren't even possible to do on X11, but then don't leave people with the belief that you can do all these things.
The response also says:
> Some directories, like ~/.local/share/flatpak/overrides, are blocked. Even if they have home or host access, they will still need explicit permissions to get read-write access to the blocked directories. Doing this with .bashrc, .zshrc and other shell configuration files would be very useful from a security standpoint to prevent sandbox escape.
That is just an awful approach to security. You need to deny by default and selectively allow, not allow by default and selectively deny. Applications do not need explicit permissions to get r/w access to blocked directories; they can simply append to ~/.bashrc or whatever, and bam, they have "permission".
I'd heard some bad things about Snap, but looks like I'll be staying away from Flatpak as well.