7 ms·

Except that with "old school" package managers you get security updates without the application or the developer having to act on it. I don't know if it's "a ni

by haolez 6y ago

Except that with "old school" package managers you get security updates without the application or the developer having to act on it. I don't know if it's "a nightmare", but it's worse security comparing against the previous solution.

danShumway 6y ago
Nobody should be relying on dynamic linking as the primary way they keep their home computer secure. Enough applications statically link their libraries that this is not a reliable strategy. If you can't trust a library author to keep their code up to date, it's probably also a mistake to trust them to use your system libraries in a way that minimizes their attack surface. I also have problems with Flatpak's security model, particularly with their UX around permissions. We already learned from Android/iOS that allowing highly permissive manifests out of the box was a bad idea. But at least Flatpak is trying to do something, and that something seems like a tangible improvement to me. The idea that our systems will be secure because we dynamically link everything needs to die; it's not a viable security model. Even if the only thing that Flatpak does is kill the "dynamic libraries make me secure" perspective, that on its own will be worthwhile.
- hapless 6y ago
  Static linking is dead. Most applications cannot be built statically, at all. Solaris-style RPath is still an option on Linux, but it is rarely used. As far as “security,” dynamic linking is not an attempt to contain applications, but rather to fix as many things as possible with as few updates as possible. Flatpak actively encourages upstream developers not to participate in the wider picture, and as it turns out, upstream developers can’t be trusted to fix security holes in a timely manner. This was a widely foreseen issue that was pooh-poohed in the early days of flatpak, but, well, look how it turned out.
  - otterley 6y ago
    > Most applications cannot be built statically, at all. That’s a pretty bold claim. Can you identify a specific C program that cannot be built statically, no matter how hard you try?
    - gray_-_wolf 6y ago
      > identify a specific C program Well, not sure about C (but I assume something using gtk could be pain), but if we expand that to C++, I mean, I would expect firefox and chrome to be basically unbuildable in static manner. > no matter how hard you try Well, no. If you are willing to rewrite it (even significant changes), of course it will be possible to built it statically. That does not mean it is doable in practice.
    - franga2000 6y ago
      I doubt they meant "no matter how hard you try" nor were limiting this to C programs only. Something the size of Firefox, for example, with hundreds of files, multiple languages and dozens of platform variations, is simply not designed for a fully static build and trying to modify it to build like that would be an absurd amount of work for basically no reason, so it hasn't been done and probably never will be. Add licensing complications to that (Qt is notorious for this) and OP's statement is for all intents and purposes true.
      - otterley 6y ago
        Perhaps so, but Firefox is but one program among the hundreds or thousands that are available in a typical Linux distribution. "Most" implies a quantitative analysis (i.e., more than half), which I think is disputable.
      - hapless 6y ago
        Firefox has a hard dependency on GTK, so it is literally unbuildable as a static binary.
    - marcthe12 6y ago
      Certain libs use dlopen() which needs dynamic linking. Mesa, Pam, Qt (static is possible but a lot of stuff will break), Glibc(static is possible but nsswitch.conf will break), Alsa. So most graphical apps will fail to be pure static(Prob possible but will hardware/config specific). So we need to tackle and provide alternatives to dlopen.
  - jart 6y ago
    The two weaknesses cited by the OP to support your argument were CVE-2019-17498 and CVE-2020-12284. That means if you use the RedHat's App Store to illegally torrent media content and pentest strange ssh servers, you might get pwnd. Tears are flowing to mine eyes.
  - remram 6y ago
    A lot of languages like Rust and Go (but also C++) mostly do static linking.
    - hapless 6y ago
      Golang doesn't really support static binaries. This may be confusing, since it compiles-in all golang dependencies, but by default, all output is dynamic, and it's quite difficult to get static binaries out of it at all. The golang model expects all golang deps to be distributed as source code, and then it expects to dynamically link to all C dependencies. It is technically possible to diverge from the latter set of expectations, but it is not easily or commonly done. C++ is much like golang in that respect. Template libraries are always "static" in the sense that they are distributed only as source code, but the final binary output is almost always a dynamically linked binary.
