6 ms·

Nobody should be relying on dynamic linking as the primary way they keep their home computer secure. Enough applications statically link their libraries that th

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.
    - rleigh 6y ago
      Running NSS and PAM modules in-process was IMO a historical mistake. Convenient in one aspect, rather inconvenient and impractical in many others. If we were to redo these today, I think we'd do them out-of-process and talk to them over UNIX domain sockets or pipes. The transitive dependencies of NSS and PAM modules can also wreak havoc with your application. There are many bugs which have arisen because of these limitations. Yes, looking at you, GnuTLS.
      - wahern 6y ago
        OpenBSD chose BSD Auth over PAM for this reason. With BSD Auth the C API invokes binaries in /usr/lib/auth which are SUID or SGID according to which permissions are required for the credential store.
    - jcelerier 6y ago
      > Qt (static is possible but a lot of stuff will break), as a user of statically-built Qt I haven't noticed any particular breakage
  - cycloptic 6y ago
    GTK does not support static linking, so that rules out pretty much all GTK applications: https://mail.gnome.org/archives/gtk-list/2018-January/msg00006.html https://mail.gnome.org/archives/gtk-list/2018-January/msg000... The question about it comes up every so often, but nobody has ever put up the effort to maintain it. It appears to be a lot of work for very little gain.
  - hapless 6y ago
    Firefox. Chromium. KDE. Gnome-shell. Libreoffice. Static linking is an atavism. Application authors don't spend time thinking about it any more. The main reason static linking persisted as A Thing into the 1990s was that fossilized vendor UNIXes didn't support it, or didn't support it well. Those systems are all extinct. About the only place you still see static linking is embedded. And that is its own world.
- 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

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.
  - rleigh 6y ago
    Running NSS and PAM modules in-process was IMO a historical mistake. Convenient in one aspect, rather inconvenient and impractical in many others. If we were to redo these today, I think we'd do them out-of-process and talk to them over UNIX domain sockets or pipes. The transitive dependencies of NSS and PAM modules can also wreak havoc with your application. There are many bugs which have arisen because of these limitations. Yes, looking at you, GnuTLS.
    - wahern 6y ago
      OpenBSD chose BSD Auth over PAM for this reason. With BSD Auth the C API invokes binaries in /usr/lib/auth which are SUID or SGID according to which permissions are required for the credential store.
  - jcelerier 6y ago
    > Qt (static is possible but a lot of stuff will break), as a user of statically-built Qt I haven't noticed any particular breakage
- cycloptic 6y ago
  GTK does not support static linking, so that rules out pretty much all GTK applications: https://mail.gnome.org/archives/gtk-list/2018-January/msg00006.html https://mail.gnome.org/archives/gtk-list/2018-January/msg000... The question about it comes up every so often, but nobody has ever put up the effort to maintain it. It appears to be a lot of work for very little gain.
- hapless 6y ago
  Firefox. Chromium. KDE. Gnome-shell. Libreoffice. Static linking is an atavism. Application authors don't spend time thinking about it any more. The main reason static linking persisted as A Thing into the 1990s was that fossilized vendor UNIXes didn't support it, or didn't support it well. Those systems are all extinct. About the only place you still see static linking is embedded. And that is its own world.
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