Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.
We know some things are *objectively* better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake.
Just the people who are stuck to 1970's way of doing things and fear new things oppose sandboxing.
I get that some packages do actually have sandboxing, but unless it is mandatory and enforced I feel like I'm better off avoiding the ecosystem entirely and dealing with app isolation myself, using containers or VMs.
It may be too hard today. But that's less "Flatpak is a security nightmare" and more "we're not using the features we have very well yet". I feel like some people expected 100% targeted profile for each app or will declare sandboxing a failure. This stuff will take years.
That sounds funny given the facts about Flatpak.
This has been the sandboxing method or choice since the 70s. Filesystem permissions were designed around users and groups, and now everybody's trying to bolt on intra-user access control lists and wondering why the experience sucks so much.
Create a `browser` user. Add yourself to the `browser` group. Maybe give `browser` read access to an area in your docs folder for convenience. Modify your browser launch script. Done.
In the default settings other users could not access the X server. I forgot how that is changed. I changed it once and now just copy the config
Biggest is getting the sound to work. Pulseaudio in system mode should do it. Although it is not recommended to use. And now my headphones do not work reliable anymore. Not sure if it is caused by system mode or by another setting.
And sharing files. Good that the browser cannot change my files, but it works both ways. My normal user cannot change the browser files, sometimes not even access the downloads.
Absolutely. That's why the comment that makes you characterize me as a luddite explicitly referred to the "sandbox everything wave".
Sandboxing has its place. Sandboxing everything (i.e. the "Flatpak way") is what I'm commenting on.
Flatpak, for all of its many faults (and there are a lot of them), is still a strict improvement over the current security model running on most desktop Linux computers. Sandboxing native applications (even partially sandboxing them) is objectively better than the status quo.
It is embarrassing that the Linux community is still having this debate. It is exhausting, it feels like the community has to be dragged kicking and screaming away from a 20-year old security model that every other platform has moved on from.
Because that's what we do on the web. Every app only has access to it's own files and 10 or so standard clipboard formats (and ONLY through the clipboard).
There are security models that allow sharing files that don't give direct access to the entire filesystem. A word processor might need access to my Documents folder, but I might choose not to give it access to anything outside of that folder. Or I might choose to tell it it's been given access to a Documents folder, but really it has access to a VFS mount that is a composite of several folders inside of Documents including some shared folders outside of Documents.
This kind of "portal" idea is incidentally also what browser manufacturers are considering as they start to explore offering native file access[0] (although this is obviously an area that in browsers needs to be approached with a lot of caution). I don't think Google's proposal is the best way to handle this, I think it could be better. But it's still better than what's happening on desktops with native apps.
- have complicated permissions that users misunderstand or can be tricked into misconfiguring through inattention, misleading user interface or fatigue
- aren't actually sandboxes because the isolation they claim isn't actually achieved (I usually call these "security holes")
- are used to artificially force markets (e.g., Microsoft's UWP)
Other than that, they're great.
Signed, cranky, pre-morning-coffee programmer speaking ex cathedra from the 1970s
https://www.acsac.org/2002/papers/classic-multics.pdf
I don't understand how you can honestly, truly say it's "technological ludditism" when it's clear that nobody in this thread is opposing the features that Flatpack and Snap claim to have, which in many forms predate UNIX and predate Flatpack/Snap -- they are just opposing the half-baked implementation that Flatpack/Snap have created.
I skimmed the article and it looks like one thing they do is have a daemon in the background to intercept data in and out, when they could just make user groups and normal file permissions.
I know it's almost a meme at this point, but plan9 had a great system for this.
You were able to define a filesystem layered on top of your own, exposing and linking files/folders however you please to any process.
So say you have a web server. You can make a layer that only has /www and /configs, linked to some folder in /var/foo/webstuff, and /etc/fooserver/configs or something.
No reason why you couldn't standardize an interface for systems like flatpak to safely use your filesystem.
What is wanted is some system that allows one to run untrusted sofware in without fear of it compromising one's system. — the problem is that the set of software that can be so ran is smaller than expected, as most software by design is capable of making changes to one's system, as one typically uses software for such tasks.
A text editor that cannot edit every file in one's home directory would be rather useless, but in doing so, it is of course capable of completely destroying one's system as well.
The dream of being able to run “entrusted software” is not a very realistic one.
App has access to its own config/cache folders, and is implicitly and temporarily granted access to a file or directory on a process-lifespan basis when that file or dir is fed to that app through the file browser or through the application's "open file" file dialog box.
Possibly something more liberal could be granted for read permissions for like a gallery app or a music library thing, but that's what I'd expect for write permissions.
I’m not sure if it’s temporary or process-lifespan basis, but AFAIK macOS’s sandbox does have a model where the user must grant access by using the system-provided out-of-process file dialog for the application to be able to access the files.
Pretty interesting. For an example, try renaming a file in MS Words by clicking on the document icon — you’ll see MS office asking for permission for the access of the parent directory. (Apple does provide rename functionality by it’s APIs, but MS Word does it by it’s own, which requires the permission.)
Spot on. Distros exists for good reasons: you need someone to configure things to work well together and manage security for you.
Including sandboxing: it's being already done with system daemons by systemd and for applications by firejail and similar.
Desktop users want the newest version of their UI apps and don't care so much about stability. Ideally, the developers of e.g. Inkscape would offer the newest version on each Ubuntu version via apt, but that does not seem to be feasible.
I am no Arch user myself, but I think a rolling release is much more suitable for desktop use. I don't have the feeling most people use Snap/Flatpack for their sandbox, but much rather for getting a new version of some software.
Canonical started developing sandboxed packages for Ubuntu phones ("click" packages which evolved into "snap" packages). At about the same time, Canonical was interested in getting other big distributions (RedHat, Suse...) to align on what software (kernel, glibc, GNOME, KDE...) to offer LTS on together, but there wasn't too big of an interest from other distributions (and tbh, I think that's a good thing: upstream open source projects would be strong-armed into caring about only a few versions that monopolist distros decided to base their LTSes on).
It is my guess that Canonical has (post-phones) invested in snaps to reduce the burden of maintaining the desktop and trying to earn some money in the process through the Snap Store. Flatpak seems to be Red Hat's slightly more open response that quickly followed.
The only benefit of Snaps/Flatpak for delivering newer versions of apps over just simply statically compiling everything into an app is that some of the things are shared between snaps (like frameworks, glibc...). You still get all of the same problems (theming, fonts,...).
That's the case for everyone I know (though they mostly use appimages)
[Citation needed]. Can you imagine telling this to someone who is about to present on a conference call, but zoom updated automatically and fails to start now?
I imagine MS has crunched the numbers at some point, and decided that the amount of lost work and interruptions due to forcible updates (especially contrasted with the benefits of updates) is not causing a significant number of people to ditch their OS for a competitor.
I'll answer my question: Companies make decisions on the margin. They don't care that they have 85% of the market. They want that next percentage point.
The users who might switch to or from competitors are precisely the "swing voters" they have to consider.