- haolez 6y ago
  Distribution packagers often remove statically linked libraries from upstream and make the software dynamically link anyway. I'm not saying that the UX of native packages is great for end users. I'm just saying that the security model is saner.
  - danShumway 6y ago
    That cat is already out of the bag. How many Ubuntu users have custom software sources enabled; how many of them are installing games from Humble Bundle that come as their own `deb` packages with statically linked assets? GoG installed Linux games don't even use the package manager at all. Heck, there's a decent amount of Linux software being distributed right now as `tar.gz` files with an install script that just extracts the folder someplace and then modifies the user's path. Flatpak improves on all of that. It's one thing to look at the Linux security model and say that OSS authors should coordinate with distros, but OSS authors and general Linux developers already don't do that today. So how is Flatpak making that situation any worse? Developers were already abandoning the sane security model. Flatpak is a response to that trend, not the cause of it.
    - cycloptic 6y ago
      >How many Ubuntu users have custom software sources enabled; how many of them are installing games from Humble Bundle that come as their own `deb` packages with statically linked assets? I don't have an answer to this question, but I would never do this. If the game was open source, I would rebuild it to be dynamically linked, and then publish the dynamically linked package.
      - danShumway 6y ago
        If this is genuinely your philosophy then Flatpak isn't a real problem for you because you can take any OS application that's bundled with Flatpak, rebuild it to be dynamically linked, and then publish the new package using whatever package manager you prefer.
        6y ago
- kevincox 6y ago
  The distribution can recompile dependent packages if required without requiring the upstream program to release a new version no matter how the libraries are linked.
  - danShumway 6y ago
    In which case, the problem isn't Flatpak, it's packages that are distributed outside of the distro's control. If Ubuntu was the ultimate distributor of every Flatpak on their system, they could also recompile and update the dependencies for those Flatpaks whenever a security risk was discovered. Should we get rid of the AUR while we're killing Flatpak?
    - remram 6y ago
      If applications are distributed by the same people, at the same frequency, linked against the same versions of the dependencies, why have two distribution mechanisms at all? What you're describing sounds like it could be a separate APT channel ("backports", "non-free", "edge", hell call it "flatpak" if you want) but doesn't need another package manager and package format.
      - danShumway 6y ago
        That's what I was getting at -- the defense that package managers handle everything in the existing system falls apart as soon as you start compiling packages from source, adding custom repos, or installing proprietary packages, many of which will statically link their dependencies or use custom versions of libraries. There's nothing a distro maintainer can do about them. The "authors won't keep their own software up to date" point isn't an argument against Flatpak in specific, it's an argument against custom package sources in general. If we really don't trust authors to update their own software, then we ought to be pushing for even stricter sandboxing and system isolation than what Flatpak currently provides. The cat is already out of the bag: people already run software on their system from the AUR, from private repos, from custom Linux installers that just bundle everything into a tar.gzip. Dynamic linking won't save you from them.
    - 6y ago
013a 6y ago
I think the industry has moved past believing that dynamic linking has a net security and usability benefit over static linking/sandboxing, even if you heavily bias toward preferring security. The three most "modern" and popular linux "package managers" made in the last decade (Snap, Flatpak, Docker) all bias toward static linking and sandboxing (in the case of docker, forced sandboxing, but the others are opt-in). Sidenote: I include docker as a package manager in that list because recently I actually ran into a very large and popular command line application that, per their documentation, prefers distribution and execution via docker over anything else: aws-cli. They don't keep any other linux package managers up to date, despite having a package in snap and distributing a .tar.gz. They recommend invoking it via docker. Rather interesting, and I'm surprised we haven't seen a frontend for "docker as a pm" gain traction, to increase usability over "go into your .bashrc and alias aws=docker run aws/aws-cli:latest $*"
- sempron64 6y ago
  I think the industry has "moved past this" because for SaaS platforms, it takes a lot less labor to enforce sandboxing in-house applications on the cloud than to maintain dependencies across the shop. However, for an OS distribution to end users devices, where applications inevitably ask for an are granted MUCH more permissions than they need, this is not a safe model. It is CLEARLY superior for users and for operating system maintainers, or others responsible for user security, to update dependencies using the traditional dynamically linked model. No work needs to be done to consider the compilation tooling of each individual application. The existence of Flatpak etc. is a misguided concession from the FOSS community to private businesses and to software developers who are used to packaging for the cloud. The model is not appropriate for desktop or mobile software -- there is a reason that filesystem access is extremely restricted or impossible on mobile platforms, and that even Android has moved to dynamically prompting for permissions when apps use them rather than bundling them into a single prompt at installation. For Flatpak to work, we need MUCH heavier sandboxing, which will be detriment to productivity for desktop users for certain classes of applications, and may prevent many types of applications from being packageable as Flatpak. I think this is a fine compromise. I'm OK with installing Spotify as a Flatpak (given better security, not now) but keeping my webserver, database, file manager, terminal, programming language, and other "system" software in the OS repository.

