Unable to load shared library in DISA STIG hardened Rocky Linux 9.5 Installation

Rocky Linux Help & Support
1

Hello, I hope someone can shed some light on the issue I am having. Using VirtualBox, I set up a VM using Rocky Linux 9.5 with the DISA STIG policy enabled.

I wanted a newer Python version, so I grabbed the latest tarball, and installed the developer tools as well as all recommended dependencies. Configure worked fine, but at some point after the executable and its shared library was complete, it failed when trying to run the interpreter itself as an integrity test.

Since I saw the binary and shared library, I tried to execute it with
LD_LIBRARY_PATH=. ./python
and was surprised that it was unable to find libpython3.13.so.1.0 which was right there.

Since I wanted to get the build complete, I then fired up another VM without the STIG enabled, and built the binaries and shared libraries, then transferred them to the STIGged machine.

Again, something in the system makes the attempt to load the shared library to fail with a “No such file” error when executing python.

Is there a remedy which allows me to keep the STIG hardening yet allow me to run the binary. When installing, I did properly create the file in /etc/ld.so.conf.d and ldconfig, and ldd properly showed the dependent lib, but the executable does not run.

(edited)
The error message given differs between root and a normal user. Note that I have installed in /opt/python313, and have added to my path, and updated the library resolution with ldconfig.

Error as root: error while loading shared libraries: libpython3.13.so.1.0: cannot open shared object file: No such file or directory
(Error as user: bash: /opt/python313/bin/python3.13: Operation not permitted
(end edit)

Thank you very much in advance,
Ben.

2

This is just for anyone who wanted the solution. Apparently, the hardening also enabled fapolicyd, preventing untrusted executables and shared libraries from being loaded. The brute-force would be to disable/uninstall fapolicyd, and the correct solution would be to add a rule to make an exception for the installation directory. Another alternative would be to add the contents of the entire directory to the trusted file database. For further reference, see the man page for fapolicyd-cli.

1 Like
3

(Tapped on something and deleted my post with no way to undo it. Reposting)

This is just for anyone who wanted the solution. Apparently, the hardening also enabled fapolicyd, preventing untrusted executables and shared libraries from being loaded. The brute-force would be to disable/uninstall fapolicyd, and the correct solution would be to add a rule to make an exception for the installation directory. Another alternative would be to add the contents of the entire directory to the trusted file database. For further reference, see the man page for fapolicyd-cli.

1 Like