The Gnome Software app in Workstation currently offers flatpak as the default installation option:
For a majority of users this will probably be the least desirable option to choose, since it is generally the largest installation size compared to RPM or Flathub. Additionally both flatpak options are labeled as ‘potentially unsafe’, whereas the RPM version is labeled as reviewed/privileged.
Would it be an idea to move RPM to the start of the list so that it is displayed as the default installation option?
Current order:
$ gsettings get org.gnome.software packaging-format-preference
['flatpak:fedora-testing', 'flatpak:fedora', 'rpm']
I kinda feel like even though it might be less desirable from a purely pragmatic perspective, from the perspective of the fedora ethos it might be a good default?
just that fedora repos have more restrictions to be more in line with project values. maybe possibly have rpm be above flatpak for the reasons you stated though.
That would be a step backwards. Our goal should be to make it as hard as possible for malicious input to take control of your Fedora installation. Currently nobody has figured out a realistic way to sandbox RPM applications with a comparable user experience to what Flatpak is doing.
I’m concerned by the rampant abuse of sandbox holes on Flathub, but even a fully unsandboxed Flatpak application is no worse than an RPM application, and many apps on Flathub really do have strong sandboxing. I think sandboxing is more important than all other considerations combined. If we keep ignoring desktop security, the day will come when we regret it…
I am not familiar with the differences in (relative) safety, but as an end user i do notice that RPM is presented as more ‘safe’ by Gnome Software than flatpak:
RPM
Flatpak
If flatpak is actually safer and preferrable over RPM as you describe, then perhaps the communication should be updated to reflect this?
Apart from this the installation sizes vary greatly, with the Fedora Flatpak option generally being the heaviest in size. The RPM versions are often hundreds of Megabytes smaller. E.g. for a random app (Calibre):
That’s an interesting (and certainly knowledgable) point of view. I’ve always preferred Fedora-packaged RPM’s over Flatpaks (Fedora or Flathub) on non-atomic Fedora editions.
In my opinion even an average Fedora Workstation user has at least as many command-line RPM applications/tools as has GUI apps (which could be Flatpaks). So I wonder if there is a real benefit of Flatpaks on non-atomic systems?
I think the main problem are not the apps it selves. The user can run such rpm based apps as root and so the app has access to the os layer and can damage it as it is not read only.
While on a sandboxed environments the app just has access to the user space and just can be runt by it.
I guess this is also the reason why Fedoras future goal is to change to the atomic desktops to have a more secure environment.
I would like that too. Might be an Gnome issue? Alias missing measurements from gnomes side as it comes as a container like app?
From what i’ve read elsewhere, the immutability is quit trivial to circumvent if you know what you are doing (which many malicious actors probably do), and for that reason is not intended as a security measure but mainly as a management measure for safe deployments and rollbacks?
(source for this was a developer of the Manjaro Immutable project)
flatpak software are newer, and usually supported from their own devs, also while technical users may want to use rpm, they know how to use the command line, the GUI can focus on less tech savvy users
If I am not mistaken, the security issues are not necessarily with RPM’s being run with root/wheel privileges, given that GUI apps rarely need such privileges, but rather how they are sandboxed, and/or what granular permissions the user grants to the apps.
If the goal is to make Fedora desktop editions more secure (and it I agree it should be a goal), then why is the burden of such decisions (choosing between RPMs and Flatpaks) placed upon the user? Why not provide GUI apps to the user OOTB only as Flatpaks? And given that Linux is about empowering users, put such GUI RPMs in a separate repo, which is disabled by default.
I too think it is rather confusing for new users what to choose and what to consider safer. Even experienced users on this forum often recommend RPMs over Flatkpaks, if the RPM packages are available in the official Fedora repos.
Then we have Flatseal. Is it considered mandatory from a security perspective? If yes, then shouldn’t it be installed by default? And to end on a joking note, the installation of Flatseal should be done as RPM or as Flatkpak ?
Just to be clear, I suppose your suggestion only applies to package/software management from the GUI front-end, right? Because if you are suggesting that average Fedora users have to go through hoops to get a working “traditional” system, then this is absolutely not ok and definitely not empowering whatsoever. There is already an alternative that accommodates such user experience in Fedora immutable.
From a security perspective, the absolutely mandatory detail is that users need to understand how Flatpak hosting repositories work, their policies, and susceptibility to supply-chain attacks. Isolation from the system doesn’t matter if the software itself is security or privacy critical. In that sense, there is very good reason the Flatpaks are flagged “potentially unsafe”, it was put there by people who understand how things work.
Correct me if I am wrong (my flatpak knowledge is indeed not up to date), but isn’t the sandboxing determined by the provider of the packages? In the past, most flatpaks opened the whole home directory to the application, as its easier for the maintainers.
When using sandboxing for an application, I tend to say we want to protect from (simplified) …
attackers who maintain packages, or who capture the infra of maintainers
bad practices of developers that lead to vulnerabilities and such
But it was exactly these two people who decided if any sandboxing was provided in the user’s home or if the whole home was opened to their app. We trust those to impose the sandboxing from whom the sandboxing should protect us from. This issue increases when considering the heterogeneous environment in flatpaks/flathub.
Afaik, we have already the widespread issue on mobile apps that developers tend to just get any privilege so that they no longer need to consider any access issue (calendars with mic & cam access an dsuch). When I checked out flatpak in its earlier time (I admit, some time ago), it was the same. Its their competition to quickly produce apps, and add features as quick and cheap as possible, which makes it unlikely to change that, especially in cases where no review of code is possible (and where the audience is users who don’t know about it).
Has flatpak introduced some mitigation about these issues?
Another issue is that flatpak effectively (at least currently) disables the possibility to use SELinux confined users, which are really able to provide that type of isolation of apps, and sysadm_u is on its way to become “usable”, but not yet with flatpaks (and I am not sure if that will become possible).
Not sure if I agree: at least within our Fedora realms, rpms have a homogeneous environment, that rpms have to pass before ending in stable, which excludes a lot of issues. I don’t think the flatpak environment can compete with that, can it? (Again, my knowledge of flatpaks might be not up to date, feel free to correct me).
100%!!! But ironically, this is the reason why I have always avoided flatpaks and focused on my sysadm_u instead of our default unconfined_u (with regards to SELinux confined users - formally no sandboxing, but effectively, I came to the conclusion that at the moment it achieves the desired goal best) But I am open to learn that mentioned flatpak issues have been mitigated?
I admit one major advantage of flatpak for average users though, as it mitigates if users have to use untrusted third party repos or so (or within our default repos, use packages that are only in minor and thus less tested use; although the latter might be a lesser issue). But this can be also mitigated by toolbox (I admit, not an eligible solution for average users)
installing RPMs on traditional DNF fedora highly increases the entropy of the system. it deviates way more from the default state, so outdated packages may cause upgrade issues, pull in old dependencies etc.
In my experience, dnf version upgrades dont work reliably, even on a very minimal system (i use Fedora KDE like I use Kinoite).
flatpaks are only bigger if they use a lot of different runtimes. an issue here is, that GUI stores dont warn if the runtimes are outdated or nearly outdated.
this is possible in the CLI and a big issue.
the CLI has a clear warning
this package uses an EOL runtime!
this should be added
the order of recommendation helps users. In the end, we are in a strange state in between, and nothing is perfect.
My suggestion (food for thought actually) was that if we take the preference of Flatpaks over RPMs as an official standpoint of Fedora regarding security, than more consistent actions should be taken, than to just educate users on this forum when they happen to ask for help. And one such action could be not to provide the average user the option to choose between RPM and Flatpak OOTB. Putting the corresponding RPMs of these GUI apps in a separate repo (not enabled by default) is a possible solution for that action, and it would certainly affect both GUI package management apps (such as GNOME Software or KDE Discover), as well as packages installed via dnf commands.
Empowerment should come with knowledge and responsibility, yet we see here lots of issues caused by users taking advice from the internet without researching the commands/actions they are actually performing. Limiting users in doing wrong by accident is not the same as taking away the options.
I would like to add that I still prefer RPMs over Flatpaks, these are just some ideas drafted following the importance of sandboxing as laid out by @catanzaro .
This will come “when it’s ready”. It is part of Fedora Strategy 2028, with making immutable the “majority of Fedora systems”[1]. Until then, I strongly disagree that defaulting to flatpaks in an otherwise traditional system is beneficial to anyone.
Browsing through this discusion, I think a couple points are worth mentioning.
Some posts express concerns over the extra mass storage space needed for flatpaks. These concerns may be exaggerated as a) cost of mass storage has declined much faster than the inflation rate, and b) many use cases involve data (images, video) orders of magnitude larger than the required software footprint.
Efficient use of developer resources. Many large systems (Octave, Julia, Sage Math, and a number of specialized scientific systems I have used) are not easily ported to multiple linux distros. One of the dfficulties is differences in the configuration of widely used libraries (e.g., gdal, hdf4, netcdf4, proj) across linux distro and between current and LTS packages within some linux distros. Flatpaks allow developers to have a consistent set of libraries across multiple distros. When large systems are packaged by distros, users encounter issues with differences in configurations. Going forward, linux will benefit if more distros drop packages that have well-supported flatpaks and focus efforts on a small number of “core” packages.
“Privileged” is identical to “Potentially Unsafe” but distros don’t want us to label all distro-provided software as unsafe. I think we might be able to change the color, though.
Who cares though? Nowadays cheap SSDs are huge. The sizes are a little misleading anyway; they’re accurate if you only have one app installed, but runtimes are shared by many apps, and everything gets deduplicated.
The benefit is tremendous. If you open a malicious file in a sandboxed application, the compromised application cannot attack the rest of your system unless it also exploits a zero day sandbox escape. That’s expected to be hard.
I think we should. This would be a tough sell, but Silverblue already does it.
Flatpak app permissions are not intended to be modified by users. Flatseal is a great tool for testing and debugging that users should never need to touch. If you find yourself adding or removing permissions, you should report a bug to the application developer.
Yes. It’s secure by default, but the application maintainer can subvert it by adding extra permissions, such as declaring access to the entire home directory, subverting any benefit to having a sandbox. Fortunately, I’m told that new applications on Flathub are not allowed to use such permissions without strong reason, but many existing applications still do unnecessarily (e.g. GIMP and LibreOffice). I think applications that do this should be removed from Flathub unless they have a very strong reason to do so (e.g. Disk Usage Analyzer).
Right. The Flathub ecosystem today is insecure, as you describe. Your concerns have not been mitigated. But unlike Fedora RPMs, where there is no clear path forward to improving security, with Flatpak we have clear options. We should either make it much scarier to install applications with extra permissions, or just delist such applications. (While still accommodating the rare few applications that legitimately need host system access and won’t ever be able to adopt portals.)
I think we could quite plausibly achieve this within the next 5 years, if we mobilize and take the challenge seriously.
selinux confined users might be great for the 1% of users who will attempt to use them, but I care more about the other 99% of users who just stick with our default configuration.
selinux has not gained significant adoption outside Fedora and has no role in the upstream desktop security model. Honestly, we should strongly consider turning this off for desktop users and using it only for servers. It keeps breaking things, and problems are not fixed quickly enough. E.g. one of our headline features of Fedora 40, remote login, never worked and is still broken four months post release. So the cost is pretty high, and the benefit has to be weighed against that cost.
I’m not sure if selinux could really be useful for desktop security, because I don’t know much about it, but if so, I think it would be for hardening services. We really don’t need selinux for applications. Even then, systemd service-level hardening might be more useful, and would benefit all distros, and is more likely to be maintained by upstream service developers. I suspect the best use case for selinux is to lock things down further once services already have upstream systemd hardening, or perhaps to focus on D-Bus services that do not use systemd at all, or other system components.
My suggestions would be (a) make the system-wide policy way more permissive so that it breaks less, and (b) services that wish to use selinux to confine themselves should install their own policies so the Fedora selinux maintainers don’t have to maintain them and deal with so many bug reports. The status quo isn’t working.
I’m not sure what this means. I think RPMs are quite insecure. The system works entirely based on trust. Every Fedora maintainer can very easily install malware on your computer; nobody is going to notice if I add some extra code to a tarball before uploading it to Fedora and kicking off a build. And there are a lot of Fedora maintainers. You just have to trust every maintainer with commit access to the packages that you have installed. So far, this hasn’t been a problem, because I think no Linux distro has ever had a malicious maintainer, as far as we know. But eventually our luck will run out.
Of course, RPMs aren’t bad either. Every alternative packaging format would have the exact same problem, as does every competing operating system; you just have to trust everybody with commit access to the code that you run, and system components generally need to be trusted and privileged. But applications don’t need to be treated as system components anymore.
I continue using primarily Fedora RPMs simply because that’s what we have installed by default, and as a Fedora developer it’s important that I stick as close as possible to our defaults. But we should try to move away from this.
Well-known third-party repos are arguably more trustworthy than Fedora repos simply because fewer developers likely have access to them. E.g. only a handful of people can commit to RPM Fusion, so it’s just less likely that one of those people will be malicious.
toolbx doesn’t provide security.
This is a bit of a separate issue. Atomic distributions can help reduce the potential for users to mess up, but there are still ways to screw up your system. E.g. you have full access to edit things under /etc. And you can set environment variables like GTK_USE_PORTAL=1, which people are still recommending today even though it’s known to seriously break your computer. But at least you cannot uninstall critical system packages, which I see happen far too often.
?
But I am open to learn that mentioned flatpak issues have been mitigated?