4 ms·

> Debian can still compile Firefox from source and patch out trackers and update dependencies, even if at the end of the day it bundles the changes back into an

> Debian can still compile Firefox from source and patch out trackers and update dependencies, even if at the end of the day it bundles the changes back into another Flatpak app. Does that mean I'll download one copy of libThatWasUpdated for every app that uses it? Seems like this is exactly like iOS and Android work. I see the appeal (they are definitely more secure against malicious apps than Linux with apt-get), but the waste of space still bothers me. Docker has the same issue, and didn't really solve it with its layered filesystem (you always need several dependencies, but you can't merge images, so you'll need to install a new copy of some of them). These packages also make it hard to audit the versions of security-critical code installed on my system. It's good that they can be updated separately by the OS, but at least when apt-get was upgrading shared libraries, I could be sure that all programs had the fix. Now I'll need to go dive into each package to know if it should be allowed to run, or if I should wait for the upgrade.

deleted 5y ago
[deleted]
danShumway 5y ago
> These packages also make it hard to audit the versions of security-critical code installed on my system. I think someone else has mentioned this somewhere, but Flatpak exposes information about the runtime it's using -- you can use metadata tools to iterate over the packages installed and check to see if any of them are outdated. I suppose the tooling in that area could be improved, but I suspect that's something that would happen in parallel with more maintainers getting involved in validating/moderating packages. I could easily see a world where you specify a set of minimum runtime versions (or pin an exact runtime version) and set up some rules about what packages you'll allow to run. Importantly, if you do have a critical vulnerability, you can make a list of the packages in your system that would be affected, and if you're willing to re-bundle them you can update the runtime for just them, which means if you're a maintainer you can push that update out immediately for those programs to everyone; you don't have to wait until somebody has finished checking to see if the update breaks a calculator app that doesn't have Internet or file access anyway. I don't think there's anything about Flatpak that blocks this kind of auditing (and the core technology may end up making it easier in the long run). So I do get the criticism, but it seems like the criticism here is more, "we need some more focus given to better userland tools" and not "this is the wrong technical/architectural direction to go." ---- > at least when apt-get was upgrading shared libraries, I could be sure that all programs had the fix Ironically, this is kind of the same behavior that the linked article calls out. You really couldn't be sure about that back then. Plenty of packages embed critical libraries like libsodium and don't use the shared versions. It is very common advice in the Linux world (particularly with games) to embed as many system libraries as reasonably possible, and regardless of whether or not that's good advice, developers do it. So right now, you're trusting package maintainers to catch that stuff and make sure that the dependencies are updated across the board (or converted into calls to shared libraries) even if the source code isn't using shared libraries by default. And after Flatpak, you'll still to some degree be trusting maintainers to do that, and you'll still be trusting maintainers to say that "updating libsodium" means updating every package that depends on it. The difference with Flatpak is that this is now very explicit and obvious to you, which may be a good thing because (in the article's words) it seems that the single shared runtime model "leads people to place more trust than they should" in their ability to ensure that applications are actually using system libraries. ---- > but the waste of space still bothers me I don't have too much to say here, it's a legit worry. I think this mostly comes down to how much space will actually be wasted in practice. Docker seems to be relatively inefficient about this, I'm not sure if Flatpak is better or not. But yeah, it would be good to minimize size as much as possible, I do understand that concern.
goodpoint 5y ago
> they are definitely more secure against malicious apps than Linux with apt-get Not at all.
- danShumway 5y ago
  Unless you're running something like Firejail on your system, yes they are. There are a metric ton of holes to plug in the Linux security model, Linux security is a dumpster fire. But... run Wayland, use Flatpak (and check your permissions), check file access/network access -- these are steps in the right direction, they are security improvements over apt-get. We know that isolation/sandboxing (and in particular filesystem isolation) is going to be an important part of security moving forward. And if you're comparing this to Android/iOS, it's not even a contest, Android/iOS's model of app isolation is unambiguously more secure than an apt-get free-for-all; and repositories like FDroid allow you to set upstream maintainers the same way that you would in desktop Linux environments. If you compare this to the web, it becomes even more obvious that resource/runtime isolation between sites improves security. Increasingly we're looking at not even sharing browser caches between domains, which is even more strict than Flatpak's shared runtimes. Isolation is a failsafe -- it means if something breaks or gets infected, it can't affect everything. It means that remote code injection into a properly sandboxed app can only compromise one app, and not overwrite your bashrc and insert random keyloggers into everything you do. Improvements still to be made, I would not today assume that Flatpak is secure or battle-tested, and it definitely can't do much about X11. But we fix these things piece by piece, and the basic idea itself is still sound.
  - goodpoint 5y ago
    > Unless you're running something like Firejail on your system, yes they are. Which I am, but this is besides the point. > There are a metric ton of holes to plug in the Linux security model, Linux security is a dumpster fire. Please don't spread FUD. Perfection does not exist in this world but Linux is used in most security critical environments in the world, from banks to military applications to security devices like firewalls. > But... run Wayland, use Flatpak (and check your permissions), check file access/network access -- these are steps in the right direction, they are security improvements over apt-get. Sandboxing and installation tools like apt-get are completely orthogonal topics. Flatpak blurs the line and people get confused. Furthermore, sandboxing can be effective only if the whole UX is designed and tested centrally. Applications need access files in ways that are compatible with each other and useful for the end users. Policies need to be written and reviewed by a trusted organization. You can't rely or random upstream authors to configure sandboxes for different applications independently from each other. Sample the sandbox settings on some flatpak applications and you'll find they range from too strict to completely lax. > Android/iOS's model of app isolation is unambiguously more secure than an apt-get free-for-all And yet the phones are full of spyware/telemetries antifeatures. > I would not today assume that Flatpak is secure or battle-tested It's not.

deleted 5y ago

[deleted]

danShumway 5y ago

> These packages also make it hard to audit the versions of security-critical code installed on my system. I think someone else has mentioned this somewhere, but Flatpak exposes information about the runtime it's using -- you can use metadata tools to iterate over the packages installed and check to see if any of them are outdated. I suppose the tooling in that area could be improved, but I suspect that's something that would happen in parallel with more maintainers getting involved in validating/moderating packages. I could easily see a world where you specify a set of minimum runtime versions (or pin an exact runtime version) and set up some rules about what packages you'll allow to run. Importantly, if you do have a critical vulnerability, you can make a list of the packages in your system that would be affected, and if you're willing to re-bundle them you can update the runtime for just them, which means if you're a maintainer you can push that update out immediately for those programs to everyone; you don't have to wait until somebody has finished checking to see if the update breaks a calculator app that doesn't have Internet or file access anyway. I don't think there's anything about Flatpak that blocks this kind of auditing (and the core technology may end up making it easier in the long run). So I do get the criticism, but it seems like the criticism here is more, "we need some more focus given to better userland tools" and not "this is the wrong technical/architectural direction to go." ---- > at least when apt-get was upgrading shared libraries, I could be sure that all programs had the fix Ironically, this is kind of the same behavior that the linked article calls out. You really couldn't be sure about that back then. Plenty of packages embed critical libraries like libsodium and don't use the shared versions. It is very common advice in the Linux world (particularly with games) to embed as many system libraries as reasonably possible, and regardless of whether or not that's good advice, developers do it. So right now, you're trusting package maintainers to catch that stuff and make sure that the dependencies are updated across the board (or converted into calls to shared libraries) even if the source code isn't using shared libraries by default. And after Flatpak, you'll still to some degree be trusting maintainers to do that, and you'll still be trusting maintainers to say that "updating libsodium" means updating every package that depends on it. The difference with Flatpak is that this is now very explicit and obvious to you, which may be a good thing because (in the article's words) it seems that the single shared runtime model "leads people to place more trust than they should" in their ability to ensure that applications are actually using system libraries. ---- > but the waste of space still bothers me I don't have too much to say here, it's a legit worry. I think this mostly comes down to how much space will actually be wasted in practice. Docker seems to be relatively inefficient about this, I'm not sure if Flatpak is better or not. But yeah, it would be good to minimize size as much as possible, I do understand that concern.

goodpoint 5y ago

> they are definitely more secure against malicious apps than Linux with apt-get Not at all.

danShumway 5y ago
Unless you're running something like Firejail on your system, yes they are. There are a metric ton of holes to plug in the Linux security model, Linux security is a dumpster fire. But... run Wayland, use Flatpak (and check your permissions), check file access/network access -- these are steps in the right direction, they are security improvements over apt-get. We know that isolation/sandboxing (and in particular filesystem isolation) is going to be an important part of security moving forward. And if you're comparing this to Android/iOS, it's not even a contest, Android/iOS's model of app isolation is unambiguously more secure than an apt-get free-for-all; and repositories like FDroid allow you to set upstream maintainers the same way that you would in desktop Linux environments. If you compare this to the web, it becomes even more obvious that resource/runtime isolation between sites improves security. Increasingly we're looking at not even sharing browser caches between domains, which is even more strict than Flatpak's shared runtimes. Isolation is a failsafe -- it means if something breaks or gets infected, it can't affect everything. It means that remote code injection into a properly sandboxed app can only compromise one app, and not overwrite your bashrc and insert random keyloggers into everything you do. Improvements still to be made, I would not today assume that Flatpak is secure or battle-tested, and it definitely can't do much about X11. But we fix these things piece by piece, and the basic idea itself is still sound.
- goodpoint 5y ago
  > Unless you're running something like Firejail on your system, yes they are. Which I am, but this is besides the point. > There are a metric ton of holes to plug in the Linux security model, Linux security is a dumpster fire. Please don't spread FUD. Perfection does not exist in this world but Linux is used in most security critical environments in the world, from banks to military applications to security devices like firewalls. > But... run Wayland, use Flatpak (and check your permissions), check file access/network access -- these are steps in the right direction, they are security improvements over apt-get. Sandboxing and installation tools like apt-get are completely orthogonal topics. Flatpak blurs the line and people get confused. Furthermore, sandboxing can be effective only if the whole UX is designed and tested centrally. Applications need access files in ways that are compatible with each other and useful for the end users. Policies need to be written and reviewed by a trusted organization. You can't rely or random upstream authors to configure sandboxes for different applications independently from each other. Sample the sandbox settings on some flatpak applications and you'll find they range from too strict to completely lax. > Android/iOS's model of app isolation is unambiguously more secure than an apt-get free-for-all And yet the phones are full of spyware/telemetries antifeatures. > I would not today assume that Flatpak is secure or battle-tested It's not.