Ok. flatpak has solved distributing an executable across architectures and distros.
That’s a feat that is done. In the can. Complete.
It’s something the distros could not do but it is solved and I’m very happy with it.
What I don’t get is the sandboxing biz. Can someone explain why it’s important to limit what an installed app can do? It’s a spec I’m not understanding.
I guess the idea is to protect users from malware. But I don’t see how limiting the directories an app sees can contribute to helping out this situation.
An app should have full permissions on what the user has access to (it seems to me). Why are we trying to hamstring apps with the home directory or picked directories only?
The limitations just seem like they’re not worthy of flatpak. Flatpak has solved getting apps across distros and architectures. We’ve freed developers from old repos.
Can’t we have something other than flatpak to sandbox apps that feel the need to be sandboxed and call flatpak done and solved?
I mean a system can be whatever it wants. Sure. But you probably understand my question, right? Why the sandboxing when it seems unnecessary (at least to me)…
I’ve always thought the idea of flatpaks being “sandboxed” is so that all of its dependencies can be more easily controlled.
This prevents say a version of a library it depends on affecting (or breaking) other app installations after updates.
It also makes it easier to remove so you can start clean, as you don’t have any remnants left in system files that may or may not affect other apps in your system after being uninstalled.
I’d think dependencies are all in the runtime you’re linking against.
(Or at least the vast majority of it.)
Which is the “totally solved and done” part. At least in my opinion.
filesystem scope and device scope would be the sandboxing.
For example, when I call QFileDialog::getExistingDirectory (widget, title, dir, flags);
Well in flatpak org.kde runtime version 6.6
the dir argument is thrown away and the home dir is where it starts from.
Which seems like a bug to me. But that’s in the name of “sandboxing” i guess?
I carefully store away the dir they picked, so when they open the dir next time it’ll start right there.
But the place that I tell it to start at is dumped in favor of the home dir.
Even though i spec filesystem=host
I mean when filesystem=home is used, I get back a weird dir like:
/run/user/1000/doc/680b21ff/midi
(which i guess is a symlink to the real dir?)
I don’t want my poor users seeing junk like that…
Not sure if that’s due to the sandboxing not being totally done and ready for prod or… why…
ok the getExistingDirectory problem I was having is fixed.
If I pass in QFileDialog::DontUseNativeDialog,
it actually goes to the directory that I want it to start in instead of my home dir regardless of the dir I pass in.
Not sure if this is a proper flatpak thing to do. Maybe only the native file dialog is sandboxed and the “macro one built in Qt” isn’t sandboxed ? I don’t know how to know tho.
Is there a place where the things being worked on in flatpak are discussed?
No it heavily depends on the app. I’ve had to bring my own python version, due to reasons - runtimes don’t help with that.
The other problem sounds more like KDE isn’t handling the portal correctly. If you go via the portal it shouldn’t need a filesystem premission at all. Then again there seems to be an implementation src · master · Plasma / KDE Portal for XDG Desktop · GitLab maybe you’re not using the correct api. I would also expect the KDE filepicker to remember the folder.
interesting. I mean this sandboxing thing implies (in my total guesswork) to amount to
rebuilding the desktop from the ground up. Intercepting and changing many toolkit apis and nooooot breaking things
Which is a pretty big task Hrm. Well. I’ll keep googlin n studyin.
you could say that, but as the app author, you should know better, then the runtime/distro what your app needs.
for e.g. I’ve maintained an app, that would crash on windows (too old) and arch linux (too new), if you had the wrong python version installed. had a bunch of reports for that, but we can’t manage python deps on windows systems. we could ship the correct python version with flatpak.
It might be sensible to keep the user out of the root directory, but otherwise no.
Restricting say a wordprocessing application to the directory where the documents are sounds sensible, but if it were a rogue app it would be able to harm what mattered most to that user - his wordprocessing documents.
Ransomware is a good example of why we don’t want apps to have complete access to your home directory: every app that has that access could both encrypt your data and ask you to pay for decryption, and also steal your data (documents, photos, browser history) and threaten to expose it online.
This isn’t only about malicious apps. Perhaps you’ve got a game that lets players create their own maps and share them on the internet. The game itself is perfectly legitimate and trustworthy. But there’s a tiny mistake in how it loads maps. Someone finds that, and creates a map file that can take over the program and start running code. They post it on the server, and anyone who loads their ‘map’ is vulnerable. But ideally with sandboxing, that attacker can only see the files belonging to the game (saved games, screenshots, etc.), not all your other files.
The same applies for any type of application loading any kind of documents, images, music, anything you might have got from someone else. Which is probably most applications.
For now, we often need to make the sandbox pretty leaky to let apps actually work, e.g. allowing full access to the home directory. The hope is that over time, more apps will work nicely inside a sandbox, and we can gradually close these holes.
File dialogs go through the FileChooser portal. There’s a current_folder option, but the docs mention that
The portal implementation is free to ignore this option.
So it’s not a bug if it doesn’t use the directory you specify. You could still open an issue to request that it behaves differently. Note that this doesn’t depend on the Flatpak runtime - that’s part of what’s inside the sandbox, but the portal implementation is on the outside. The portal implementation probably belongs to your desktop (Gnome/KDE).
That’s basically it, yes. ‘Native’ file dialogs means the app asks the system (via ‘portals’) to display a file dialog and give it the file the user has chosen, so they work with sandboxes. The older way of doing file dialogs is for the app to look at all your files and draw the dialog itself. So non-native dialogs, including the built-in Qt ones, need broad access to the filesystem outside the sandbox. Recent versions of Qt & GTK request native dialogs by default rather than drawing their own.
(This also means that ‘native’ dialogs look the same whichever app they come from. If you bypass them, Qt file dialogs look ugly on Gnome, and GTK file dialogs look ugly on KDE)
saying that sandboxing should solve malware is exactly the same thing as saying gun laws should keep drug lords from killing people.
Malware can’t be prevented.
I believe it’s the toolkit (Qt, GTK) that calls the portal business, right? If it -is- the desktop, please correct me.
If the docs for QFileDialog::getExistingDirectory () say I can pass in a directory to start at and then ignores it and goes straight to the home dir…
Whether that’s a bug or not is kind of besides the point. I mean users want a program’s window to reopen where they sized it to. They want a dir picking dialog to open where they browsed to last.
If your app gets reset back to the center of the screen (lookin at you wayland) or the home directory, umm, that’s something you as the app developer need to fix. Telling your user “oh that’s for the purpose of sandboxing - to keep you safer” - hey man - that’s not gonna fly. People will drop your app and rightly so.
So your users are totally ok with dirs like:
/run/user/1000/doc/680b21ff/midi
Cuz that sure don’t look very pretty to me…
Users will say “what is this directory? why isn’t it in my home directory???”
It just seems like “sandboxing” doesn’t have an exact spec - it’s just what the developer working on this or that portal decides it should be… That’s a recipe for a big headache. particular parts of the gui don’t know enough to properly protect an end user. how could they?
It probably can’t be absolutely prevented, but we can make it harder for malware to work, and limit the damage it can do when it does. That seems pretty evidently worthwhile.
The toolkit calls the portal, but the desktop provides the thing it calls. I’m assuming Qt passes the directory you give it through as the current_folder option to the portal, but then the portal implementation ignores it. That’s actually worth checking, though - maybe it’s not even getting passed to the portal. If you do want to check that, use a tool like Bustle to record D-Bus messages while you try it.
It seems that the deal with the FileChooser portal today is that it gives the sandboxed app access to the file with the real filename, but not the real path. The /run/user/... path is obviously not something you’d normally show to the user, unless they go looking for details to debug something.
The portal methods and behaviour are documented - they have to be similar enough between Gnome & KDE & any other implementations, so there has to be some spec. There’s also a reference for the different permissions a Flatpak app can have.
But of course all of this has come about by people making decisions, and it’s still evolving.
I dunno about sandboxing having anything to do with preventing malware. Anything executing couuuuld be malware and that’s what apps do… Maybe they could wreck slightly fewer things, but linux is pretty easily wrecked
Anyways, thank you for pointing out those links for the docs! I just couldn’t seem to find anything about the whole sandboxing thing and I was all like “whaaat is the deal”…
