Flatpak – a security nightmare – 2 years later (2020)

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.

[0]: https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/master/R... [1]: https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/master/l...

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.

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.

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...

Opening the mouth is fine, nobody has fallen from the sky fully learned about everything ;).

If you learned something that is interesting or useful to you, then great.