I don't fully understand what you mean.
With flatpak, you have the option of installing applications on the system (/var/lib/flatpak) or for a single user (~.local/share/flatpak). And application data for each gets stored in ~/.var/app.
AppArmor should confine the same regardless of which user is running the package. Besides, the flatpak's main sandboxing comes from bubblewrap. Though the distro's default AppArmor profiles can further be used to sandbox more stuff.
In general, they don’t interfere. The only major issues I’ve seen are with in development versions of Ubuntu, which have a strange habit of breaking flatpak, but it gets fixed before release.
SELinux tends to have more issues.
Security is hard and not the fun part of programming (for most people anyway).
KDE and Gnome have problems too.
Rationale for Accepting kio-admin into openSUSE
We have dealt with these types of APIs in KDE since 2017 without achieving any notable improvements. As we are responsible for product security we tried to protect our users from potentially harmful components. At this point, though, we don’t believe that this situation will change anytime soon. Meanwhile users still want to use features like the one found in Dolphin, and don’t understand why openSUSE does not include them.
https://security.opensuse.org/2025/02/21/kio-admin-admittance.html
Short version
We don’t believe that the openSUSE Deepin packager acted with bad intent when he implemented the “license agreement” dialog to bypass our whitelisting restrictions. The dialog itself makes the security concerns we have transparent, so this does not happen in a sneaky way, at least not towards users. It was not discussed with us, however, and it violates openSUSE packaging policies.
...
The experience with Deepin software and its upstream during the code reviews that we performed has not been the best. More than once, security issues we reported have been replaced by new security issues. Other times, upstream did not invest the effort to fully analyze the issues we reported and fixed them insufficiently. Generally the communication with upstream proved difficult, maybe also due to the language barrier. While upstream stated at times that they don’t have enough resources to deal with security reports, which is worrying enough, the design and implementation of Deepin D-Bus components often changed radically in unrelated ways. This makes the security assessment of Deepin components a moving target. Building trust towards Deepin components has thus been extremely difficult over the years.
The history of Deepin code reviews clearly shows that upstream is lacking security culture, and the same classes of security issues keep appearing....
The really big one for me is installing things. Installing packages requires 0 interaction, can be easily automated, wide availability of packages, etc. On Windows, Winget sucks. It's just running the regular installers. MacOS is better since it has Homebrew, but it has some problems. Homebrew struggles to update "casks" (aka GUI apps) so you still have to rely on app's in-app updaters. MacOS's gatekeeper also is annoying about third part software. And for anything not in Homebrew, you have to install it from the web.
Programming is also easiest in Linux. MacOS is a pain sometimes. The preinstalled toolchains are outdated. Installing new ones from homebrew also requires reading through a large block of text in order to find out what manual steps you need to do.
Updated the title
Took me a minute to realize they meant two weeks until TWIG #200.
Blood is edited in.
By default, flatpaks have no permissions. All permissions must be manually specified in the manifest file. But if you look at the top apps on Flathub, they tend to have broad filesystem permissions, including home and host. This are pretty bad permissions because it's insanely easy to escape the sandbox with them since there are no protections against writing to files like .bashrc. Snap at least prevents apps from accessing hidden files for this reason.
Flatpak isn’t as strong as a sandbox as Android. But if you tweak permissions, it can be deemed good enough.
If you really wanted security, you’d want to learn SELinux, but that’s a whole rabbit hole of complexity.
The linked blog post about moving from WebKit 1 to 2 was an interesting read: https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/
Chuckled when it mentioned that GIMP 2 was affected but they will be soon migrating to GTK 3… written in 2016.
Oh I understand now, you're referring to making AppArmor profiles to target a specific app. I just did a little research and it's possible to create AppArmor policies for binaries that are in a user's home folder.
Rather than hardcoding a specific user's home, you can instead say "@{HOME}". So you could create a profile for "@{HOME}/.local/share/flatpak/app/appID/current/active/files/bin/binaryName" that would confine the app for all users.