Shared library randomization Add support for shared library loading order randomization. Base work was done in HardenedBSD https://github.com/HardenedBSD/hardenedBSD/commit/6fc06960ae5d374278dddc301aede21a7919b600 https://github.com/HardenedBSD/hardenedBSD/commit/6fc06960ae5d374278dddc301aede21a7919b600 This implementation takes care about libraries ordering. Sometimes, libs must be loaded in exact order, because one might shadow symbols from another (for example libregexp shadows regex- functions from libc). If this order changes, the application will most likely not work. Here, prior randomization, needed libraries are analyzed for symbol shadowing. If such situation is detected, these libraries are marked as "critical" and a loading order between them won't change. As a shuffle algorithm, Fisher-Yates shuffle is used to acheive equal distribution. https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle By default the option is disabled. To enable, one must ude WITH_SHLIBRANDOM flag in src.conf
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
How do you propose to fix the issue mentioned in the commit message in https://github.com/HardenedBSD/hardenedBSD/commit/1b291848bfbb8fe12b893d12c5163f74b84257aa?
Comment Actions
That's a very good point, unfortunately I don't have a clear answer.
I'm aware of the problem with grep and this patch definitely not resolves it.
Moreover, it's not only a grep issue. In all /lib and /usr/lib there are about 30k+ symbols with the same name in different so's. Most of them are just duplicates of various version of the same lib (like ncurses* stuff and similar), but some libraries are re-implementing procedures from libc which is a case with grep/libregex.
The idea here is to provide a randomization for secured embedded environments where we can and want to precisely control which applications are running. It's definitely not for typical user who values to have unix-like experience.
There are products which are running just fine with this randomization and that's why I think it's worth to integrate it and leave it as an option.
For future improvements, I consider one of following:
- Have a list of application/libraries for which there shall not be any randomization at all
- Analyze symbols during pre-load phase and provide "before/after" dependencies
- Always keep libc, libssl* etc. at the end of the list
#1 will increase executalbe startup time
#2 and #3 might impact uniformity of probabilistic distribution with F-Y shuffle