Flatpak – a security nightmare – 2 years later (2020)
flatkill.org
flatkill.org
I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.
Or when neither of the CVE links go anywhere.
Maybe I've understood how Flatpaks work incorrectly (please correct me if so), but the applications are ran in containers. So how would an attacker exploit CVE-2019-17498 on a Gitg? Its not like Gitg has a port open for listening incoming messages.
With ffmpeg I don't know if things like Chromium are actually using the flatpak ffmpeg or if they ship with their own libs.
Edit: when I wrote this comment only the first sentence of the parent existed.
They are not containers in themselves: if you feel this is pedantic, the way namespaces are used can make all the difference (eg. why you should not be running stuff in docker containers as root which can easily be used to get root on the host).
If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo. The biggest problem is that flatpak advertises sandboxing when some apps disable it but I imagine in the future we will get better UI around showing the user exactly what gets exposed as well as less permissions being given to packages.
True, and the same is true for flatpak given that the author of the package controls the sandboxing.
The only solution is to have 1 or 2 trusted packagers to review the package, including its code - which is what some Linux distributions do.
Furthermore, Debian does a long release freeze for the stable release and a lot of users test it. A malicious package might well be spotted.
Contrast it with the very lightweight vetting that is done by others.
If I have Debian apt archives in my sources.list, I understand the risks, just like a pure Windows user does: other than bugs, you might be affected if someone hacks Debian/Microsoft and that's it (or, of course, someone internal to them decides to do it).
Flatpaks/snaps are designed to be built by less-trusted parties and promise things they know they can't deliver on. Now I am suddenly asked to trust these external developers that they will be as adamant with security fixes, be non-malicious, etc. And flatpak/snap are trying to convince me how that's a non-issue "because sandboxing".
Sure, we here understand the underlying technologies so we can make our own educated guesses, but majority of the people who this is aimed at don't.
Since you also mentioned "add a new repo", there are some repos you can trust even if they are not the official ones. PPAs on Launchpad build from source packages, so you can always get the source first ("apt-get source package" after adding the repo). If someone is just bundling binaries and the build is a no-op, you can drop the repo right away. Sure, it requires some effort and you won't be checking every repo, but for sufficiently popular repos, somebody would be doing that.
It'd be ideal if apr grew support for limiting packages that can come out of a repo, so you'd have to whitelist when something new pops up ("hey, this repo has now introduced libc version X, and your libc is coming from repo main: do you want to allow upgrades from non-main repo to libc? [only once] [yes] [no]").
Both of them focus more heavily on the convenience of distribution than any user-facing benefits such as sandboxing.
If you're referring to the GNOME Software "Sandboxed" badge, it still indicates that there are some universal properties of the sandbox. (For example, flatpak apps live in their own PID namespace and cannot see what other processes are running on your system.) Also, there is a permissions badge on the right that does indicate the level of access you'd be granting to the app. (Full $HOME access is indicated with High, and a click on the badge tells you exactly what it needs.) There could be some work needed to do around guarding `.bashrc` and similar, though.
In addition, Flatpaks and Snaps are both served as repos - a `.flatpakref` for instance is just a reference to a repo. Using a `.flatpakref` to install software is like adding a repo to your sources.list, but in ways more secure:
1) Flatpak doesn't have the concept of install scripts (and doesn't have a way to install a setuid binary), so just installing an app won't cause a security hole. On the other hand, a `.deb`/`.rpm` can run arbitrary code as root in the install scripts.
2) Packages on Flatpak are scoped to the repo you installed them from - for example, if you request `org.gnome.Calculator` from flathub, another repo can't serve version 10000 of the same app and have users install it. If the same app is available on multiple repos, flatpak will prompt you and ask what version to install.
example output for `flatpak install org.gnome.Calculator`:
Remotes found with refs similar to ‘org.gnome.Calculator’:
1) ‘fedora’ (system)
2) ‘flathub’ (system)
So yes, I think the messaging in GNOME Software should be improved (hard for me to check on Ubuntu because it does not come with Flatpak support on by default).
Note that ".bashrc and similar" is a huge amount of files (just off the top of my head, .profile, .zshrc, .cshrc, .Xsession, .xinitrc, .ssh/config [for eg. ProxyCommand]... you get the gist).
TBH I don't know which I prefer. But I suspect the lack of security patches will continue to get worse and worse as time goes on.
You can also manually set permissions using flatseal to lock it down as much as you want.
Would be better if each process had its own downloads folder (it’s own file system namespace even).
Each flatpak app does have its own namespace and dir it can save whatever it wants to. Some packages like the MS teams one have been given access to downloads only so you can share files with people. You can turn off this access if you want.
Flatpak also has a thing called portals which let the program request a privileged filepicker so the user can select any file and the filepicker grants access to it for the program. The problem is not all apps are set up to work properly with this right now.
Sure, they are capable of locking it down better. But they haven't in 2+ years. It shows where their priorities are.
Flatseal I'll have to look into though, thanks! A user-controllable method is always a plus, and I do love sandboxes. Most apps need very little access, and locking them down prevents a LOT of kinds of misbehavior, intentional or accidental.
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.
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.
Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.
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.
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.
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.)
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.
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.
That sounds funny given the facts about Flatpak.
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.
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.
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.
- 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
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.
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.
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.
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.
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.
I think they are, simply based on the fact that we can run untrusted stuff inside VirtualBox (and with quite good performance).
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...
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.
I use Flatpak extensively and I fully agree with you and the author of the response that there is a need to balance practicality vs. idealism when it comes to (fully auditable) FlatPak apps, as well as FlatHub's overall approach and continual work within the desktop Linux ecosystem.
What's more, the fact that an entire domain was devoted to what could have been a blog post gives credence to the responder's notion that this is FUD which, while valid for discussion, is most certainly not beneficial to the FOSS community writ large.
Either way, from the article you linked TIL about Flatseal[0] so I'll be taking that for a spin!
To sum up the issues:
- We agree that write access to the entire home directory compromises any and all security, but we are aware of the problem and trying to fix it.
- We checked the claim of “Many of the popular flatpack applications still have access to the entire home directory,” and conclude that 23 of the 50 most popular ones do.
- We partially disagree that the “sandboxed” icon is misleading, because it does limit some things, even though we as per issue one agree that access to the full home directory gives malware carte blanche.
- We agree on the point that the outdated example library with a vulnerability used is true as stated.
- We agree with the issue, but we have a tool built that mitigates it by altering developers.
I hardly would say that this rebuttal amounts to showing “f.u.d.”; — it alleges no technical falsehood in the article, but at some points simply disagrees that it is as much of a problem as the article claims it is, not numerically in terms of facts, but simply disagreeing on whether full write access to the home directory is truly such a big issue as the original article makes it out to be.
> Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions
TheEvilSkeleton counts them and 23 out of 50 is not almost all, so that is a technical falsehood, albeit not one that invalidates the author’s point. There are other falsehoods that do invalidate the author’s points. This one, for example:
> Two years is not enough to add a warning that an application is not sandboxed if it comes with dangerous permissions (like full access to your home directory)?
This is wrong because GNOME Software did, before the flatkill author’s 2020 update, add a warning (which is missing from the author’s screenshot) indicating that the app has high permissions and can access all files and folders (it’s still described as sandboxed, which technically it is, just with the ability to escape the sandbox; further changes to GNOME Software to make this clearer are already planned). The author’s screenshot was presumably taken using an outdated version of GNOME Software; they should have checked more recent versions before making claims about what features developers did or did not add.
And here’s another falsehood:
> So I need to run multiple fcitx daemons on my desktop and switch between them as I switch flatpak apps depending on which fcitx libraries are bundled with that app
The flatkill author misunderstood the implications of the bug report (in addition to seemingly misunderstanding where fcitx comes from; it’s part of the runtimes, rather than being bundled with each app). The issue was caused by a change in Flatpak, fixed in fcitx, and there is no need for the fcitx versions to match going forward.
We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use. Forcing user interaction at worst raises awareness, at best prevents the privacy of individuals from being invaded.
The current strategy seems to be having outsiders packaging all the desktop software in to flatpak while disabling any sandboxing that gets in the way. This brings you to the same state as traditional package managers with little security, but it boosts the flatpak ecosystem and makes it ready for the average person. At that point app devs will be more aware of it and can build their apps to tolerate missing access to things and prompting for access.
Does it? From the flatpak state you have a far more clear path towards a sandboxed destination.
The only real problem is that the Gnome Software program lists these programs with a green "Sandboxed" badge when the app may have anywhere from full sandboxing, to literally no sandboxing. I am certain this is not an intentional misleading feature because Gnome Software is hardly functional and need serious work across the entire program.
I use it to find software and read reviews, but never install. I always use the terminal for that.
1. Gnome Software does not tell what the package name is for deb, flatpaks, snaps etc
2. Gnome Software does not say what type of package it is (deb, flatpak, snap etc) except when it’s multiple choice.
3. No overview of dependencies.
4. No information what is happening during install.
5. Buggy installation, common case, click on Install, nothing happens, click on Install again and get warning “hey it is already installing you fool!"
Not everyone is comfortable to use the terminal, fixing Gnome Software should be a high priority for distros.
The current mockups[1] for a UI refresh of GNOME Software have the “Sandboxed” badge and the permission details replaced by a context tile giving an overall “Safe”, “Potentially Unsafe”, or “Unsafe” rating, with additional indications and a safety dialog giving the full information. The ratings are determined from the permissions as well as license, whether the runtime is no longer supported, and whether the source is known.
[1]: https://gitlab.gnome.org/Teams/Design/software-mockups/-/raw...
"Enhanced Sandboxing (Warning: This feature is experimental, and may cause issues for some apps.)" or something of the sort.
See also threads bellow; people complaining that the Signal client can save only into ~/Downloads.
If you learned something that is interesting or useful to you, then great.
Most people here comment on something they have exactly zero idea about how the security model works, how the transition (i.e. holes in the sandbox and the reasoning behind them) works and what is the intended end-result (portals).
Same underlying reason, except it is worse, because it is in the quadrant "they think they know, and they really don't".
The flatpak portals are trusted system components, that work outside the sandbox and can present some choosers, where the user picks what will eventually become accessible inside sandbox, if the user agrees (whether files via file choosers, microphones, cameras, desktop sharing, whatever). The sandboxed processes talks to the these portal via IPC (dbus, normally).
The thing is, that outside of standard gtk3 and qt5 apps, nothing else uses portals yet (and gtk3 with qt5 do that at framework level, so it's transparent for the apps). You cannot sandbox random electron app, for example, and expect that it will work just like it worked when it was installed via deb or rpm. And with files, it is just not single files (document apps are relatively easy), but imagine opening project file inside IDE or playlist inside media player: the project or playlist was picked by the user and can be opened by the app, but it contains references to other files, potentially hundreds of them. Can you imagine asking the user to confirm opening each and every one of the hundreds of files?
And then there were people complaining that their locally installed SDKs cannot be used from sandboxed IDEs. Sigh, that's kind of the point...
No, and expecting that to work is obviously ridiculous. This type of problem needs to be solved in a way which requires no changes at all from developers, or it will almost certainly go nowhere.
Maybe some antivirus etc products manage to seemingly do things like this on Windows platforms, but they have generous support from the platform developed over decades, are executing custom 3rd party kernel drivers, are unhindered by opinionated kernel developers blocking the feature due to their distaste for these hacks, and the resulting system is still unsound and rife with stuff like TOCTOU vulnerabilities, and the prompts are not intelligible to nontechnical users.
> Oh and reverse engineer the high level intent of the user / application far enough to present an intelligible question to the potentially nontechnical user.
I don't believe that this is such a big problem, since Android is pretty explicit about this - a camera app asking for access to my contacts will simply get denied and will promptly be uninstalled.
Re Android, it was designed from the ground up for this (the camera app request is even called "Intent"). So it's not really solving the question of running unmodified applications.
This happened years ago. Linux is way behind.
1. https://docs.flatpak.org/en/latest/portal-api-reference.html
Anything that tweaks on that, most notably Electron, will not use the portal
Also, if you want to review or change these settings, you can use Flatseal[0]. Arguably, it should be installed by default.
The problem with flatkill.org is that it leads to users rather downloading a random deb off the internet or an AppImage than using Flatpak, which both have worse security stories.
The annoyance doesn't come from the security, it's from un-refined UX.
In 2021, UNIXen are not as isolated as before. A lot of closed source software is creeping into the ecosystem. I'm not against that, but being able to limit them to sandboxes is a good thing IMHO.
I run VMs for such software, but a lighter weight solution is may prove more useful for some scenarios.
From that angle if the permission dialogs bothered you then you could just recompile flatpak to unconditionally approve all dialogs. (Maybe there is even a setting for this already?) Of course as a sibling comment has said, this would be pretty dangerous, almost equivalent to using windows without UAC, or sudo with NOPASSWD.
Parent here. Whoa, you're reading too deep into that. How do you think that I envision such a future? Even I didn't know I've envisioned such a future.
If I had time to implement such an elaborate subsystem, I'd do it as a user-configurable kernel level interface. Like a more user-configurable, more flexible version of SELinux or AppArmor.
The first thing I'd implement would be a global on/off switch, too. I've seen and worked in enough projects where keeping it on was the only sensible choice, and I know enough that some people (incl. me in some scenarios) would like to keep it turned off.
For clarity, I neither support snaps, commercialization of Linux distributions to create commercial lock-ins, centralizing packages like Snap and dumbing down Linux. I already don't touch Chrome, Electron, VSCode and other pseudo opensource and pseudo free software and use some paid, cross-platform closed source software since they solve some real problems of mine, but I wouldn't dream of a Linux like you're creating by reading my simple comment.
Wow.
On iOS the system works because of the type of tasks I do (and do not) perform on a phone. But when I start an automated Applescript and it pauses partway through with a permissions prompt, that’s a problem.
And a good chunk of those people often would be just fine with that "outdated" version.
A more acceptable solution would be to intercept all the filesystem related system calls, look if a path is accessible, and if not ask for the permission and either try again the system call and return the result or return to the application E_AGAIN (but is not ideal since not a lot of applications handle that correctly). But this approach would probably require a kernel module, or you can do that with eBPF but obviously you would need CAP_SYS_ADMIN capability so not really possible.
The approach of flatpack is create a container with all the paths that you know the application can access and then jump into the container. A simple solution that even doesn't require a daemon and doesn't require modifying the applications.
Technically it can be done using LD_PRELOAD on fopen() and such.
If my application invokes syscalls directly, that wouldn't hit anything interposed using LD_PRELOAD.
There are other solutions such as seccomp (as siblings of your post have pointed out) that solve this securely, but LD_PRELOAD won't.
The POSIX APIs do not have such permissions. You can attempt to put something in between and have lots of stuff break, that's what Apple did. On Linux, there is no such authority.
There are alternatives as well, such as sandboxing all the way up to using a hypervisor for every program, which is arguably what you need to run an untrusted program.
> We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use.
Fair enough, but Flatpaks are mostly open-source software and closed-source software can be monitored far better on a Linux system.
(Majority of) People barely understand the (privacy/security) impact of giving access to Location, Contacts, Calendar, Phone, SMS. Now think of the more obscure (?) layers of the following pyramid: Hardware, Middleware/Drivers, OS, Applications. (Majority of) People hardly understand Applications. You want to ask them if they can write on X folder? On the OS? Good luck!
Although both A&G can review your code and flag these upfront with some auto-policy-check, I feel that it would send many app creators reeling & pain. Pain for app creators = smaller revenue to A&G.
I assume it's the typical cat & mouse game. A&G may try to reduce/prevent access here but their SDKs will create a new oppotrunity/workaround to get access there. The new "there" access will be abused and someone will find away to do what they were doing in the previous setup. And thus we restart the chase.
It's in the way that people code. Naughty and/or lazy coders will go for the keys to the kingdom, ignoring the security. To avoid misunderstanding the word 'lazy' doesn't mean 'lazy people', but 'lazy/inapprpriate/corner-cutting practices'.
Well this is how it works in OSX (“Would you like to grant this application permissions to this folder?”), so I guess the answer is “yes - that’s exactly what Apple do”.
Turns out, you have to copy the file to some folder via adb command line, to make it usable by Android. Copying directly to a uSD card would have probably worked too, but how many people just have a uSD card reader lying around.
But I didn't get a confusing security prompt when downloading from a https:// url, that I might not have understood, so I was better off I guess. /s
We shouldn't need to put data in and then trust it doesn't somehow wind up being sent over the internet - we should be able to prove this before we put it in.
The system needed is something like SELinux for programs - data goes in and gets tagged that it's there, and before we do that whatever the trusted OS is prompting us for permissions for, it's actually proving the application will do.
Obviously this might not be a new language: abstracting out how files are used so applications go through trusted interfaces to do things is probably the better solution but the key is starting at user data first and being able to make positive assertions about what can't happen (in the absence of bugs in the enforcement mechanism obviously): i.e. "these personal photos can only be viewed by me, and be sent encrypted over the network to these classes of recipient encryption key" should be a reasonable policy statement we can enforce without needing to explicitly grant permissions to every app which wants to do something with photos.
If we can prove at runtime the app can't or won't be able violate policy, then we don't need to keep throwing "do you want to allow?" dialogs in the user's face and pretend we've done something useful for their security.
To my mind this ultimately requires us to have a runtime framework for tracking data provenance and entropy for what we feed into the system: at any given time we want the OS to have a good idea of where any set of data in an application came from, and how much entropy has been increased by transforms against it (i.e. taking the length of a file doesn't leak much data about it, but letting that be an unmitigated side-channel would be worse).
For example: the operation the user doesn't need to see is "this application is syncing your photos to your Google account". The operation they should be prompted for is "this application dumped a whole lot of data into a function we don't recognize, and the output data which we can see is tagged as possibly containing your photos, it now wants to send to this unknown IP address".
Thinking similar to how systemd works with sockets— specify it in the unit file rather than needing to be launched as root so you can create it yourself and pinky swear you'll downgrade yourself afterward.
Bringing in a new programming language might be valuable for it in the future but at least off the top of my head I can't see why can't this model be adapted relatively easily in most languages today.
The "ask for permission" model is broken.
Everything should be sandboxed without giving the application awareness of being sandboxed. If you want to give additional access to a program, it should be through an external interface only accessible to the user.
Say the process wish to write to a particular file; — how far up the directory tree does the system ask for permission?; only that specific path? the home directory?; how can the system know this?
Of course, the other issue is that, say the system be implemented so that the write call blocks until the permission be given, that they will timeout with an error because they have limits on write calls that take that long, and assume there is something else that is wrong like mechanical storage failure, if a simple write call truly take seconds.
I publish a snap variation and so many edge cases break the security system and make the app unusable.
Home perms? What if the user symlinks something into their home directory? Etc
But, as other people have said, this involves new APIs. In the open/save case, the app has to request that the system display a file chooser instead of drawing its own. GTK & Qt can hide this change so apps built on those toolkits benefit automatically. But beyond really self-contained things (like games) most apps that haven't been developed with a sandbox need some adjustment to play nicely within a sandbox. And making changes depends on building a consensus that it's worth doing.
So, is there a security problem with Linux desktop? Yes, absolutely. And it is serious enough to worry for those who are not paranoid security enthusiasts (I mean, even real vulnerabilities aren't truly a concern to many users, but we have to admit there is a problem, when it becomes quite evident, that Linux starts falling behind both MacOS and Windows in this regard). But is flatpak the culprit? No, not really. Linux on desktop in 2021 is just really flawed (at least security-wise).
And there are the modern applications from the Microsoft Store or self-distributed as msix/appx which are properly sandboxed.
Windows 10X original roadmap was to merge both sandbox models, and it is also part of Project Reunion goals.
I use it for specific purposes like possibly hostile browsing environments but I'd never consider it for a mainstream system to work on.
It's really not easy to get a code signing certificate fraudulently (or to steal someone else's), but of course, there are some issues with code signing: for example, certificates are relatively expensive, so very few OSS/free software projects sign binaries.
I have all my personal data in its own isolated VM (Qube). I do all my browsing in another VM, which has its own home folder and no access to my personal VM. All my sensitive stuff like banking is done in its own VM. Every proprietary application gets its own VM (mainly Teamviewer and VS Code).
So if I do happen to run some program that's malicious, it has effectively zero access to anything sensitive unless it's aware of Qubes and knows how to break out of the hypervisor (non-trivial).
It's just as easy for a Windows .exe to create a service that runs when you log in as it is for a Linux app to write something to .bashrc - so its not a uniquely Linux problem.
macOS has the big Apple hammer to force developers to comply - Apple has the power to say "from this release on, all permissions need to be requested for or they won't work". Comparing the two companies, Apple uses the big hammer they have to force some compliance from app devs, while Microsoft often tries not to break stuff.
Linux doesn't have a big, central hammer like Apple does, so progress like Flatpak's isolation has to happen in steps, or else you end up in this chicken and egg problem:
- App devs won't support Flatpak with stuff like using portals because Flatpak has a small userbase - Users won't use Flatpak because it doesn't have apps that they want, and will instead go about doing things the old way
This "we'll give them $HOME for now and let them fix it eventually" is deliberate - you need to drive adoption for Flatpak before apps consider adding special code paths for it. The goal is to eventually fade out $HOME access or severely restrict it, but unfortunately this is the norm.
I've mentioned this on other posts, but this is deliberately why Flatpak's messaging on their website[0] is focused on ease of distribution instead of security. In addition, if you feel like you can put up with an app having a restricted view of the filesystem (for example, you don't think you'll touch anything outside ~/Documents/Models with Blender), you can adjust the sandbox to fit your needs.
[0]: https://flatpak.org/
This isn't entirely true - you need something like Administrator access (so at least a UAC prompt) to create a Windows Service, whereas all software you run on Linux will normally have access to write to your .bashrc.
Of course, if we're talking about installers and not random .exe's, where users are already conditioned to allow installers to run as Administrator, the problem re-surfaces.
A bit closer to editing .bashrc in Windows is the peculiarity that Windows DLL search order normally starts from the directory where the .exe was loaded from. So, any .exe in a User-writable location that loads a DLL can be tricked into running malware by creating/overwriting a malicious DLL of the same name there (this doesn't work for Windows DLLs, though).
Last I installed something with windows it had full write access to my home directory and pretty much everything the user it was running as had access to. Is this no longer the case?
I think this shows that a standard release cycle is not appropriate for desktop users.
The instant value is providing channels for developers to ship apps to their users without either side having to mandate the OS that the other uses. Right now, even well-funded projects like Visual Studio Code have to pick and choose which Linux distributions and versions that they package for.
They don't provide packages to the main repositories for Linux distributions, partly because the release cycles are so wildly different. I don't want Debian stable to ship a completely new base system every few weeks, but the release cycle of my Web browser is a new version every six weeks.
In the ideal Flatpak world, I can run Solus or whatever distribution I choose, and the app developers that I rely on can not care about distribution market share, and just target Flatpak runtimes.
The challenge is going to be to ensure that Flatpak repositories and the Canonical App Store (the server end of snap) enforce good enough legal and security checks once vendors have started using them.
> It is crucial for an IDE to have access to home or host filesystems, for Git repositories, and for other external uses, otherwise it is not very useful. […] They also need additional permissions to work, since making them use portals for all host system file access is technically complicated. Audacity and VLC face similar barriers, but all these applications should eventually be able to use portals instead of direct home or host filesystem access without losing functionality.
Which means that the author still has a point: there are still lots of use cases where the only practical way to use the file-access sandbox is to disable it.
Btw, the post you shared is a much more balanced view on Flatpack than the OP, but after having read it I would still consider Flatpack not being ready for what it advertises.
My colleagues sometimes complain that it takes somewhat longer to do it this way than the old-fashioned “writing the code yourself” way, but on the plus side I don’t have to actually be present at all while it’s doing it. Just have it send you an email once the unit tests all pass and you’re good! This development approach has given me a bunch more time to train my monkeys to type Shakespeare. They’re getting pretty good at MacBeth, and I’m hoping to move on to Othello next week.
A friend of mine questioned why I involve ‘clang’ in the process at all; why not just echo /dev/urandom into a file, set it as executable, and then run it, instead of mucking around with the whole “compiling it with clang” step, but I pointed out, you know, at that point is it even really programming any more?
There's obviously much more to do, but it already prevents many things like a pdf.js exploit being able to copy my ~/.ssh, without having to resort to some really clunky solution like a VM.
I want to be able to give programs exactly access to I want it to access, and just when I want to give it that access. This way I'm sure my SSH keys (or private emails,or bitcoin wallet, etc) will never be leaked by a malicious VSCode extension.
But if that's what you're asking for it isn't a major change. It could even be done by using a simple shell script for installation.
"Oh, opened our website did you? Don't mind us - we'll just go ahead and install our own 'value add' daemons on your computer that show ads, and exfiltrate your data to improve ad targetting. You can trust us!"
The overwhelmingly vast majority of them would do just fine without having access to my entire home directory.
>If you don’t like Flatpak for personal reasons, I respect your opinion, but basing your arguments on an anonymous post that claims to have “criticized” Flatpak, but provided no statistics or evidence that vulnerabilities have been exploited inside a Flatpak package is not a reliable source of information.
Really?
You can't categorize people into "people who use flatpak" and "people who have personal reasons", it's not a very healthy way to look at software development. These concerns are entirely legitimate, and it's not like you're coming from the majority here. Flatpaks are still wildly unproven, and most of their responses were concessions surrounding the issues Flatpak has.
As a Linux user, most of my software will be installed with my native package manger and receive the appropriate security updates.
Flatpak/Snap/Appimage are just for when the former option is not possible because the software is not available or not in the right version I need.
I am making a conscious decision here to seek out that software and can be expected to check for trustworthiness.
The Windows world survived decades with running random .exe files from the internet. Some people got hurt but that is fine. Sometimes convenience and productivity can be more important than security.
I already have a good sandboxed environment, it is called a web browser.
So really for me the only thing I need is some easy way to run an application with just a single click on any Linux system. Appimage works fine for me. All the other features, I don't need them.
Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?
Ignores half the point of having a distribution that has a package manager, curated software.
Say you distribute a video app. It is completely counterproductive to have every user click on a permission dialog "I allow this video app to open videos". This only trains users to blindly allow everything to make software, you know, work at all.
A much more sane approach would be to enable access to ~/videos and other reasonable places at install time and only ask for additional permission when needed.
The article does highlight some actual issues, but the author implies that the solution is to simply not use it at all and go back to the free for all smörgåsbord of access rights that an application installed from the regular repositories have.
Personally, I consider Flatpak the best solution available right now time minimise the attack surface for anyone not willing yo go all the way and run Qubes OS. If there is a better alternative I'd be happy to hear it, since I cannot run Qubes one of my machines.
> Passing responsibility of not distributing evil software from the gatekeepers to the user.
As in, we can have gatekeepers but also force software to define explicit access policies. Like, maybe a program that needs regularly files will create a folder where they have access to files and any files placed there afterwards can be used by the program without asking for access. For all other files/folders it would ask for specific access, and the access could be given as session based or normal and apply to the selected files only?
Having a default folder (per application) could then be used by programs like word processors or wtv to have a place to save automatically so the ux doesn't suffer in the basic case. Saving files outside authorised folders would not need permission unless they were overwriting a file that wasn't permitted previously, but access to other things in a non permitted folder would require permission still?
This could live with existing package managers curation and sandboxing, but even if the programs somehow got into a compromised state they would be limited?
Making each app have its own filesystem just forces a weird file structure where you don't have a folder for a project, but for an app. Whose projects only consist of one type of files?
If the app is a web browser then fair enough, but what other apps would that be useful for?
> What's the point though? Either the software is evil/has a bug that lets it steal all your data, or it doesn't.
The program itself might be updated to a compromised version, where the gatekeepers are compliant or by a change that passes review, or you might want to test a program and not have to worry about running a vm or a docker container. For package managed programs this is not so much an issue with linux where you usually will update it yourself, but anything using auto-updates can fall prey to it. The same with npm et al.
> Making each app have its own filesystem just forces a weird file structure where you don't have a folder for a project, but for an app. Whose projects only consist of one type of files?
The app wouldn't have any specific filesystem, it would be given a role/group/wtv that could be used to assert permission when accessing files or system apis. Say I download chrome, chrome creates a folder named "chrome", it can only, by default, write to that folder and read from that folder.
For anything else it needs to ask the OS for permission and I can grant it, for a single usage (the file as is in that point in time is read and passed to the app), for a single session (until the app is exited it can re-access that specific file without prompting) or until I revoke it (it can access that file without prompting until I revoke the access). When it needs to access a file or api, outside of those currently allowed it needs to ask again.
The folder was in terms of one of the complains of permissions making the UX worse when you need to give permissions to the app. So in this case, chrome could store its downloads inside that folder, the save Page as, download image as, etc.
Ideally it would have enough granularity to distinguish between modes of access, so I could give it permission to save on my "docs", but it wouldn't have permission to read other files in the folder that weren't granted permission - it would be able to read though the files it saved by default, because those would default to be readable as well (since the program was the one writing them there's no point in changing that).
The permission could be changed as well and changing the file from one "folder" to another could/would automatically reset the permissions (perhaps the permission would be an hash of the current directory + an app key). When upgrading versions the OS would have an easy way to migrate current permissions, generating a new copy of the current permissions from app key to a new set assigned to the new app key (the app key could be an hash of the current program folder as when installed). This would be something like a panel where you could see all app icons/or in text mode their names, and click one, and say, import to X, or do copy-permissions chromev12-xssdcfdsf to chromev13-shfghhjh. Or right-click the icon for the app and have one of the options be "import permissions from", etc.
If a program doesn't need to do any of these then it wouldn't need to have a folder but most programs will have some sort of necessary file storage, be it config, etc.
This same permission model would then work for OS api/hardware/wtv access. Open zoom and it needs mic and cam, you can give it permission just until you quit it.
This is also true when it comes to programs that have sudo requirements to be run. I'm not saying that you can't take precautions to mitigate any of this if you're paranoid, I just think it should be the baseline. There shouldn't (ideally) be any need for me to run jails, VMs or anything to try a program or installed libraries to be used.
If I on a phone use an app that can send, for instance images or any other files, but also store them, I should only need to give it write access to a folder but not read. Because unless it's going to do reading by itself without me instantiating the action, whenever I want to send a file, the OS can prompt me and I will pick the file, and this wouldn't even need to change the access level to that file, the os could just provide the file for that single interaction.
Very few desktop apps need permission to read/write files you didn't select manually anyway.
So do users, still can't overwrite system wide settings without first getting root. Decent sand boxing has to be granular enough to cover partial access. Of course the hard part on Linux would be locking access to files like ~/.bashrc without completely blocking access to the home directory, that probably would require an exhaustive list of all config files that are directly stored in home instead of a specialized sub folder.
I think I didn't make my point clear. I used that as an example of "needs to access files" not meaning "needs to access all files, including but not limited to configuration files".
> Flatpak only offers the ability for extra security.
With a permission model that apparently can't keep an image editing application from silently editing .bashrc .
It can, you can cut off all filesystem access or select certain areas. The problem is that programs often need special attention to make sure they work properly using flatpak portals. Currently not many devs are interested in doing this work since flatpak is pretty small right now.
So for now we must assume that Gimp built from the official source, is not a malicious program. Like we have for the last 25 years.
This does mean that some apps potentially do have worse UX; any app that implements a custom file picker will just stop working properly. Arguably in that case you just simply cannot sandbox that kind of app, and you shouldn't try, because it gives people a false sense of security in using it.
For apps that want to do custom things you essentially have to make them not need to do custom things by building their custom behavior into the sandbox-owned file picker (or whatever), and allow them to make use of it in a safe way. But that's a lot of work, and it doesn't seem like the Flatpak folks really work with the toolkit authors.
Flatpak has this already. They call it portals and it covers more than just file pickers. The problem I have seen is that shoving existing software in to flatpaks and making them use portals ends up buggy for unknown reasons. I think the app devs themselves need to make at least some conscious effort to make sure it works and not directly access files.
I think the reasons are quite clear: introducing asynchronicity (one requiring further user interaction at that) into what used to be synchronous code is one of the most common ways to introduce bugs.
App devs would be right to sit tight and see who gets a higher market share (snaps/flatpak) before implementing any of the proprietary approaches they might employ.
Apps which do implement them probably have an investment in the ecosystem already (eg. Canonical-developed apps will make use of Snap APIs, whereas Red Hat-developed apps will make use of Flatpak APIs).
This will however suck for end users because now software starts depending on packaging :/
I don't think it is that clear. If your app uses GTK or QT, you should in theory get transparent and automatic support for portals. I suspect the problem is the app then tries to directly access the FS outside of the filepicker and gets blocked.
Both Flatpak[0] and Snap[1] use the same xdg-desktop-portal spec[2], which covers stuff like opening files, taking screenshots, sharing screen, and sending e-mails, among other things.
The only major difference in the two sandboxing approaches (noted in [1]) is the ability to execute arbitrary code outside the sandbox - Snap requires you to disable the ("modern"?) sandbox and use "classic" confinement, whereas Flatpak has you send a command over D-Bus to `org.freedesktop.portal.Flatpak.Spawn` while still running the primary application in a sandbox.
This would only be relevant for a small number of programs like IDEs, which are, at the moment, a relatively poor fit for "application"-style sandboxes like Flatpak, or confined Snaps, IMO.
[0]: https://docs.flatpak.org/en/latest/basic-concepts.html#porta... [1]: https://snapcraft.io/docs/xdg-desktop-portals [2]: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...
Even if I want to ignore the "exec()" differences, you are still limited to standard OS file selector (for instance no custom previews which is probably the most common thing apps customize): basically many apps will need to break backwards compatibility and move to a suboptimal solution (meaning expend effort for a worse UX) just to provide users with sandboxing.
Don't get me wrong, it would be great to get the best of both worlds, but since it means I have to trust individual app packagers to also provide security updates for each app, we are still a long way off from that best-of-both worlds.
(This explanation also adds some context to the recent Audacity release which mostly just moves all project files into a single file)
Even if you do build support for previews in the file chooser, you lose the sandboxing since that preview-generating app now has access to any file a user simply previews. Unless you start introducing a separate, orthogonal previewing system, you also lose caching of generated thumbnails and such.
But it's not only previews: there's also the File-Roller (archive manager for GNOME) "Add File" file picker.
So, while it would be great to have consistent file choosers UX- and UI-wise, you'd be forcing some apps to do away with useful features. And suddenly, you are now into how much consistency matters in this particular case?
FWIW, some issues will remain forever (or well, a long time): in the days of gnome-vfs vs pure Gtk+ file choosers, one could give you non-local files [nfs, smb, sftp...], and the other couldn't, yet they looked exactly the same.
The same is true for Gtk file chooser today (local vs networked files), simply because some apps can handle them, and some can't. These UX issues always annoyed me more than the look of file choosers between apps.
In a sense, I am actually arguing for orthogonal, system-wide file chooser infrastructure with support for everything and your kitchen sink. These would now not be sand-boxed (I don't want to wait an hour for my gallery image previews to load, so caching FTW), so it's a big attack surface (all the previewers, with some like ghostview executing turing-complete PS programs), and it makes you question why would you need sandboxing for the rest of the stuff :)
I don't think it's possible yet to ship thumbnailers in Flatpak - I'll try poking someone to see if there are plans for that.
[0]: https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/master/R... [1]: https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/master/l...
You could also argue the reverse: if synchronous file access was good enough before, there should be no real reason not to use Flatpak portals synchronously as well.
That's okay for mega-corps who re-build the entire software universe every time they want to make a change. Or for those who ignore desktop entirely and just "deploy" containers.
And that's lead us to today. Linux desktop can't live for more than a few years on it's own. In order to deal with the backwards incompatible features some desktop distros have shifted to using containers. But this doesn't fix the futureshock. It only makes things for desktop users worse.
Discord & Slack, I'm looking at you.
I also run a rolling-release distribution...
Agreed, although we may be in disagreement regarding what the disease is.
> Modern Linux development is extremely rapid pace
I believe you are over-generalizing, both over different distributions and over different packages within a distribution.
> and is 100% targeted at the needs of the corporate entities paying for the development.
... specifically, many distributions are not funded by one, or a few, specific entities, corporate or otherwise. Debian comes to mind. I've never felt its is developed rapidly, or that languages change that quickly.
> . Linux desktop can't live for more than a few years on it's own
I'm not sure what you mean.
> In order to deal with the backwards incompatible features some desktop distros have shifted to using containers.
but the rest haven't.
Perhaps OP would be happier with a capabilities-based operating system (like Google's new Fuschia system).
It just seems like these complaints leveled against Flatpak are asking the authors to achieve nearly impossible goals given the complexity of doing sandboxing at the app level in Linux.
Are you talking about the Official Images program? Because if so, this is not true.
What we need are tools for per-workflow sandboxing. Assign each data to worflow/project (with separate uid), and then execute applications as a part of the project. So applications would have access to data of the project in which they are executed.
1) application sandboxing isolates different vendor's code, some of which may be security / privacy infringing.
2) There wouldn't be a problem with data sharing in a properly designed sandboxing system. There will be shared filesystem, file chooser / save dialogues so that's not really a problem.
> The flatpak runtimes and apps do not get security updates
This is exactly what I worry about with things like Flatpak and Snaps (Ubuntu).
Instead of having the distro maintainer provide timely security updates, all they have to do now is shrug and point at the external package maintainer. So now instead of simply backporting a patch to the distibution's openssl library, every single app maintainer of each app that uses it has to do this and provide an update. This is clearly not going to work as well.
And while sandboxing is a great idea, it can be done using other methods too, like SELinux or AppArmor.
Not to mention the wasting of resources by running all those separate versions of each library.. But that's not security-related discussion.
That’s false. OpenSSL is part of the runtime[1] and only needs to be updated there.
[1]: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/ma...
All of these require access to the users data to actually function.
GIMP, Inkscape: edit/view photos and save creations VSCodium, PyCharm: edit/create project files Audacity, VLC: play user media
these apps have the same "problem" in snap requiring --classic to allow access to the users files.
The future of software cannot be containerizing anything dangerous or complicated. All it does is add an extra layer of abstraction that makes it harder for the end-user to use your software. All of this seems especially redundant on Linux, where we could take any number of extreme measures to sandbox software. Why did we choose the path of most resistance for the user?
That’s not true. Even the smallest consumer hard drives are big enough to store as many apps as you will want to install.
> Slow internet connection? Good luck, you'll be here a while.
Flatpak uses OSTree to install and update apps. It is very efficient and generally faster than traditional package managers.
Flatpak for me is incredibly useful in a narrow use case; other people put in the work to make stuff work without cluttering my damn home directory! Specifically it's helpful for Steam. Why every game on the planet feels the need to fill my home directory with UNHIDDEN directories with spaces in the name (!!!) is absolutely beyond me.
Just abandon the epicycles already!
I suppose the real answer may always have been backports on debian distros - which is to say, trusted sources over technical solutions.
This does not solve the problem where your a PDF reader from a trusted repository happens to have a zero day exploit. When it is exploited, the attacker could have access to all your files, since there are no further limitations unless you bubblewrap or firejail the application yourself.
Since sandboxing is one of the goals of Flatpak, the exploit would be limited to the sandbox (if sandboxing was enabled for the PDF reader).
You can use Firejail or bubblewrap, but they are not exactly user-friendly solutions.
Ideally a user installs the app and they would know, without reading anything else about the app, that the app is separate from their system. If any app you install is NOT separate from the system, then... the sandbox is like making a giant wall but having a door right in the middle of it.
E.g. if I make a chat app, and it has a bug that lets someone send you a malicious message and execute code in the app, then a sandbox is a really good thing.
The developer also sets the default permissions - in principle, the user can change these before running the app. Of course, not many users will do that, but there are still cases where it can make a difference.
As such, rebuilding Flatpak and its various layers should be easily rebuilt from source or equivalent as available as an option (but not the default). That would prevent some of the issues.
It would also introduce bugs, but at least you would have the option.
Anyway, I spent about an hour attempting to get get it to run on my up-to-date Mint laptop. Now, Amarok 1.4 is 12 years old, so if you want to get it to run, you'll either have to compile it (which means getting your hands on the 12 year old KDE libs), run a 12 year old Linux distribution in a VM, or... Dockerize it. Now you see where the flatpak connection comes in.
Step 1: Find an Ubuntu 8.10 ISO and mounted it:
sudo mount -o loop ubuntu-8.10-desktop-amd64.iso /mnt/intrepid
Step 2: Unqsquash the filesystem:
sudo apt-get install -y squashfs-tools sudo unsquashfs -f -d /tmp/unsquashfs /mnt/intrepid/casper/filesystem.squashfs
Step 3: Import the tarball into a Docker image:
sudo tar -C /tmp/unsquashfs -c . | docker import - ubuntu/intrepid
Step 4: Run interactively and install Amarok:
docker run -it --entrypoint=/bin/bash ubuntu/intrepid
(NOTE: At this point, it was pretty hard to find an apt repo for Ubuntu 8.10 but, amazingly, one or two still exist online. So I edited the apt sources, ran apt-get update && apt-get install -y amarok. I also created a user to run Amarok - one whose uid/gid matched my own user. These commands are left as an exercise for the reader)
So I dockerized Amazok 1.4.10 / Ubuntu 8.10. What next? Well, I could have created a Dockerfile that started "FROM ubuntu/intrepid" and repeated all of my manual work I did in the interactive container, but I'm not keeping this thing, so I just did this the hacky way:
docker export quirky_mendel -o ubuntu_intrepid_amarok.tar
docker import intrepid_amarok.tar amarok:1.4.10
Now I have a docker image called "amarok:1.4.10" which I can share on Docker Hub! Does it work?
docker run -it --entrypoint=/usr/bin/amarok --rm --name amarok --net=host --user amarok --privileged -e DISPLAY=:0 -v ${HOME}/.Xauthority:/home/amarok/.Xauthority amarok:1.4.10
IT WORKS! A 12 year old music player running in a docker container on the latest Linux Mint. My alternative to Flatpak / Snap etc. Is it safe? Nope! It's running in an Ubuntu image that wasn't updated since 2008.
What a contribution. Typical flame bait website.
A large difference it that Flatpak also attempts to sandbox applications, which Nix doesn't (it only sandboxes builds). Though it might be easier to sandbox applications using Nix than traditional package managers, since all dependencies are made explicit.
It makes builds reproducible, and basically a package will depend on it’s inputs’ hashes. So you can not only install multiple versions of the same package that is solved by some package managers although in hacky ways, you can install multiple ones that only differ in eg which libc version they link to.
In this way, I do think that it is truly revolutionary - but it is a package manager (and NixOS makes basically the OS a big package). Flatpak and snap try to do this as well, in an objectively worse way, but they also provide different features, so they are not in competition. I would rather like to see flatpak and snap employ nix for solving the package management problem and build on top of it. That would actually make the linux solution better than what we have on other OSs.
The Freedesktop SDK has a CI pipeline (run on schedule, not on every change, because it is expensive) that tests reproducibility, similar to r13y.com. Currently everything is reproducible except a few components.
There are also many respects in which Flatpak is objectively better than Nix (other than sandboxing, which is an important one). For example, Flatpak guarantees atomic updates with restarting merely the updated application. NixOS only guarantees atomic updates with a reboot (`nixos-rebuild boot`); `nixos-rebuild switch` can still break your running system, though the Nix store is safe and problems will not persist after a reboot, which is still a huge improvement over traditional package management. Still, using containers allows giving stronger guarantees.
Another example is that flatpak-builder and BuildStream are substantially faster than Nix. Evaluating Nix expressions is quite inefficient, even if they are convenient to write. Worse is the cascading rebuilds that come with the Nix approach when dependencies like compilers and glibc are patched or updated. Rebuilding after significant updates to gcc and glibc has advantages, such as benefitting from newer compiler features, but it is very desirable to have the option not to do that.
Also, Nix’s languages lacks domain abstractions for building packages, which makes tools to generate and update derivations have to rely on assumptions about their format or be unnecessarily complex. In comparison, flatpak-builder and BuildStream use JSON and YAML. The result is less expressive but more convenient, consistent, efficient, and simple to manipulate.
Similar to nixpkgs-update, Freedesktop SDK uses a simple auto-updater[1] for BuildStream and Flathub apps can use the Flatpak External Data Checker[2] for a bot to open merge requests or pull requests to update dependencies in the runtime and in application manifests.
OSTree uses a content-addressable store for all files, giving Flatpak deduplication for free. Nix gets deduplication only with an expensive process (`nix store optimise`) that involves scanning the Nix store and replacing duplicated files by hard links.
Yet another advantage of Flatpak is that due to dependencies being “flat”—that is, apps can depend on runtimes and have extensions, but there are no complex dependency trees—there is no need for dependency resolution. This also reduces the amount of metadata that needs to be downloaded. This makes installing and updating software with Flatpak very fast, which is unfortunately not at all true with Nix.
So, there are tradeoffs, and overall Flatpak has the better of them. Employing Nix to manage dependencies or to build apps would cause Flatpak to lose many of its advantages.
[1]: https://gitlab.com/BuildStream/infrastructure/gitlab-merge-r...
[2]: https://github.com/flathub/flatpak-external-data-checker
Nonetheless, I have some questions, comments:
> Nix doesn’t guarantee binary reproducibility
Yeah, it’s true, but no general build tool can, since language build tools themselves are usually non-deterministic.
> For example, Flatpak guarantees atomic updates with restarting merely the updated application. NixOS only guarantees atomic updates with a reboot
That latter is only true of NixOS; for an ordinary package you can just start up actually both the old and updated version at the same time without any trouble. And in the OS config case, it is more of a linux deficiency - it does restart services when possible, but that is orthogonal to this discussion as I believe flatpak doesn’t do anything similar.
> Evaluating Nix expressions is quite inefficient
You are right, but the results can be cached. With the experimental flakes it is quite fast.
> Worse is the cascading rebuilds that come with the Nix approach
Well, it is sort of a tradeoff of reproducibility. Also, there is work in progress to minimize rebuilds to only truly necessary changes.
> Also, Nix’s languages lacks domain abstractions for building packages
The language lacks them. The repo has a great deal of abstractions for many use cases, and so a trivial to build package will look almost the same as a JSON. And as you note, it is a tradeoff, but there are plenty of hard to package apps that benefit greatly from the more expressive language. Also, there is plenty of auto-updaters that can automatically create PRs for eg new python packages, since it is more often then not just a version and hash change away, so package description manipulation is possible this way as well.
> OSTree uses a content-addressable store for all files, giving Flatpak deduplication for free
Correct me if I’m wrong, but it is necessary because flatpak uses the docker-like model, in that the same shared dependency is “theoretically” copied in each package, even if it is the same version. So in a way they solve a self-created problem. nix on the other hand simply links the same shared library, no duplicated data. You can optionally deduplicate when you install multiple versions of eg. libc. Nix can’t really prove whether the two “versions” are the same, and sometimes they may be identical, or identical in part (eg the man pages are the same, but the exe is not), in which case imo really elegantly, it can hard-link one to the other. But the base state with only one version of a nix channel installed, you simply have no need for deduplication as opposed to the flatpak model, because you only get every package once.
One last point, a nix package may have less overhead, although it is I believe negligible in most cases since vms are quite light nowadays.
So I agree with you on the tradeoffs part, and I again apologize for dismissing the project - I really dislike the same uninformed attitude towards for example systemd or wayland. But I still believe that nix is the one doing something revolutionary.
(Also, maybe not-possible but nix could perhaps be used as a tool to create flatpak images similarly to how it can create smaller docker images: https://yann.hodique.info/blog/using-nix-to-build-docker-ima... )
https://firejail.wordpress.com/documentation-2/appimage-supp...
both snap/flap user experience is trash
linux desktop is doomed to fail people the people who make decisions are clueless and tasteless
Who cares? Why is popularity so important to you?
Even ChromeOS and Android only package the Linux kernel, while building their own userspace on top.
With the Web turning into ChromeOS, and the return of timesharing via the cloud, there is even less reasons to care about the GNU/Linux desktop.
What does this even mean? I’ve been using Arch Linux with KDE as my only desktop OS for years and it’s a wonderful time. If you think Windows is better and prefer to use that, great. I personally prefer Linux and a lot of other people do as well.
No it is not. If sandboxed means no access to filesystem, sure it would be, but that is not the only definition of sandboxed, that is not the definition of that under which flatpak said they would operate, that is not the definition of sandboxed under which other things operate.
If you want them to use a different definition of sandboxed, by all means submit an issue making the case, but you don't even make it here. You just ignore that and then proceed to act as if your definition is the only reasonable one. And if that was the case the very least you can do is find a reference for your definition.
Try harder with the FUD.
How is that what is happening here?
The freedom in open source could be the freedom to structure your system in the most secure way possible for running untrusted applications. It’s just that no one managed to achieve this yet in a satisfying way.
Don't you think tools like Bochs, QEMU, gVisor, etc. are reasonably satisfying? Security is a hard problem since there's an endless push and shove around its tradeoffs hence why sometimes the best one can afford is monitoring.
Right now I'm most happy with Firejail for sandboxing proprietary applications. It doesn't solve the packing problem but seems to do the best job at actually limiting what applications can do.