Problem: An attacker could alter how an applications interacts with shared libraries Fix By: Link with -Wl,-z,relro,-z,now Waive If: The application runs in an space/time constrained environment Example: FAIL: gnu relro test because not linked with -Wl,-z,relro
Some parts of an executable need to be modified when it starts, so that it can access any shared libraries that it uses. This process is called relocation, and once it is finished the altered code/data should not be modified again. The gnu relro test checks that write permission can be removed once the relocations have finished.
Enabling gnu relro increases the executable size on disk and in memory, and depending upon the application it can also cause a slow start time. It does not cause any significant execution time penalty, and using pre-linking can eliminate the startup penalty.
For programs that do not need to be reloaded often, such as daemons and servers, and on systems where disk and memory are relatively abundant such as desktops and servers, the overhead of gnu relro is very insignificant and highly recommended. For programs that need to be reloaded often, the execution penalty of gnu relro can be eliminated by using prelinking. For embedded systems where space is scarce, gnu relro is not recommended due to its space overhead.
To turn on gnu relro compile with the gcc -Wl,-z,relro,-z,now option.
Note - this test is related to the See The writable-got test test. This test checks that the GOT and PLT tables are made read-only once the relocations have been processed. The writable got test checks that the relocations that are used to initialise the GOT and PLT tables cannot be changed.
If necessary the test can be disabled via the --skip-gnu-relro option and re-enabled via the --test-gnu-relro option.