Library validation failed: problems with dynamic library

Question

Created Mar ’21

Replies 4

Boosts 0

Views 2.2k

Participants 3

I have a setup (working in 10.1[345]) which now fails in Big Sur, where I have a dynamic library (which calls another external library which in turn calls another) which is referenced from PAM.

More specifically, this is a setup to allow PIV smartcards to be used for "sudo" authentication. Thus, I have a line in /etc/pam.d/sudo which calls /usr/local/libexec/pam_ssh_agent_auth.so. This library calls a perl script which does a network LDAP lookup for the current user.

I have code-signed the pam_ssh_agent_auth library as well as the non-system library it references (as seen by "otool -L") and the non-system library that the intermediate one calls. These are all located in /usr/local/libexec as well.

When I run a sudo command now, e.g., "sudo date", the command simply hangs. The error I see in Console is:

Library Validation failed: Rejecting '/usr/local/libexec/pam_ssh_agent_auth.so' (Team ID: 82A95CK2HC, platform: no) for process 'sudo(16107)' (Team ID: none, platform: yes),
reason: mapping process is a platform binary, but mapped file is not.

I have found other references to this error but those seem to involve application bundles. In my case I have a single .so library (plus the two others) I wish to invoke.

The library is from
https://github.com/jbeverly/pam_ssh_agent_auth/releases

Again, this works fine in the three previous OS versions.
What do I need to change to make it work here? Advice most appreciated, please. Thank you!

Boost

Answer 1

DTS Engineer OP

Apple

Mar ’21

It seems that sudo is trying to directly load your pam_ssh_agent_auth.so. Normally I wouldn’t expect that to work because of library validation. Specifically, platform binaries (that is, things included in the base system, which in this case means sudo) can’t load third-party code without taking special measures.

However, in this case it seems that sudo has taken such special measures. Consider this:

Code Block  % codesign -d --entitlements :- sudo
…
<dict>
    …
    <key>com.apple.private.security.clear-library-validation</key>
    <true/>
</dict>
</plist>

The com.apple.private.security.clear-library-validation should allow sudo to load third-party code. And this works in other contents, like /System/Library/Frameworks/Security.framework/Versions/A/MachServices/SecurityAgent.bundle/Contents/XPCServices/SecurityAgentHelper-x86_64.xpc.

So, in summary, I’m not sure what’s going on here. I’m going to recommend that you open a DTS tech support incident so that I can allocate more time to investigate this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

DTS Engineer OP

Apple

Mar ’21

I just want to close the loop on this one. Earlier I wrote:

The com.apple.private.security.clear-library-validation should allow
sudo to load third-party code.

That is, indeed, true. dpfriedlander and I were both confused by the Library Validation failed log entry. It turns out this has a simple explanation:

PAM, running inside sudo, tries to load the module.
That fails, generating this log entry.
PAM responds by disabling library validation (not something you can normally do but enabled because sudo is signed with the com.apple.private.security.clear-library-validation entitlement).
PAM then retries opening the module.
That works.

Once I understood that the log entry was a red herring, it was easy to work out the root cause of my problem (a mistake in my testing methodology that made me think that my PAM module was failing to load when, in reality, it loaded just fine).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 3

jdough OP

Mar ’23

[deleted and changed to comment]

0

Answer 4

jdough OP

Mar ’23

@dpfriedlander Hey, I'm trying to compile https://github.com/jbeverly/pam_ssh_agent_auth/ on macOS 13.2.1 (Ventura, ARM) but I get errors with './configure'. Maybe ARM isn't supported yet. Did you try it?

0