4 ms·

As a programmer who unfortunately is suckered into doing devops at times, the more I get to just update the openssl library instead of the whole OS whenever a s

by pilif 12y ago

As a programmer who unfortunately is suckered into doing devops at times, the more I get to just update the openssl library instead of the whole OS whenever a security flaw in openssl is announced, the more I'm convinced that dynamic linking was very well worth the trouble. Funny how perceptions change depending on the angle you're looking at a problem.

edgan 12y ago
You are right. Lack of it will be the next wave of security problems
bandrami 12y ago
Oddly enough I was thinking about openssl updates specifically. Did you remember to restart all your long-running clients? (I'm a sysadmin who occasionally gets roped into doing development...) Dynamic linking makes security more difficult to reason about, which is a Bad Thing. It has many pluses, but also many minuses. And with symbol versioning it gets very problematic to actually figure out what your real code path is to begin with.
- yuriks 12y ago
  And when you update all your clients with static linked OpenSSL, did you also remember to restart every single one of them? These seem like equivalent problems to me.
  - deathanatos 12y ago
    Not quite, I think. With a .so, I can ask `lsof` which services on the machine require restart: the ones that haven't are linked to a deleted so. And you wouldn't need to restart the clients with static OpenSSL — you need to recompile them. And with static linking, I'm not sure how you would easily determine the linked version out to say, the minor or the micro. (Perhaps, if this is your OS's thing like nix, the package manager keeps track…)
    - danieldk 12y ago
      Tip for Debian/Ubuntu users: checkrestart from the debian-goodies package is a nice wrapper around lsof that lists running binaries that rely on outdated solibs: http://manpages.debian.org/cgi-bin/man.cgi?query=checkrestart http://manpages.debian.org/cgi-bin/man.cgi?query=checkrestar... https://gehrcke.de/2014/06/good-to-know-checkrestart-from-debian-goodies/ https://gehrcke.de/2014/06/good-to-know-checkrestart-from-de... It not only shows processes that run older solibs, but in the case of services, it will also give you the commands to restart them :).
      - tankenmate 12y ago
        It also shows programs that are still using the old binary that has been deleted (unlinked from the filesystem) but not refcount 0 freed. This can also be used to uncover some forms of hiding that hack attempts use.
    - pmahoney 12y ago
      I don't think that nix would be able to tell you which version of OpenSSL some binary linked statically, as there would no longer be a reference from that binary to /nix/store/xxx-openssl-1.0/lib/libssl.so. Nix generally uses dynamic linking, though the links are to absolute paths to a specific library version, so upgrading OpenSSL requires a recompile much like with static linking. With "normal" dynamic linking, upgrading OpenSSL and restarting some service means you're now running untested code, hoping that the new version of the dynamic lib really doesn't change an interface on which your code depends. But to be fair, this is usually a good assumption.
    - hyc_symas 12y ago
      Not quite, but you've identified a key leverage point. You only need to relink the apps, unless the newly patched library breaks its own ABI. Otherwise, it would be ideal for package distributors and package management systems to ship just a single .o file for an app, and do the final linking at package install time. Then updating a buggy static library doesn't require full recompile of any apps.
- nimrody 12y ago
  Should be relatively easy to make a tool that uses `losf` or similar to get a list of all running processes that depend on a shared library.
_pmf_ 12y ago
It seems you are being downvoted by Go monkeys who drank the static linkage kool-aid.
zzzcpan 12y ago
There are no problems with updates anymore. You don't have to download everything to update a bunch of static binaries. There are things, like bsdiff, that allow you to download and patch only tiny differences related to a security flaw. There is no need for dynamic linking for updates. Really.
- _yosefk 12y ago
  What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all use the Internet for self-updating and stuff and they all need to be patched? How are you going to do that? Also - weakly related - what if you want to use a plugin from vendor A inside the program of vendor B, and they live in the same address space - how are you doing it without dynamic loading?
  - zzzcpan 12y ago
    I don't see a problem with proprietary code bases.
  - wtbob 12y ago
    > What if you have binaries compiled from proprietary code bases… Then don't do that. Seriously, RMS, ESR and others have written a plethora of well-reasoned essays indicating why proprietary software is a poor choice.
    - GFK_of_xmaspast 12y ago
      ESR advocating for something is reason enough to seriously consider the alternative.
    - eropple 12y ago
      So you're admitting that this isn't a solution and you need to change the rules of the game to make it work. Well, I'm convinced.
      - 12y ago
derekp7 12y ago
I personally would like to see a distribution have a mixed policy -- dynamic linking against core libraries that are part of the default / basic OS install, and static linking against low usage libraries. That way, you keep the "update one library package to fix a bunch of programs", yet you also reduce cross dependency issues by limiting the number of library packages a given program is dependant on.
- bandrami 12y ago
  IIRC Snowflake[0] does that (but also has a very experimental per-process view of /usr -- pretty cool stuff, really, but takes some getting used to). [0]: https://github.com/GregorR/snowflake https://github.com/GregorR/snowflake

