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.
I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues.
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.
It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure.
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.
Sandboxing is fine, but it sounds like Snaps/Flatpaks don't actually do it because that would be too hard - so what's the point?
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.
Snap/Flatpak are not doing it because that's not the layer which "does it". They provide the framework which allows since sandboxing today and will provide better sandboxing tomorrow. It's up to the app distributors to support it or not. We won't get full support immediately either.
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.
On average, I've found Snaps to be better sandboxed. But there are plenty of things to dislike about Snap e.g. not respecting XDG base directory spec, persistent daemon running as root, requiring sudo, unable to control when it decides to autoupdate, coarse grain "connection" system ...and more. A lot of obvious design mistakes that don't get fixed for one reason or another.
Well, they are also marketed as a way of isolating dependencies, which they do actually manage to some degree. So they could be weak security-wise without being completely pointless?
- 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
I think this is a valid criticism from flatpak / snap. But they are step in right direction about sandboxing (on the other hand bloat and developer trust are main problems abou these platforms for me).
> 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.
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.
I think that GP's point still stands. Application security on most native platforms right now is a disaster. But application security on Linux is a dumpster fire. Yes, there are ways to do it better with SELinux, yes there are ways to isolate apps, but they're overcomplicated, inaccessible, and the end result is that most consumers don't use them.
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.
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.
So you think that disallowing access to word processor files to zip and unzip, or backup utilities, or ... is a perfectly reasonable way of doing things?
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).
Having a portal that dictates file access would be a perfectly reasonable way of doing things, and that's the direction that Flatpak security is at least starting to move in.
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.
This. I would expect a modern permissions model to be:
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.
> 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.
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.)
Definitely not perfect, but I wish people would lean on good old fashion unix more for these things instead of implementing it worse on top of it.
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.
That is because it turns out that everyday software often needs such permissions to operate gracefully.
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.
No, I think what got us into this mess is Ubuntu being a server distro with a standard release cycle (as opposed to rolling release) getting incredibly popular on desktops.
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.
That would be quite surprising since Ubuntu Server appeared only after Ubuntu Desktop was already the #1 desktop Linux distribution (free CDs shipped worldwide, etc).
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,...).
> Desktop users want the newest version of their UI apps and don't care so much about stability.
[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?
If you define "care" as in, "random updates cause enough instability that they make alternate OS's favorable for accomplishing the same tasks," I'd cite Windows autoupdate as fairly hard evidence that people don't care.
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.
Competitor? Windows is still >85% of desktop use or thereabouts - you can buy an expensive mac or you can go to hell and try out linux; neither is really an alternative for many so they just accept what happens.
So why do they bother adding new features to Windows?
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.
Sandboxing does not mean no interaction. It means supervised interaction between apps where the user is in control of what to allow and what not. I'm not sure how well Flatpack does it (never used it) or Snap does it (used quite a bit but never tested how well it sandboxes) but there are other platforms that handle sandboxing pretty well and then provide APIs on top to allow interaction with the system and other apps (iOS, Android, Meego for example).
Snap and flatpak: they suffer from identical problems (in the snap world, these are "classic" snaps which get almost no restrictions).
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 :)
A capability model fixes this: the application launches a file chooser which it does not control, which can then return it an fd or other token giving the application the capability to read from or write to a specific file.
Of course, this would be a considerable effort. But it's probably where we're going.
I've long argued for applications to use file choosers they do not control, but not for security reasons. I've wanted it for UI reasons.
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.
Major GUI frameworks agree with you and have already adopted this approach and it is already used by many applications, and this has already been the case for years.
As mentioned above, Flatpak is already doing the two most popular toolkits. Programs just don't use toolkits to open files. So there is not a lot of "buck" here, and the tail is rather long.
Can't the sandbox override the corresponding syscalls? E.g. open() and readdir() which then block until the user has selected the file? This means you'll have to click the file twice (once for the sandbox and once for the application) but at least it is more secure.
Of course, in "classic" apps, there is explicitly no protection. They don't promise it, and you don't get those by default when trying to install a snap.
From my perspective as a Flatpak user I can say I hate how the current file access restrictions are implemented, it's confusing and annoying.
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.
You can use flatseal[0] to allow apps access to extra folders in the filesystem. It's a GUI app that makes it much easier than learning how to do the same thing from the command line.
Took me a while to figure out that Signal can't save outside of Downloads as well, especially since its not the default dir it opens when trying to save an file. There's no feedback of any kind.
I see flatpak more as a distro independent package format than a way to secure my system.
Exactly, the lack of feedback is the worst part of this. The way it's done right now it looks like the file picker is completely broken and riddled with bugs; the user goes in expecting it to behave normally(given that it looks exactly the same) but it won't show files in the home dir, refuses to even show user-created directories etc.
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.
More confusing one is that flatpaks can't access mount points inside your home directory even with the correct flatpak permissions set.
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.
If that can make you feel better, it is exactly as annoying for mac os apps on the mac app store. I don't know anyone using Mac professionally (for e.g. design, etc...) who uses AppStore apps because of that
This way of dealing with file-access is also not secure: if all your files eventually end up in a Downloads folder which is readable by all Flatpak apps, then what advantage does this have over sharing your entire home folder?
>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.
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.
Couldn't it be possible to ask the user to allow certain directories or files? It might be kind of annoying but it would be safer.
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.
> 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.
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).
I use flatpaks all the time and I almost always have to adjust these permissions to be more restrictive.
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!
The criticism and response typically boils down to "Yes, but its actually not any worse than what we have now"
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.
The thing is that messaging is the important bit here.
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]").
I decided to look at the messaging - the websites of both Flatpak[0] and Snap[1] make no claims about security, or about being "designed to be built by less-trusted parties".
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’:
"Convenience of distribution" is, by nature, targeted at application distributors which are not the end-users I (or the OP) claimed to be affected by the messaging.
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).
The sandboxing is not always weak. On most apps its almost fully locked down and has access to only your downloads folder. Its only things like vscode which need everything.
You can also manually set permissions using flatseal to lock it down as much as you want.
Putting a blue shield on "sandboxed" when allowing (write!) access to my home directory falls on the extreme side of "weak" to me.
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.
Access to a shared downloads folder doesn't sound “fully locked down” to me. I can imagine situation where I wouldn’t want one app to see what is downloaded by other apps.
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.
Flathub actually does review submissions reasonably well. You have to give a justification for each permission you request and why it couldn't be done in any other way.
It is hard to guess at motives when author is unknown.
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.
You've misunderstood "how Flatpaks work": they are using the same system calls that containers use for containerization but in a different way, look at https://en.wikipedia.org/wiki/Linux_namespaces (Snaps use AppArmor too if that's a more familiar technology).
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).
Which is good as one should discuss the merits of the arguments brought forth when discussing the pros and cons of a technology rather than who who said it or what motives they might have.
Edit: when I wrote this comment only the first sentence of the parent existed.
I find your takeway that it is f.u.d. from this response quaint.
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.
One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used? Similar to iOS and Android, ping the user and confirm whether or not they want to give the application this permission. Perhaps even allow for customising the permissions (e.g. when it asks for permission to the homedir, you can override what the homedir would be when prompted).
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.
I think its more of a one step at a time thing. There is nothing about the design of flatpak which prevents permission popups. The problem is that every desktop program must be rewritten to support this idea and most linux desktop app devs are only vaguely aware of flatpak, let alone ready to start designing specifically for it.
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.
If the package has host fs access, the sandbox is essentially turned off. A few packages have this because they just don't work without it. The thing is, clickbait bloggers go nuts over this but the state is not any worse than if you had used a .deb
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.
When I install something using dnf for example it installs near-instantaneously! Makes me wonder wtf Gnome Software does in the background to make installs so slow :P
It also just seems sooooo slow. I also drop to the terminal for these tasks 100% of the time - including search. I’ll Google for software, and then dnf search to find the specific package if it’s offered.
> 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.
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.
Why not just fake stuff? If you give software no file permissions, show it an empty dir. Tell the software you saved it's file but don't, just keep it in an memory overlay just for that program's run. If it wanted the network, give it a dummy net.
Easy, show a pop-up informing the user that the application tried to access so and so file, and if this was intentional, please click allow and try again.
When the sandbox works as it should, the application has no idea that so and so file even exists.
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...
As an counterargument, see all the comments to this article.
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).
Very similar. Either complaining about non problems, or complaining about some default they can change, or suggesting solutions that are over-complicated and simultaneously inadequate anyway.
Same underlying reason, except it is worse, because it is in the quadrant "they think they know, and they really don't".
Agreed, the current state is such that many developers either rely on package managers for auto-updates (thus lacks sandboxing anyway) or use Snap (which is usually similarly not sandboxed and you have to put your trust in some proprietary cloud platform to push code to your computer). Just getting devs to support Flatpak is an effort, but once that's done sandboxing can be worked on later.
> The problem is that every desktop program must be rewritten to support this idea
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.
Is not that simple. First you would need a flatpack daemon that manages that permission, that the application could ask for a path (e.g. by writing in a control socket) and the daemon asks the user and mounts that paths inside the container, and then inform the application that the operation is successful. But that would require modifying the application, and not in a trivial way, and it's unacceptable (you need to fork basically every application that you package for flatpack, and the filesystem access could be in various places).
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.
It will certainly work for the vast majority that are using #include <stdio.h> and more importantly for the various GUI apps that are using GTK/Qt dialogs.
This is for security, though - you can't just assume it's good enough because it will work for most benign applications - you need to be sure it will work for all applications - benign or malicious!
There are other solutions such as seccomp (as siblings of your post have pointed out) that solve this securely, but LD_PRELOAD won't.
Confirming these settings at first launch is something that mostly annoys users. Remember: Most users just install software via Flatpak because this way they don't have to compile it themselves, deal with a tarball or use an outdated release their distribution ships.
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.
As it happens, macOS didn’t get away with it for me. It’s the single largest reason I’m moving away from the platform.
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.
Escaping from annoying micromanagement pop-ups is a big part of why I use Linux. If this changes and it becomes as naggy as Windows I might have to move to Openbsd :)
From that perspective, moving to OpenBSD seems mostly pointless as currently the best practice there if file permissions are too strict seems to be "comment out some unveil lines and recompile the program." Not really an improvement IMO.
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.
I personally think being able to know what my applications are doing and being able to micromanage software permissions if I need to is beneficial.
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.
You apparently didn’t read the parent: “ I'm sure the same model can be applied to Linux.” I was replying to that, so perhaps your reply belongs one level up. I read the parent as “all next-gen packaging formats should adopt this pattern” and envisioned a hell where said packages are the only way to get new software, if any of them gains enough traction. I already know of a few packages I depend on which are only officially packaged as snaps - I’ve had to find alternatives or look into compiling from source (not always feasible - I don’t have a ton of time to tinker anymore).
> I read the parent as “all next-gen packaging formats should adopt this pattern” and envisioned a hell where said packages are the only way to get new software, if any of them gains enough traction.
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.
There is a mechanism for this called portals (1) available in flatpak. It gets integrated into the GUI toolkit, and certain applications are not supported. It is useful for things like accessing files from outside the default sandbox.
In my view these queries about permissions are a bit meaningless. If an app asks me if I want to give it access to my Photos I feel uneasy about that. Which photos? For what? What is it going to do with it?
I think the filesystem should be sandboxed and if an app wants to read something I should be able to e.g. give it a directory where it can do anything or I should be able to select a file and the app will have a permission only for that file for a limited time e.g. only to read it once.
Also there is no easy way to know what these apps send over network. How do I know they are not downloading all my documents to China?
If it's anything like on Android, where you just give it blank permission to access your entire storage, it would be useless. There are plenty of programs you might want to use that have no business having access to everything, that you can't or don't want to trust 100%, but it's easier for the developers just to ask for everything (or it's the only option).
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.
This is where we need to require better programming languages. What we need to be able to prove from code is that when an application is asking for a particular permission, the code paths the data will be used for can be shown not to result in network transmission without going through a trusted transform (if we want to allow it) - i.e. that only SHA512 transforms of that data can end up on the network without gating or something.
Is this really a programming languages thing? Feels like more of a framework issue to me, that the OS should be set up to pass apps already opened file handles for a lot of use cases where apps currently browse the filesystem and just do whatever.
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.
IMO we need a new runtime OS/system library for it. People have commented here that LD_PRELOAD wouldn't work so I suppose we need a software with which you can force a program to only see the libc.so you want it to see -- as a start.
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.
Because what we need to be expressing - and it would be better at a language level however that's done: is something that can be introspected reliably by the OS at runtime to create assurances about how data is used in the system.
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".
This is probably quite hard to implement without modifying the packaged applications. Needs something like a mechanism of pausing, instead of denying, a system call in the kernel and calling back to userspace, which would then load new policy into the ruleset on the fly and resume execution. Oh and reverse engineer the high level intent of the user / application far enough to present an intelligible question to the potentially nontechnical user.
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.
Doesn't this imply that Linux is falling behind somewhat in the area of permissions management? Personally, i think that limiting access to files and such based on users and groups simply isn't enough and instead the user should be prompted (or should be able to configure) which piece of software is allowed to do what (network access, file system access, talking to specific devices) based on their own individual needs.
> 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.
Depends on your POV I guess, whether you think this model is a worthy one. Personally I think we'd be better off building simpler and more understandable compartmentalization.
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.
Isn't this something that was addressed already years ago by SELinux, even before Android? Personally I prefer to not use it since I don't find it very user friendly but Fedora seems to have it activated by default.
Android only uses the Linux kernel, everything else is completly unrelated to GNU/Linux, besides the lockdown enforced via LinuxSE and seccomp, so Google could naturally make this kind of customization.
In some cases it does request permissions when you try to do things. E.g. sandboxed apps without full filesystem access can open & save files through a 'portal' - the system presents the user with an open/save dialog, and the app gets access to the file or folder they select. Things like screen sharing can work similarly - the system asks the user to approve access for the app.
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.
> One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used?
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.
Because the system can't be intelligent enough for that.
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.
Simplistic response: Apple & Google (A&G) don't want people concerned with what's going on under the hood. It is difficult to explain. Also, imagine that you download something, you pay for it, then it asks a question you do not understand (rights 666 or 777? - what the hell? I don't want the devil on my phone!! NO to 666, Yes to 777)(maybe I will win in the casino). And assumming you 'Deny' and the app doesn't work. And you paid $10 for it. You uninstall, reinstall, and 'Allow'.
(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'.
> People hardly understand Applications. You want to ask them if they can write on X folder? On the OS? Good luck!
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”.
Reminds me of some bizarro Android permission issues, when I wanted to install a TLS client certificate (pfx) file. I downloaded it via web browser to a phone, opened the certificate management app, and the file was grayed out, no explanation, nada. No way to click on it, no error messages, no confusing permission flags in the file list. I thought the format of the file was wrong, so I tried regenerating it a few times in different formats, wasting an hour or two.
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
I don't want to downplay the importance of the problem, but it seems to me, that unfortunately the correct addressing of security concerns is rather an exception, than the norm on Linux desktop. Of course half of the your "ordinary apps" need home write permissions, whether they are installed via flatpak/snap or not. And most semi-technical desktop Linux users have some sort of ~/bin with a bunch of random scripts, and a number of tools installed via pip or directly downloaded from github. (In fact, you probably use Linux on desktop in order to do all these things, because it makes life easier.) And many users aren't even really aware of the contents of their .bashrc and such.
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).
I'm not too sure about "falling behind Windows", personally. The major lines of defense that Windows appears to rely on are code signing and a signature database, with behavioral AV being a relatively recent creation that still doesn't cover a lot of big holes. (for instance: What if I manage to fake my way through an OV/EV cert or use a leaked one? What if I use polymorphic code obfuscation that can generate hundreds of different signatures, but is also used by "legitimate" programs as DRM?) There's SafeSearch, but many people just click past those warnings anyway.
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.
> 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.
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).
Not in my experience - for instance, Discord on Windows when I last used it can register itself to run on user login without ever needing UAC to install itself (it installs to %APPDATA%). It's been months though, so my memory can be hazy.
I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?
I've been experimenting with Qubes and it's the only OS I'm aware of that adequately addresses this issue. It's not usable for non-technical users though without a lot of learning/training and it can be a bit tedious to use sometimes.
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).
Harder boundaries? From what I understand, a hypervisor is much harder to break out of than a FreeBSD jail and provides more isolation between the VMs.
In some ways, things are better there on Windows here, because of code signing - if something isn't code-signed, you get a more prominent warning. I often wish for something like this on Linux (and it would have to be easy to use - no compiling your own kernel with additional modules for example).
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.
> Linux starts falling behind both MacOS and Windows in this regard
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?
All Linux users I know don't use Flatpack/Snap for their sandbox, but much rather for getting the newest version of some UI app (Inkscape) on an older Ubuntu release.
I think this shows that a standard release cycle is not appropriate for desktop users.
Yes, for me the sandboxing is not the immediate benefit.
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.
It seems pretty obvious to me. Some programs aren't going to be very useful if you don't let them access resources on your computer, like the filesystem. Some "stateless" apps will do fine without it (Spotify), but anything designed to create and edit files you want to live outside the sandbox is going to need to access them.
Look at how the Web standbox is designed: of course some websites must access to your camera (Zoom, Jitsi, MS Teams, etc.) yet you still have to give them the permission! And it's a fine-grained permission (don't want to share your microphone, Ok just don't).
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.
The web sandbox is an absolute delight for users. That users can run javascript code from malicious advertising companies without ill effect is a technological marvel. Consider all the shady nonsense advertising companies do today anyway - and imagine if they had full access to your filesystem when they do it! What a horrifying hellscape that would be.
"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!"
Yeah, my development practice also principally centers around having clang repeatedly compile /dev/urandom until it produces a program that does what I wanted.
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?
While I'd like for more portal-based file access integrated in applications, with flatseal you can pretty easily adjust what folders/files a certain flatplak application can access. E.g. I can limit firefox to only the ~/Download & ~/.mozilla directories, instead of the whole of ~. It also allows for configuring stuff like X11, wayland, network, printing and 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.
This response is pretty well-measured, but their closing note rubbed me the wrong way.
>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.
I don't need the security. I don't need automatic updates.
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.
The proper way to do this is to have the file/directory picker run in a separate process (managed by the sandboxing runtime), and the sandbox only grants access to files/directories explicitly picked by the user.
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.
>The proper way to do this is to have the file/directory picker run in a separate process (managed by the sandboxing runtime), and the sandbox only grants access to files/directories explicitly picked by the user.
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 :/
Created an account just to reply to this - there is no "proprietary" API for actions like opening files.
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.
Thanks for a detailed reply and correction on the extent "proprietary APIs" apply (I hope my use of proprietary as in not-an-open-standard does not rub you the wrong way — perhaps "custom APIs" is better): I am happy to hear that it's at least a shared implementation between both for some, very limited things.
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)
The upside of having the system draw file dialogs is that file dialogs from different apps look consistent, rather than getting out-of-place dialogs depending on what toolkit the app used. It might sound silly, but it's a real annoyance, and there are plenty of apps that don't implement any custom preview.
Oh sure, but it's hard to make a one-size-fits-all file chooser. The case in point: Gimp, not using GtkFileChooserNative, even though Gtk started off as the "Gimp ToolKit". Otherwise, Gimp does not get image previews.
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 :)
Thumbnail rendering on GNOME is already sandboxed with bubblewrap, even when you're outside Flatpak: [0] for docs and [1] for code on how they accomplish it.
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.
>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.
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.
File access should, by its very nature, be asynchronous. If you're only introducing asynchronicity to support Flatpak portals, the original code was flawed.
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.
Something akin to the web's permissions notifications “This app wants to access ~/Images/ do you want to allow it. Checkbox: I want to remember this” and a centralized permission manager ?
Flatpak is a package manager which supports repos exactly like traditional package managers. The biggest repo is flathub and there is also one for fedora which is a little more vetted but contains less software.
> 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?
What's the point though? Either the software is evil/has a bug that lets it steal all your data, or it doesn't.
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?
I was trying to address multiple points that sometimes are made here and else where regarding stricter access patterns. This would probably involve a more complex (as in with more options) permission system, or perhaps can be achieved under linux with groups.
> 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.
Right, fix the permission system, every app has its own scratch space, but needs to talk to the os file protection layer to load/save, if you double click a file, it has permission to read it, if you save a file it has permission to write and read it.
Very few desktop apps need permission to read/write files you didn't select manually anyway.
Yes, the point is to have the package manager set sane defaults for every user.
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.
Flatpak allows this, but requires changers to the application so that it calls the correct API's when requesting files outside of the allowed directories.
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.
> All of the examples are apps where the main use is manipulating files on the system.
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.
Flatpak apps can not access root owned files. They run as the user and the typical linux permissions apply. They can only gain access to root if they have filesystem access so they can load malware in to bashrc. The thing is this is exactly the same as traditional packaged linux software. Flatpak only offers the ability for extra security.
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 .
>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.
Yup, it's a classic catch 22. Sandboxing doesn't really work without developer cooperation. But there's little incentive for developers to work on it in apps that are easy to get outside the sandbox - or when it's easy to get extra permissions in a Flatpak.
Containers on the desktop are a symptom of a festering underlying disease. They are not the cure for anything. Modern linux development is extremely rapid pace and is 100% targeted at the needs of the corporate entities paying for the development. This extremely fast pace of change in the kernel and underlying libs, langs, and compilers means that a desktop environment put together 4 years ago cannot realistically compile or run software written today.
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.
> Containers on the desktop are a symptom of a festering underlying disease.
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.
It seems like some of OP's criticisms of Flatpak are not actually criticisms of Flatpak, but rather criticisms of the way Linux works.
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.
Security updates are a huge issue for most “container” formats. Even official image on Docker Hub receive almost zero security updates and most companies seem to have no policy on how to keep container, be it Flatpak, Docker or even LXC containers updated.
Hot take: Per-application sandboxing is (in general) fundamentally flawed idea, as applications are just tools to manipulate data, while data needs to be protected from unintended manipulations, but such protection should not encumber intended manipulations. What manipulation is intended depends on worflow, not application. Such setup can work on phones due to their limited use cases, but not on desktop.
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.
> 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.
That’s false. OpenSSL is part of the runtime[1] and only needs to be updated there.
Ok bad example then, and I didn't know that, but most libs are not part of the runtime :) I just mentioned openssl as an example of a frequently linked library.
I don't have anything against Flatpak but maintain a Snap package and think Snap has made a lot of good design decisions even if it still has rough edges. For a basic application it's pretty easy to package for Snap. A lot of the things that bother Linux power users like polluting their mounted file systems wouldn't matter to regular users. My understanding is they support either pre-declaring permissions or requesting them at run time.
If Flatpak security is this much of a joke, why do people go through the trouble of using it? Flatpaks are outright cumbersome, and bar-none my least favorite way to install anything. Have a local GTK/Qt theme/colorscheme? Gotta manually patch it in. Have a small main drive? You can store maybe three or four Flatpak'd apps. Slow internet connection? Good luck, you'll be here a while. All of it boils down into the outright worst way to distribute software on Linux. I'd rather use Snaps, which should be taken as a violent insult to anyone who's familiar with the medium. Nowadays, if I see that an app is exclusively distributed through Flatpak, I'll compile it from source or find an alternative.
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?
This is quite late, but I thought I'd add my two cents. I use Linux as my only daily driver, and in general I use my distro's package manager. I keep secure by not running random executables and keeping updated, but I'm no infosec engineer and there is a 0% chance that anyone who knew what they were doing couldn't work around everything I have.
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.
All the things like flatpak annoy me because I have a gut feeling that capsicum is the most incremental change to unix that is both secure and ergonomic, and all these other things sacrifice one or both of those with tons of complexity.
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).
It doesn't solve that problem, but it does provide a channel that is likely to receive an update in most distributions. It would be nice to not have to choose between sandboxing and security updates, though.
Am I alone in that I really don't like using flatpaks or snaps over debs. All the software I've installed from both tends to be buggy and unoptimized. Inkscape from flatpak crashes, Kate can't access system themes, steam barely works and doesn't understand the permission system. It feels so much like these projects are taking software and stuffing it into a box it was never meant to fit. Also I don't really think the problem it fixes really exists. People who use Linux know what they're installing and I don't sandboxing really achieves anything other than getting in the way.
One thing that gets me about the sandbox of flatpak is that it doesn't seem to be up to the user. If the developer of the app chooses the permissions, then there isn't a fundamental difference for security from having all permissions anyways.
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.
You're thinking about malicious apps, where the developer would just request all permissions they can. But sandboxing is also about limiting the impact of security issues in apps from honest, well meaning developers who (hopefully) won't request more permissions than they need.
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.
A small nit about an aside in the article: Is fcitx "the" East Asian IME for Linux? As a speaker of Chinese as a second language, I use IBus (with libpinyin), which is supported out-of-the-box in GNOME and seems to provide a better user experience than fcitx the last time I checked (which was probably 10 years ago).
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.
How does snap compare to this: let’s say the Chromium snap? It’s advertised as sandboxed but obviously can download files to your Download directory, it can print PDFs etc, access Webcam of course for video conferences. How is sandboxing supposed to work here?
Semi-related. I wanted to run Amarok 1.4 recently (because I had been having a discussion about how no music player on Linux touches MusicBee, and the last one that had promise, before the developers lost their minds, was Amarok 1.4 - yes I know about Clementine etc but MusicBee still wipes the floor with all of them. This is a digression).
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
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:
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.
"People are trying to do things better, I'll say they aren't and not provide a single option that's better" aka "I'll complain about stuff and not do a single thing to improve it".
Basically, nix (and guix, which is based on it) is the only package manager that actually solves the dependency hell problem properly.
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.
Nix doesn’t guarantee binary reproducibility. It does help with reproducing build inputs and the build process, as do the tools used to create Flatpak applications and runtimes—flatpak-builder and BuildStream. Nix can build packages in a sandbox, but the same is true of flatpak-builder and BuildStream.
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.
Thank you for the detailed and informative answer. Sorry for my cocky style, I am by no means knowledgeable on flatpak and I passed judgement prematurely.
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.
There is some overlap and there are a lot of differences. One point of overlap is that Nix makes it easy to install packages that are newer than your os. For example, you could run NixOS 20.09 or Ubuntu 16.04 and have the latest Handbrake or youtube-dl.
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.
AppImage is a convenience layer which doesn't claim to add any security as it provides no sandboxing whatsoever. And the outdated dependencies in images are likely to exist in the AppImage world too.
And this is why I use Qubes and not Snap, Flatpak, or any of these other cobbled-together emperors-new-clothes app package managers. I knew this would happen from the very beginning but as usual, most software developers just shrug it off.
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.
linux desktop is never going to take off and died off when all the money moved to the cloud - it's not the 2000s, you can download windows and run it for free because that's not where the money is anymore. For the average user that's not technically oriented, that's going to be their goto solution.
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.
A single line of code allows any "sandboxed" program to escape from the sandbox. This is not what the word "sandboxed" means for any reasonable definition of "sandboxed".
Am I the only one who sees the irony in it being a scandal for free software to fail to adequately restrict freedom? I just can't imagine an iPhone style restrictions model ever gaining momentum in open source. As much of a prize an App Store would be, it's just too at odds with the culture. I think what makes more sense for open source is to have better tools for monitoring what it's doing. The behavior of some of these programs with things like dns is like the hunger games and you can't trust the system to save you with a top-down permissions model when the system itself is the problem.
Security and open source philosophy are two completely orthogonal problems. You can a have an open source system that is the most secure, sandboxed implementation there is. Likewise you can have a completely insecure closed source proprietary system.
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.
Not entirely. A few months ago I was reading about a controversy where the Emacs dev team was concerned about the ethics of conducting an online survey. Can you believe that? That's why I like using their software. You just know people who are that extreme philosophically will never in a million years betray you.
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.
I see flatpak and snap as potential solutions to the problem of distributing proprietary software to Linux. Its in that usecase that I really want sandboxing and where the current solutions are lacking.
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.
