You need read access to actually use them. Even if some file system trickery would be made to prevent it so that you couldn't fopen it, the actual binary code will be in memory accessible for your app, because it has to be there in order to run.
That would only work for the .text section. Other sections like .data, .rodata, and .bss need read access because they contain data required for the library to function (global variables, vtables, constants, etc.).
I'm not sure if Android allows for multiple mappings of the same page, but I could see something where global variables that are internal to the library are accessible only through a mapping that is known only to the binary itself (possibly by hardcoding it into instructions inside .text?) API needs to be exposed, of course, but ideally that would be the same across different implementations of a library.
What problem are you actually trying to solve though? System libraries are not secrets, there really isn't any good reason we should go through these hoops to prevent reading them.
...system libraries contain identifying information? Is this some alternate usage of the word "system library" I wasn't previously aware of? I'm assuming, and haven't read anything to the contrary, that these are just dynamically linked code libraries what have been a pretty big part of how OSs work for decades.
Therefore, I can only conclude that the identifying information is which precises system libraries are installed on any given machine. Any solution to this problem other than "have fewer system libraries and don't change them as often" is adding far more complexity to computing than it will ever be worth, and computing already has enough of such "for the security gods!" solutions.
> I'm assuming, and haven't read anything to the contrary, that these are just dynamically linked code libraries what have been a pretty big part of how OSs work for decades.
Yes, we're talking about the same thing.
> Therefore, I can only conclude that the identifying information is which precises system libraries are installed on any given machine.
Specifically, it provides very detailed information about your hardware revision, OS version, security patch level, which is generally something that forms part of most fingerprinting suites. Now, I'm not saying that we can solve this problem easily–but I do think it's important to recognize the privacy implications that uploading them can entail.
Ok, so let's say you've solved this problem tomorrow. You've just made it impossible for an application to know which OS version, security patch level, and hardware revision it is running on, meaning it can't do anything like dynamically adjust itself depending on features (or bugs) it will know are available or not. It also can't submit any of this in crash reports, so fixing bugs that occur in rare combinations of hardware and software is now much more problematic.
All to prevent... what? If you log into Facebook, which is presumably why you have the application, then it already knows who you are. Not to mention the hundreds of other ways to fingerprint you.
There are situations where different people use the same machine to access Facebook. And indeed, where they also (foolishly, I know) expect that Facebook will preserve mutual privacy. Partners. Parents and children. Siblings.
So Facebook, if it's relying on hardware/software fingerprinting, might compromise multiple users to each other.
Whereas the execute flag on a page allows one to only load data from there but not jump there is nothing that allows one to execute code while preventing mov.
