I’m running Kinoite currently, and in response to the recent news about Flatpak patching 2 sandbox escape bugs I went out of my way to make sure my system was fully patched. Only problem is, even fully up to date, it’s running a vulnerable version of Flatpak (1.16.3, patched version is 1.16.4, technically it should be on 1.16.6 as there were 2 hotfix releases afterwards). I did a bit of digging and the issue is that F43 Kinoite’s most recent release build is from the day before the updated packages were uploaded, on Friday. Concerningly, this seems to be the case for every atomic variant other than Silverblue, with Silverblue having a Saturday build and all other release streams last being built on Friday.
Is there any reason for this discrepancy? I assume it’s a build resource thing but I would hope there’d be a process in place to ensure that security critical updates didn’t get delayed by multiple days even if minor updates might…
The patched versions (1.16.4 and 1.16.5) are still being tested. They’ll be pushed to stable once they’re ready.
And while these are security issue, in practice, they’re not that big of a deal. For one, the majority of popular apps already have permissions that make sandbox escape trivial (home or host permissions). Second, the app will have to behave maliciously in order to break the sandbox.
So I’m fine, as long as I’m not relying on the sandboxing features of an application packaging system specifically designed to provide sandboxing features? You’ll have to forgive me for not finding such a blasé response to a security issue reassuring. I prefer not to just leave my door unlocked and hanging open for any random to wander in, personally.
This isn’t actually true for a lot of apps, and it’s extremely presumptive to assume that I happily run such apps unchecked when any halfway competent user can turn those permissions off or modify them. I can’t turn off a security exploit if the patch isn’t being shipped.
Let me be clear, I do care about security. I manually tweak the permissions of my apps to make them more secure.
When I say you’re fine, I’m saying that a couple of days of waiting for the patched version to be be built, tested, and submitted as stable is not going to harm you (the odds it does are minuscule).
This testing period is important. I noted that there were two releases, 1.16.4 and .5. The first release introduced a major regression that necessitated a hotfix (.5). That’s why Fedora has a testing process.
This isn’t actually true for a lot of apps
The words I said are exactly true. If you look at the most popular flatpak apps, the vast majority have these sandbox-breaking permissions. Most people don’t fix these because they either don’t understand how to, don’t care to, and/or don’t want to work around the limitations of doing so.
it’s extremely presumptive to assume that I happily run such apps unchecked when any halfway competent user can turn those permissions off or modify them
And all I can say to that is that it’s good that you’re more security paranoid than most people.
But the fun part about security is that it’s a bottomless pit of paranoia. I could say that you’re insecure because you’re running tens of millions of lines of code that you haven’t vetted yourself, are relying on flatpak instead of strong SELinux policies, are using Fedora instead of something like OpenBSD, and have networking enabled .
Not trying to start a big debate about this, but I have to agree with positron here, I think it’s a bit lax attitude towards something that is described as a critical vulnerability (wether you agree with that classification or not).
Most people don’t fix these because they either don’t understand how to, don’t care to, and/or don’t want to work around the limitations of doing so.
I honestly think you’re underestimating the amount of people that actually do care about these things and actively manages their flatpak permissions.
I could say that you’re insecure because you’re running tens of millions of lines of code that you haven’t vetted yourself, are relying on flatpak instead of strong SELinux policies, are using Fedora instead of something like OpenBSD, and have networking enabled .
So why bother fixing any security issues then? Not a fan of this attitude.
Of course it’s important that the packages are tested properly, and the delay is understandable in this case, but I think there are more productive ways than to dismiss users security concerns this casually.
So why bother fixing any security issues then? Not a fan of this attitude.
Not saying that at all, that bit is mostly just a joke about the iceberg of security.
Despite what I said above and below, I care about security. I use flatpak and tweak permissions. If an app doesn’t have a flatpak, I even have a script I use to create a flatpak sandbox specifically for that app. I plan to create a wrapper to launch apps with enhanced syscall filtering (because flatpak’s default filtering is rather light). I use hardened browsers and would be using GrapheneOS (if it wasn’t for my damned carrier lying to me… anyway, unrelated).
It’s just that despite this being a “critical” issue, it’s still quite a low risk compared to the known about and even intended security holes present on every system that will not be addressed anytime soon. Compared to those, waiting a few days for a patch for a bug that is fixed upstream is actively and on its way to Fedora is not worrying to me.
I think there are more productive ways than to dismiss users security concerns this casually
I don’t mean to be dismissive there’s just a couple of factors that lead me to believe waiting a few days for the fix is not a big deal
The exploit is fixed upstream is actively and on its way to Fedora
The exploit does not seem to be a 0 day (no known people using it to exploit people)
The exploit is not 0 click (you’re not going to get pwned by just having your computer turned on)
To use it, a app must be…
malicious, which is unlikely as neither Fedora Flatpaks nor Flathub have unvetted apps
compromised, which is more likely, such as through a browser vulnerability. But even in this case, now you have to work under the assumption that not only does the app has a known vulnerability that can be exploited, they will also take the time break out of the flatpak sandbox using this vulnerability (and keep in mind, for the vast majority of users, they don’t have to use this exploit! it would be easier to use the other sandbox escapes allowed by permissions like home/host)
I would be concerned by this vulnerability if it was not fixed upstream and Fedora wasn’t preparing an update. But it is patched and an update is on its way.
I get that, I don’t have a major issue with this specific case and flatpak portals can be disabled anyway to sort of mitigate this issue until the fix is in place.
I just think that the notion that there are easier/worse exploit paths isn’t very helpful or reassuring and in my opinion isn’t a great approach towards improving security in general. Not a security researcher so maybe I’m just fighting windmills
.