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.
Asking out of curiosity, how would someone properly sandbox this use case without having a worse UX?