by haolez 6y ago

danShumway 6y ago

Nobody should be relying on dynamic linking as the primary way they keep their home computer secure. Enough applications statically link their libraries that this is not a reliable strategy. If you can't trust a library author to keep their code up to date, it's probably also a mistake to trust them to use your system libraries in a way that minimizes their attack surface. I also have problems with Flatpak's security model, particularly with their UX around permissions. We already learned from Android/iOS that allowing highly permissive manifests out of the box was a bad idea. But at least Flatpak is trying to do something, and that something seems like a tangible improvement to me. The idea that our systems will be secure because we dynamically link everything needs to die; it's not a viable security model. Even if the only thing that Flatpak does is kill the "dynamic libraries make me secure" perspective, that on its own will be worthwhile.

hapless 6y ago
Static linking is dead. Most applications cannot be built statically, at all. Solaris-style RPath is still an option on Linux, but it is rarely used. As far as “security,” dynamic linking is not an attempt to contain applications, but rather to fix as many things as possible with as few updates as possible. Flatpak actively encourages upstream developers not to participate in the wider picture, and as it turns out, upstream developers can’t be trusted to fix security holes in a timely manner. This was a widely foreseen issue that was pooh-poohed in the early days of flatpak, but, well, look how it turned out.
- otterley 6y ago
  > Most applications cannot be built statically, at all. That’s a pretty bold claim. Can you identify a specific C program that cannot be built statically, no matter how hard you try?
  - gray_-_wolf 6y ago
    > identify a specific C program Well, not sure about C (but I assume something using gtk could be pain), but if we expand that to C++, I mean, I would expect firefox and chrome to be basically unbuildable in static manner. > no matter how hard you try Well, no. If you are willing to rewrite it (even significant changes), of course it will be possible to built it statically. That does not mean it is doable in practice.
  - franga2000 6y ago
    I doubt they meant "no matter how hard you try" nor were limiting this to C programs only. Something the size of Firefox, for example, with hundreds of files, multiple languages and dozens of platform variations, is simply not designed for a fully static build and trying to modify it to build like that would be an absurd amount of work for basically no reason, so it hasn't been done and probably never will be. Add licensing complications to that (Qt is notorious for this) and OP's statement is for all intents and purposes true.
    - otterley 6y ago
      Perhaps so, but Firefox is but one program among the hundreds or thousands that are available in a typical Linux distribution. "Most" implies a quantitative analysis (i.e., more than half), which I think is disputable.
    - hapless 6y ago
      Firefox has a hard dependency on GTK, so it is literally unbuildable as a static binary.
  - marcthe12 6y ago
    Certain libs use dlopen() which needs dynamic linking. Mesa, Pam, Qt (static is possible but a lot of stuff will break), Glibc(static is possible but nsswitch.conf will break), Alsa. So most graphical apps will fail to be pure static(Prob possible but will hardware/config specific). So we need to tackle and provide alternatives to dlopen.
- jart 6y ago
  The two weaknesses cited by the OP to support your argument were CVE-2019-17498 and CVE-2020-12284. That means if you use the RedHat's App Store to illegally torrent media content and pentest strange ssh servers, you might get pwnd. Tears are flowing to mine eyes.
- remram 6y ago
  A lot of languages like Rust and Go (but also C++) mostly do static linking.
  - hapless 6y ago
    Golang doesn't really support static binaries. This may be confusing, since it compiles-in all golang dependencies, but by default, all output is dynamic, and it's quite difficult to get static binaries out of it at all. The golang model expects all golang deps to be distributed as source code, and then it expects to dynamically link to all C dependencies. It is technically possible to diverge from the latter set of expectations, but it is not easily or commonly done. C++ is much like golang in that respect. Template libraries are always "static" in the sense that they are distributed only as source code, but the final binary output is almost always a dynamically linked binary.
