4 ms·

In practice this works really well as long as the change is to eliminate an unwanted side effect rather than to change a previously documented behavior. But it

by dsr_ 6y ago

In practice this works really well as long as the change is to eliminate an unwanted side effect rather than to change a previously documented behavior. But it doesn't really matter. What matters is that whatever system is in use needs to have a control system that can quickly and reliably tell you everything that uses a vulnerable library version, and can then apply the fixes where available and remind you of the deficiencies. That metadata and dependency checking can be handled in any number of ways, but if it's not done, you are guaranteed not to know what's going on. If a library is used inside a unikernel, inside a container, inside a virtual machine, inside venvs or stows or pex's or bundles, the person responsible for runtime operations needs to be able to ask what is using this library, and what version, and how can it be patched. Getting an incomplete answer is bad.

Quekid5 6y ago
Absolutely correct. The whole "shared libraries are better for security" idea is basically stuck in a world where we don't really have proper dependency management and everyone just depends on "version whatever". This is interestingly also holding back a lot of ABI breaking changes in C++ because people are afraid it'll break the world... which, tbf, it will in a shared library world. If dependencies are managed properly... not so much. I wish distros could just go back to managing applications rather than worrying so much about libraries. EDIT: There are advantages with deduplicating the memory for identical libraries, etc., but I don't see that as a major concern in today's world unless you're working with seriously memory-constrained systems. Even just checksumming memory pages and deduplicating that way might be good enough.
- ColonelPhantom 6y ago
  So if there is 'proper dependency management' (what do you propose? are we too fixed in versioning, too loose?) how will you fix the next Heartbleed? Pushing updates to every single program that uses OpenSSL is a lot more cumbersome (and likely to go wrong because there is some program somewhere that did not get updated) than simply replacing the so/dll file and fixing the issue for every program on the system. And in case your definition of proper dependency management is 'stricter', then you simply state that you depend on a vulnerable version, and fixing the issue will be far more cumbersome as it requires manual intervention as well, instead of an automated update and rebuild. If it is looser, then it will also be far more cumbersome, as you have to watch out for breakage when trying to rebuild, and you need to update your program for the new API of the library before you can even fix the issue at all.
  - bjourne 6y ago
    No, it is not cumbersome to reinstall every program that relies on OpenSSL. My /usr/bin directory is only 633 MB. I can download that in less than a minute. The build is handled by my distro's build farm and it would have no problem building and distributing statically linked binaries if they ever became the norm.
    - zxzax 6y ago
      That is going back to the same issues with containers, where everything works just fine... as long as you build it from your own statically-configured repo and you rebuild the whole system every update. It's useless once you try to install any binaries from an external package source. And IMO, a world where nobody ever sends anyone else a binary is not a practical or useful one.
      - bjourne 6y ago
        Yes? Rebuilding and (retesting!) the system on every major update is not a bad idea at all. I rarely install binaries from out-of-repo sources so that is not a great problem for me. And those I do install tend to be statically linked anyway.
variaga 6y ago
>In practice this works really well as long as the change is to eliminate an unwanted side effect rather than to change a previously documented behavior ...and then you deploy and discover that somebody was depending on that "unwanted" side effect.
adrianmonk 6y ago
I strongly agree that the reporting and visibility you're talking about are important. But there's one other advantage of the shared library thing, which is that when you need to react fast (to a critical security vulnerability, for example), it is possible to do it without coordinating with N number of project/package maintainers and getting them all to rebuild. You still do want to coordinate (at least for testing purposes), but maybe in emergencies it's more important to get a fix in place ASAP.
zepearl 6y ago
> In practice this works really well as long as the change is to eliminate an unwanted side effect rather than to change a previously documented behavior. I fully agree with that, didn't understand the rest.
- dsr_ 6y ago
  Let's say you are building a web-based file upload/download service. You're going to write some code yourself, but most components will come from open-source projects. You pick a base operating system, a web server, a user management system, a remote storage system, a database, a monitoring system and a logging system. Everything works! Now it's a month later. What do you need in ongoing operations, assuming you want to keep providing reasonable security? You need to know when any of your dependencies makes a security-related change, and then you need to evaluate whether it affects you. You need to know which systems in your service are running which versions of that dependency. You need to be able to test the new version. You need to be able to deploy the new version. It doesn't matter what your underlying paradigm is. Microservices, unikernels, "serverless", monoliths, packages, virtual machines, containers, Kubernetes, OpenStack, blah blah blah. Whatever you've got, it needs to fulfill those functions in a way which is effective and efficient. The problem is that relatively few such systems do, and of those that do, some of them don't cooperate well with each other. It's plausible that you have operating system packages with a great upstream security team, so you get new releases promptly... and at the same time, you use a bunch of Python Packages that are not packaged by your OS, so you need to subscribe individually to each of their changefeeds and pay attention. Does that help?
  - zepearl 6y ago
    Thank you

