I have been assigned the task of adopting and implementing a certain backup software solution for our GNU/Linux farm.
As per my deparment defined requirements, this solution should support SELinux enabled systems to be valid. After a not too thorough research, it was quite obvious that this product did not support SELinux, or needed the system administrator to punch a hole in the SELinux policy because some libraries needed to perform text relocations to be able to operate (not to mention the correctness -or lack thereof- of the commands suggested in their knowledge base).

It is not new that SELinux is proven to expose bugs, but my concern here was to be able to explain to Management to what extent denying text relocations is a major security feature.

Management counteract my reasoning claiming no CVEs are published for this specific product related to its need to perform text relocations.

Is the need to perform text relocations exploitable enough as to represent a CVE elegible vulnerability?

2 Answers 2


There are two major points to make. The first is that a major strength of SELinux policy is to prevent exploitation of unknown vulnerabilities. Given that they are unknown, a CVE will not exist.

The second is that permitting text relocation also permits an exploit to write and execute whatever code it would like to execute, or allows it to modify existing code in memory. You reference Ulrich's short blurb which also contains his "fixing the problem" article; both of which are excellent and explain the problem.

The "need to perform text relocations" is not itself a vulnerability; it just makes some vulnerabilities in the program or libraries easy to exploit.

  • I agree with your first point, that was what I meant when explaining that what the vendor requested was invalidating the protection offered by SELinux. As per the second, I think I understand what Ulrich Drepper's article explains, but being this a closed-source proprietary product, that is not an option. With you last statement, do you mean that text relocations can be, in fact, an attack vector, and therefore, software requiring such operations should not be trusted? It is a backup system, and as such, it has access to the whole contents of my OSes. Thanks for the feedback.
    – dawud
    Apr 18, 2013 at 21:15
  • Relocation is not itself an attack vector; it makes the software less trustworthy because it is easier to exploit. You can reduce the attack surface with policy and other mechanisms to isolate the software and its resources. You want to limit its exposure to untrusted users and processes. Given how well you believe you can minimize the attack vectors, you can make a decision of whether or not to use it. The text relocation issue is not at all desirable but, if you can isolate the application, you may be able to trust that the risk of exploitation is small enough for your situation.
    – user24941
    Apr 19, 2013 at 0:59
  • I have decided to use other software, because I don't think I can't isolate this problem enough, not provide a solution via SELinux policy that doesn't require allowing TR. However, I'd like to note that I have made no claims whatsoever in the sense of "how well I believe I can minimize the attack vectors" neither in the question, nor in the comments. Thanks.
    – dawud
    Apr 19, 2013 at 6:16

The nonexistence of a CVE is a horrible justification for not implementing a security measure. The whole point of this game to stay ahead of your attackers, and if the hypothetical attackers are only using widely-disseminated and public vulns they really aren't very good at what they do.

Text relocations are "bad" because they are a special case of self-mutating code, which means that potentially an attacker could induce the program to modify its text in some other way. If the relocations are required, it means that the program .text (code) can be written to.

Without an actual vulnerability that allows an attacker to manipulate the text relocation process or write directly to .text, this is a total non-issue. This would basically require them to be able to add loadable modules, if that's why the relocation is required, or otherwise modify arbitrary files on the system under attack; in either case you have much bigger problems. The case of being able to write arbitrary stuff into .text as an attacker is a fairly big security bug in its own right.

Essentially when you allow this you forgo the benefit of W^X protection. That's the big issue.

Of course, you don't know that there isn't a vulnerability that would allow an attacker to do these things. You'd be more secure if you were able to not grant this permission to the application, but if the functionality requires it honestly you should just allow it while shouting loudly at the software vendor.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .