Workstation, Silverblue: preinstall Flatseal

Fedora by default preinstalls all Flatpaks from the Fedora remote, which is kinds controversial.

I am also not sure if Flatseal is on that remote.

But Flatseal on non-KDE is basically needed to use Flatpaks well and users should use it more.

Preinstalling it as part of the “base apps installed as Flatpaks” could help here.

Background: nearly all Flatpak apps have broad and static permissions instead of using portals, to prevent breakages. As Flatpak does not (yet) follow an opt-in approach similar to Android, Flatseal is needed to opt-out of those permissions and adapt them to the users needs.

1 Like

IIRC, last time I heard about someone porposing Flatseal installed by default the reasoning for not adding it was the same as GNOME Tweaks: it’s a tool for advanced users.

Currently Flatpaks are not well sandboxed, to isolate them more, users often need Flatseal.

Also there are apps with too restrictive permissions, users need flatseal to view them and report them, and try if a fix on their side works, so that they can then do an issue report to get it fixed.

The biggest complaint about flatpak is “apps break”

I’m not convinced this is actually true. I have installed, and use many flatpaks on my system and do not have flatseal installed, and don’t need it, as of yet. I use Netbeans as a Flatpak from the Fedora repo and it is working with the system installed java and the graalvm java I installed in my home folder. I found flatseal was helpful at the very beginning of flatpak use, but as flatpaks have become more available and flatpak the app has become more evolved this “need” has largely disappeared.

Some actual specifics would be useful to back this generalized claim up. I do think there are currently some flatpakkers who do it better than others. I think that Gnome Builder is a solid example of how to do a flatpak proper.

1 Like

My current thinking is:

  • We could add app permissions configuration similar to KDE to System Settings. But we would only allow removing permissions and not adding new permissions.
  • Alternatively, just remove applications that declare unsuitable permissions, like filesystem access or session bus access. Flathub is very successful now and has enough power to crack down on unsuitable extra permissions.

That anecdote is not that helpful, I agree that Flatpak permissions have “improved” but I have multiple examples

GNUmeric (and tons of other apps) have the wrong issuetracker linked, the main dev has no idea of flatpak and permissions are too restrictive without supporting portals. You need flatseal to unbreak it.

GIMP, Libreoffice, Inkscape and tons more (unknown) programs all have host filesystem permissions. This is basically just the home and mounted drives, due to how restricted Flatpak is (luckily).

Still, those apps could all catch your

  • .bashrc and other shells
  • all dotfiles
  • all ssh keys
  • all gpg keys

Security on such a system is just a ticking bomb. For sure there is a review process, but there are proprietary apps on Flathub, which is added unfiltered by default (see my list of flatpak remotes with the subsections that would be possible). Proprietary apps can do whatever they want.

For sure this needs to be fixed upstream, but the current solution is encouraging users to manually reduce that attack surface. That solution is really really bad, but it is the current one.

A better solution would be dividing the home access into various xdg-directories how @pkmays did. Setting actual requirements, forcing apps to comply.

But neither Desktop Linux nor Flatpak have the marketshare to do that, so all those legacy apps are still unconfined (btw they will likely also not work with SELinux Confined users, as they are not Fedora Flatpaks).

What you are talking about is “not needing to allow more access to unbreak apps”. This is not the purpose of sandboxing.

I think GNOME and KDE should implement opt-in permissions, installing all flatpaks with 0, distros dividing home into these xdg-dirs and then prompting for every needed permission.

Until that is done (standard on Android, IOS and even modern MacOS apps), preinstalling Flatseal is the least we can do to empower users.

Viewing at permissions is not techy or whatever, its like looking at settings, its an easy GUI. (Android does that, f**ing Android, which is made for noobs that dont care at all).

GUIs are there so users have a lot to look at, everything presented, and they can learn from what they see. Learn about how Flatpak works, restrict permissions, try if apps break, reset permissions, force apps to run through Wayland, try environment variables, …

This is just empowering, the alternative is having a “community” of

  • developers that understand flatpak
  • users that use GNOME (as it is extremely pushed as “Workstation”, which I find reasonable) and have no idea how Flatpak works, what exactly their problem may be, how to report errors and how to fix their own issues.

If we want to be a community, users need to be empowered. I think GNOME is elegant and stable, but it doesnt empower users at all. Detailed settings, custom app entries, “poweruser GUI” is all not there.

GNOME outsources this to external Apps, and Flatseal is such an app.

KDE has these settings integrated, a very reasonable choice. GNOME does not, plus it is the default DE for Fedora.

If Flatpak should become the future packaging format, users should at least be able to look at their permissions and understand them a bit. If GNOME doesnt want to be such a desktop, and there is a perfect app for that, why not just use it?

I am on Lemmy giving people advices every day, and many that have problems with Flatpaks never used Flatseal. Preinstalled Apps is a thing, people stick to defaults.

/end of rant

Interesting idea, that would need to be done upstream?

But we would only allow removing permissions and not adding new permissions.

That doesnt work, how would you remove home permission without adding xdg-documents xdg-downloads etc. as an alternative?

applications that declare unsuitable permissions

This also doesnt work.

xdcd meme