by pilif 12y ago

edgan 12y ago

You are right. Lack of it will be the next wave of security problems

bandrami 12y ago

Oddly enough I was thinking about openssl updates specifically. Did you remember to restart all your long-running clients? (I'm a sysadmin who occasionally gets roped into doing development...) Dynamic linking makes security more difficult to reason about, which is a Bad Thing. It has many pluses, but also many minuses. And with symbol versioning it gets very problematic to actually figure out what your real code path is to begin with.

yuriks 12y ago
And when you update all your clients with static linked OpenSSL, did you also remember to restart every single one of them? These seem like equivalent problems to me.
- deathanatos 12y ago
  Not quite, I think. With a .so, I can ask `lsof` which services on the machine require restart: the ones that haven't are linked to a deleted so. And you wouldn't need to restart the clients with static OpenSSL — you need to recompile them. And with static linking, I'm not sure how you would easily determine the linked version out to say, the minor or the micro. (Perhaps, if this is your OS's thing like nix, the package manager keeps track…)
  - danieldk 12y ago
    Tip for Debian/Ubuntu users: checkrestart from the debian-goodies package is a nice wrapper around lsof that lists running binaries that rely on outdated solibs: http://manpages.debian.org/cgi-bin/man.cgi?query=checkrestart http://manpages.debian.org/cgi-bin/man.cgi?query=checkrestar... https://gehrcke.de/2014/06/good-to-know-checkrestart-from-debian-goodies/ https://gehrcke.de/2014/06/good-to-know-checkrestart-from-de... It not only shows processes that run older solibs, but in the case of services, it will also give you the commands to restart them :).
    - tankenmate 12y ago
      It also shows programs that are still using the old binary that has been deleted (unlinked from the filesystem) but not refcount 0 freed. This can also be used to uncover some forms of hiding that hack attempts use.
  - pmahoney 12y ago
    I don't think that nix would be able to tell you which version of OpenSSL some binary linked statically, as there would no longer be a reference from that binary to /nix/store/xxx-openssl-1.0/lib/libssl.so. Nix generally uses dynamic linking, though the links are to absolute paths to a specific library version, so upgrading OpenSSL requires a recompile much like with static linking. With "normal" dynamic linking, upgrading OpenSSL and restarting some service means you're now running untested code, hoping that the new version of the dynamic lib really doesn't change an interface on which your code depends. But to be fair, this is usually a good assumption.
  - hyc_symas 12y ago
    Not quite, but you've identified a key leverage point. You only need to relink the apps, unless the newly patched library breaks its own ABI. Otherwise, it would be ideal for package distributors and package management systems to ship just a single .o file for an app, and do the final linking at package install time. Then updating a buggy static library doesn't require full recompile of any apps.
nimrody 12y ago
Should be relatively easy to make a tool that uses `losf` or similar to get a list of all running processes that depend on a shared library.

_pmf_ 12y ago

It seems you are being downvoted by Go monkeys who drank the static linkage kool-aid.

zzzcpan 12y ago

There are no problems with updates anymore. You don't have to download everything to update a bunch of static binaries. There are things, like bsdiff, that allow you to download and patch only tiny differences related to a security flaw. There is no need for dynamic linking for updates. Really.

_yosefk 12y ago
What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all use the Internet for self-updating and stuff and they all need to be patched? How are you going to do that? Also - weakly related - what if you want to use a plugin from vendor A inside the program of vendor B, and they live in the same address space - how are you doing it without dynamic loading?
- zzzcpan 12y ago
  I don't see a problem with proprietary code bases.
- wtbob 12y ago
  > What if you have binaries compiled from proprietary code bases… Then don't do that. Seriously, RMS, ESR and others have written a plethora of well-reasoned essays indicating why proprietary software is a poor choice.
  - GFK_of_xmaspast 12y ago
    ESR advocating for something is reason enough to seriously consider the alternative.
  - eropple 12y ago
    So you're admitting that this isn't a solution and you need to change the rules of the game to make it work. Well, I'm convinced.
    - 12y ago

derekp7 12y ago

I personally would like to see a distribution have a mixed policy -- dynamic linking against core libraries that are part of the default / basic OS install, and static linking against low usage libraries. That way, you keep the "update one library package to fix a bunch of programs", yet you also reduce cross dependency issues by limiting the number of library packages a given program is dependant on.

bandrami 12y ago
IIRC Snowflake[0] does that (but also has a very experimental per-process view of /usr -- pretty cool stuff, really, but takes some getting used to). [0]: https://github.com/GregorR/snowflake https://github.com/GregorR/snowflake