haolez 6y ago
Distribution packagers often remove statically linked libraries from upstream and make the software dynamically link anyway. I'm not saying that the UX of native packages is great for end users. I'm just saying that the security model is saner.
- danShumway 6y ago
  That cat is already out of the bag. How many Ubuntu users have custom software sources enabled; how many of them are installing games from Humble Bundle that come as their own `deb` packages with statically linked assets? GoG installed Linux games don't even use the package manager at all. Heck, there's a decent amount of Linux software being distributed right now as `tar.gz` files with an install script that just extracts the folder someplace and then modifies the user's path. Flatpak improves on all of that. It's one thing to look at the Linux security model and say that OSS authors should coordinate with distros, but OSS authors and general Linux developers already don't do that today. So how is Flatpak making that situation any worse? Developers were already abandoning the sane security model. Flatpak is a response to that trend, not the cause of it.
  - cycloptic 6y ago
    >How many Ubuntu users have custom software sources enabled; how many of them are installing games from Humble Bundle that come as their own `deb` packages with statically linked assets? I don't have an answer to this question, but I would never do this. If the game was open source, I would rebuild it to be dynamically linked, and then publish the dynamically linked package.
    - danShumway 6y ago
      If this is genuinely your philosophy then Flatpak isn't a real problem for you because you can take any OS application that's bundled with Flatpak, rebuild it to be dynamically linked, and then publish the new package using whatever package manager you prefer.
      - 6y ago
kevincox 6y ago
The distribution can recompile dependent packages if required without requiring the upstream program to release a new version no matter how the libraries are linked.
- danShumway 6y ago
  In which case, the problem isn't Flatpak, it's packages that are distributed outside of the distro's control. If Ubuntu was the ultimate distributor of every Flatpak on their system, they could also recompile and update the dependencies for those Flatpaks whenever a security risk was discovered. Should we get rid of the AUR while we're killing Flatpak?
  - remram 6y ago
    If applications are distributed by the same people, at the same frequency, linked against the same versions of the dependencies, why have two distribution mechanisms at all? What you're describing sounds like it could be a separate APT channel ("backports", "non-free", "edge", hell call it "flatpak" if you want) but doesn't need another package manager and package format.
    - danShumway 6y ago
      That's what I was getting at -- the defense that package managers handle everything in the existing system falls apart as soon as you start compiling packages from source, adding custom repos, or installing proprietary packages, many of which will statically link their dependencies or use custom versions of libraries. There's nothing a distro maintainer can do about them. The "authors won't keep their own software up to date" point isn't an argument against Flatpak in specific, it's an argument against custom package sources in general. If we really don't trust authors to update their own software, then we ought to be pushing for even stricter sandboxing and system isolation than what Flatpak currently provides. The cat is already out of the bag: people already run software on their system from the AUR, from private repos, from custom Linux installers that just bundle everything into a tar.gzip. Dynamic linking won't save you from them.
  - 6y ago

013a 6y ago

I think the industry has moved past believing that dynamic linking has a net security and usability benefit over static linking/sandboxing, even if you heavily bias toward preferring security. The three most "modern" and popular linux "package managers" made in the last decade (Snap, Flatpak, Docker) all bias toward static linking and sandboxing (in the case of docker, forced sandboxing, but the others are opt-in). Sidenote: I include docker as a package manager in that list because recently I actually ran into a very large and popular command line application that, per their documentation, prefers distribution and execution via docker over anything else: aws-cli. They don't keep any other linux package managers up to date, despite having a package in snap and distributing a .tar.gz. They recommend invoking it via docker. Rather interesting, and I'm surprised we haven't seen a frontend for "docker as a pm" gain traction, to increase usability over "go into your .bashrc and alias aws=docker run aws/aws-cli:latest $*"

sempron64 6y ago
I think the industry has "moved past this" because for SaaS platforms, it takes a lot less labor to enforce sandboxing in-house applications on the cloud than to maintain dependencies across the shop. However, for an OS distribution to end users devices, where applications inevitably ask for an are granted MUCH more permissions than they need, this is not a safe model. It is CLEARLY superior for users and for operating system maintainers, or others responsible for user security, to update dependencies using the traditional dynamically linked model. No work needs to be done to consider the compilation tooling of each individual application. The existence of Flatpak etc. is a misguided concession from the FOSS community to private businesses and to software developers who are used to packaging for the cloud. The model is not appropriate for desktop or mobile software -- there is a reason that filesystem access is extremely restricted or impossible on mobile platforms, and that even Android has moved to dynamically prompting for permissions when apps use them rather than bundling them into a single prompt at installation. For Flatpak to work, we need MUCH heavier sandboxing, which will be detriment to productivity for desktop users for certain classes of applications, and may prevent many types of applications from being packageable as Flatpak. I think this is a fine compromise. I'm OK with installing Spotify as a Flatpak (given better security, not now) but keeping my webserver, database, file manager, terminal, programming language, and other "system" software in the OS repository.