6 ms·

I'd like to see the defenders of dynamic linking who claimed that it's good for security step up now :-)

by vegai 16y ago

iuguy 16y ago
That's a bit like saying that the defenders of SSH who claimed it's good for security should step up when there's a vulnerability. I'm not quite sure what benefits dynamic linking is supposed to offer by way of security over static, other than when you upgrade a library due to a security weakness you don't have to relink everything. Static linking would protect against attacks on linkers but dynamic linking offers so many non-security benefits that it's hard to ignore. Having said that, I always keep a statically compiled busybox on any Linux host I run in case something goes wrong with glibc. Too many bad memories from broken RedHat upgrades from years back.
- nuclear_eclipse 16y ago
  > Having said that, I always keep a statically compiled busybox on any Linux host I run in case something goes wrong with glibc I just keep a live CD/USB on hand. A lot easier, and it gives the benefit of a graphical boot that can even access the internet to download further fixes.
  - iuguy 16y ago
    Doesn't work too well for a remote VPS though ;) But I agree, live distros have saved my life (or at least my data) on a number of occasions!
    - nuclear_eclipse 16y ago
      If you botch an upgrade of libc on a remote machine, how does a static busybox help, or do you mean to fix the botched upgrade before rebooting?
pquerna 16y ago
it is better, on average. having 20 random-version-bundled copies of libxml2 for example would make upgrading it a massive pain. i think this actually a better example of setuid binaries burning you more so than dynamic linkers.
- jdp23 16y ago
  About a decade ago there was a security bug detected in zlib. When we grepped through the Windows code, we discovered 46 different copies of it in the tree. It turns out there were actually 47 -- somebody had copied the code and renamed everything.
- doki_pen 16y ago
  False dichotomy. Among the many things that are wrong with this statement, the most important is that usually when upgrading an so, you must rebuild the packages that depend on it. Just ask any Gentoo user. http://dl.suckless.org/stali/clt2010/stali.html http://dl.suckless.org/stali/clt2010/stali.html
  - calloc 16y ago
    That is only true of the application binary interface has changed. Usually this means the developer will update the number associated with the library. Botan is a cryptographic library, it is on version 1.8.10, however its library is at 1.8.2, which means if the application was compiled against version 1.8.3 it will work just as well with 1.8.10 as it would with 1.8.2 as none of the binary interface has changed.
    - doki_pen 16y ago
      This is how it works in theory. It seems that many fixes would involve breaking things. And how do you enforce this behavior of bumping the version? Do all upstream developers agree to your interpretation of what version numbers mean?
      - calloc 16y ago

I'd like to see the defenders of dynamic linking who claimed that it's good for security step up now :-)

by vegai 16y ago

I'd like to see the defenders of dynamic linking who claimed that it's good for security step up now :-)

iuguy 16y ago

That's a bit like saying that the defenders of SSH who claimed it's good for security should step up when there's a vulnerability. I'm not quite sure what benefits dynamic linking is supposed to offer by way of security over static, other than when you upgrade a library due to a security weakness you don't have to relink everything. Static linking would protect against attacks on linkers but dynamic linking offers so many non-security benefits that it's hard to ignore. Having said that, I always keep a statically compiled busybox on any Linux host I run in case something goes wrong with glibc. Too many bad memories from broken RedHat upgrades from years back.

nuclear_eclipse 16y ago
> Having said that, I always keep a statically compiled busybox on any Linux host I run in case something goes wrong with glibc I just keep a live CD/USB on hand. A lot easier, and it gives the benefit of a graphical boot that can even access the internet to download further fixes.
- iuguy 16y ago
  Doesn't work too well for a remote VPS though ;) But I agree, live distros have saved my life (or at least my data) on a number of occasions!
  - nuclear_eclipse 16y ago
    If you botch an upgrade of libc on a remote machine, how does a static busybox help, or do you mean to fix the botched upgrade before rebooting?

pquerna 16y ago

it is better, on average. having 20 random-version-bundled copies of libxml2 for example would make upgrading it a massive pain. i think this actually a better example of setuid binaries burning you more so than dynamic linkers.

jdp23 16y ago
About a decade ago there was a security bug detected in zlib. When we grepped through the Windows code, we discovered 46 different copies of it in the tree. It turns out there were actually 47 -- somebody had copied the code and renamed everything.
doki_pen 16y ago
False dichotomy. Among the many things that are wrong with this statement, the most important is that usually when upgrading an so, you must rebuild the packages that depend on it. Just ask any Gentoo user. http://dl.suckless.org/stali/clt2010/stali.html http://dl.suckless.org/stali/clt2010/stali.html
- calloc 16y ago
  That is only true of the application binary interface has changed. Usually this means the developer will update the number associated with the library. Botan is a cryptographic library, it is on version 1.8.10, however its library is at 1.8.2, which means if the application was compiled against version 1.8.3 it will work just as well with 1.8.10 as it would with 1.8.2 as none of the binary interface has changed.
  - doki_pen 16y ago
    This is how it works in theory. It seems that many fixes would involve breaking things. And how do you enforce this behavior of bumping the version? Do all upstream developers agree to your interpretation of what version numbers mean?
    - calloc 16y ago