If an app has host or home permission is a tiny difference. Nearly no user will store personal files only on externally mounted drives, to prevent flatpaks from accessing it.

I maintain a list of recommended Flatpak Apps

This is currently the only way to recommend apps, as only apps without any static filesystem permissions are secure. And this is so little, that flatseal is de facto required.

(I could add that the Fedoras setup “add external repos” dialog also completely wastes potential here. It could allow specifying exactly what repos, with detailed explanations on what they do (with an “i” button) and allow to add flathub subsections, see my above link)

Usually the way to make an app not need host or home permission is for it to have implemented the FileChooser support.
This would either be done manually via D-Bus or by upgrading to a newer version of the GUI framework. Thing is that most apps usually have a reason to have not upgraded yet (best case scenario it’s due to breaking changes that have to be fixed slowly, worst case scenario it can be due to conflicts with the goals of the project and the direction of the toolkit).

For example, I maintain Chibitracker, it would basically impossible to do permissions in any other way than home or host permission due to it being a very old simple SDL1.2 application that implements its own file chooser.

I know that, by default, even with host permission apps won’t have ~/.var access.
This means that flatpaks usually won’t have access to other flatpak apps internal files unless given explicit access. You can try that with baobab, if you want an example.
This should mean that it could be possible for flatpak to by default hide the .ssh and .gnupg folder as well (assuming it doesn’t do so yet) and only expose to apps which need it.
Shell-specific files might also have a way to do the same, though I’m not sure how to hide every single dotfile folder/file aside from the ones defined in xdg (.local, .config, .cache, etc)

If you mean “give a dialog that asks for access for the Music folder or the Videos folder” that likely would require a portal which would have to be implemented by the application. If we are going to ask for the app developer to implement a portal wouldn’t it be much better to just implement the FileChooser portal?
For other types of permissions (non-filesystem), sure, it still would probably require a portal that would have to be manually implemented by the app developer.

Also, the xdg-dirs separation already exists which can be used on Flatseal already (and even some extra stuff such as gvfs).

AFAIK most Android devs refused to support targetSDK 23 (Android M, which added runtime permissions) until they were forced to, otherwise they would be unable to send updates or submit new apps. And the Android system still has to support apps with a targetSDK older than 23 (Android 14 still supports those apps, even if you only are able to install via adb with a specific flag to bypass the block).

When you run a pre-targetSDK 23 app on Android M+ it just asks for all permissions (or the app stores grants them) and if you remove any of them the app might mysteriously break because the apps weren’t planned around runtime permissions.

Have you seen the chaos when Android implemented Scoped Storage? Yeah, not fun.

(Source: I am a Mobile Developer, while I wasn’t working yet in that area for the runtime permissions migrations I had to deal with the scoped storage and package visibility restrictions on recent Android)

GNOME has a GUI on the Settings app that allows adjusting some (not all) of the flatpak apps.
I would likely agree that they may be very few of the possible settings.

Just to be clear, GNOME can show some of the Flatpak settings under the Settings tab of the Settings app and the permissions of the app are shown on GNOME Software (it’s on the place that shows how secure the app is based on its permissions)

Essentially the only way this could be done is if the app is thought out in a way that flatpak and portals are taken into account.
The same way Android M added the runtime permission system and had to be forced upon Android devs and later Android 10/11 added Scoped Storage which further restricted Android storage permissions…
There’s basically no way this can be done without the app dev doing their work. You either keep the app working in a insecure way or break it to make it more secure.

Electron implemented support for Wayland and the portals a while back, but I guess Discord has yet to migrate to a newer Electron support with thoise features, so…

1 Like

Hi, yes its often for strange reasons that projects dont implement portals, poorly. Thanks for the info.

This should mean that it could be possible for flatpak to by default hide the .ssh and .gnupg folder as well (assuming it doesn’t do so yet) and only expose to apps which need it.

Yes absolutely, but then people with IDEs complain about IDEs not being able to interact with ssh or whatever. Opt-in via permission could work, afaik there is an “anti-filesystem permission”. Not sure if it works for singular files though.

But excluding all dotfiles and directories would be a good start.

that likely would require a portal which would have to be implemented by the application. If we are going to ask for the app developer to implement a portal wouldn’t it be much better to just implement the FileChooser portal?

No, that would mean that Flatpaks start with 0 permissions and instead of doing the overrides under the hood, the OS (with stronger simplicity than currently than what we currently have) allows “access to photos” on demand.

Android does this and there are a few steps, its just a different concept to have all permissions opt-in.

Android breakages

I never noticed that but I can imagine that. It may suck that the Playstore has so “high” demands but there are endless apps on there so it worked.

Even if such legacy support is there, it is de facto not used as you normally dont get these apps.

GNOME shows infos

I will have to give it another try. I think GNOME Software shows flatpak permissions really well, like Flathub, KDE Discover not at all.

Essentially the only way this could be done is if the app is thought out in a way that flatpak and portals are taken into account.

Flatpak, Snap, Bubblejailed apps can all profit from portals afaik, and also native apps can use them. Also the filechooser is always the native one, which is a huuuge advantage over seeing a GTK one on KDE or these ugly old Qt dialogs

So lets hope that many devs understand the importance.