by dsr_ 6y ago

Quekid5 6y ago

Absolutely correct. The whole "shared libraries are better for security" idea is basically stuck in a world where we don't really have proper dependency management and everyone just depends on "version whatever". This is interestingly also holding back a lot of ABI breaking changes in C++ because people are afraid it'll break the world... which, tbf, it will in a shared library world. If dependencies are managed properly... not so much. I wish distros could just go back to managing applications rather than worrying so much about libraries. EDIT: There are advantages with deduplicating the memory for identical libraries, etc., but I don't see that as a major concern in today's world unless you're working with seriously memory-constrained systems. Even just checksumming memory pages and deduplicating that way might be good enough.

ColonelPhantom 6y ago
So if there is 'proper dependency management' (what do you propose? are we too fixed in versioning, too loose?) how will you fix the next Heartbleed? Pushing updates to every single program that uses OpenSSL is a lot more cumbersome (and likely to go wrong because there is some program somewhere that did not get updated) than simply replacing the so/dll file and fixing the issue for every program on the system. And in case your definition of proper dependency management is 'stricter', then you simply state that you depend on a vulnerable version, and fixing the issue will be far more cumbersome as it requires manual intervention as well, instead of an automated update and rebuild. If it is looser, then it will also be far more cumbersome, as you have to watch out for breakage when trying to rebuild, and you need to update your program for the new API of the library before you can even fix the issue at all.
- bjourne 6y ago
  No, it is not cumbersome to reinstall every program that relies on OpenSSL. My /usr/bin directory is only 633 MB. I can download that in less than a minute. The build is handled by my distro's build farm and it would have no problem building and distributing statically linked binaries if they ever became the norm.
  - zxzax 6y ago
    That is going back to the same issues with containers, where everything works just fine... as long as you build it from your own statically-configured repo and you rebuild the whole system every update. It's useless once you try to install any binaries from an external package source. And IMO, a world where nobody ever sends anyone else a binary is not a practical or useful one.
    - bjourne 6y ago
      Yes? Rebuilding and (retesting!) the system on every major update is not a bad idea at all. I rarely install binaries from out-of-repo sources so that is not a great problem for me. And those I do install tend to be statically linked anyway.

variaga 6y ago

>In practice this works really well as long as the change is to eliminate an unwanted side effect rather than to change a previously documented behavior ...and then you deploy and discover that somebody was depending on that "unwanted" side effect.

adrianmonk 6y ago

I strongly agree that the reporting and visibility you're talking about are important. But there's one other advantage of the shared library thing, which is that when you need to react fast (to a critical security vulnerability, for example), it is possible to do it without coordinating with N number of project/package maintainers and getting them all to rebuild. You still do want to coordinate (at least for testing purposes), but maybe in emergencies it's more important to get a fix in place ASAP.

zepearl 6y ago

> In practice this works really well as long as the change is to eliminate an unwanted side effect rather than to change a previously documented behavior. I fully agree with that, didn't understand the rest.

dsr_ 6y ago
Let's say you are building a web-based file upload/download service. You're going to write some code yourself, but most components will come from open-source projects. You pick a base operating system, a web server, a user management system, a remote storage system, a database, a monitoring system and a logging system. Everything works! Now it's a month later. What do you need in ongoing operations, assuming you want to keep providing reasonable security? You need to know when any of your dependencies makes a security-related change, and then you need to evaluate whether it affects you. You need to know which systems in your service are running which versions of that dependency. You need to be able to test the new version. You need to be able to deploy the new version. It doesn't matter what your underlying paradigm is. Microservices, unikernels, "serverless", monoliths, packages, virtual machines, containers, Kubernetes, OpenStack, blah blah blah. Whatever you've got, it needs to fulfill those functions in a way which is effective and efficient. The problem is that relatively few such systems do, and of those that do, some of them don't cooperate well with each other. It's plausible that you have operating system packages with a great upstream security team, so you get new releases promptly... and at the same time, you use a bunch of Python Packages that are not packaged by your OS, so you need to subscribe individually to each of their changefeeds and pay attention. Does that help?
- zepearl 6y ago
  Thank you