0

I have an application that needs to run with the CAP_NET_BIND_SERVICE capability so that it can open a low port (502 for a TCP/Modbus server). It comes bundled with a set of .so files that it needs to dynamically link against, including pinned versions of system libraries (libxml.so and libz.so). Generally, I would set LD_LIBRARY_PATH, but when the executable has a capability, environment variables are ignored (see "Secure-Execution Mode" in ld.so(8)).

I have tried the following things:

  • Adding the search paths to the /etc/ld.so.conf.d directory breaks anything that relies on the system libraries that are now shadowed by the vendored libraries
  • Setting up a firewall rule to redirect port 502 to a high port, changing the configured listen port, and disabling the capability is not allowed under our security policy*
  • Our license with the vendor does not allow us to modify their compiled executables, so chrpath is not an option
  • Running as root is not recommended for security reasons, and would generate root-owned log files (that we would prefer to avoid)

OS is RHEL 7, running as a systemd service with a custom unit file.

Is there a way to add a library search path for just this specific application?

*which I'm not empowered to change or make an exception to

user583054
  • 1
  • That 'security' policy is insane. But you probably knew that already. As for the app, it binds to a low port. Doesn't it already start as root and drop privileges like most other such apps? Is it also insane?! What does the vendor suggest doing? – Michael Hampton Jul 14 '20 at 14:29
  • The vendor usually sells a fully-integrated Linux appliance that they lock down, and they use the firewall-redirection method. However, our 'security' team required that we provide the hardware and base OS image (also because it's pre-configured for remote access, which is a good reason). Nobody is happy with this, least of all the vendor. – user583054 Jul 14 '20 at 14:33
  • Sounds like your 'security' team is also insane. I am not sure anyone can help you at this point. Maybe you ought to start pushing back on some of the more absurd things they are doing. – Michael Hampton Jul 14 '20 at 14:37
  • Or find a new job. My suspicion is that they'll just live with the overall system breakage that comes from adding the search paths, or work something out with the vendor to change their build system and embed those paths. Thanks for the help, though! – user583054 Jul 14 '20 at 14:42
  • what about using a mount namespace to override the ld.so.conf *just* for this app? – A.B Jul 15 '20 at 20:24
  • That's an interesting idea. Could you point me at some documentation on that? – user583054 Aug 14 '20 at 17:16
  • https://www.freedesktop.org/software/systemd/man/systemd.exec.html . You can search for the several "mount namespace", "file system namespacing", "file system namespace", but especially the option `BindPaths=` "Any bind mounts created with this option are specific to the unit, and are not visible in the host's mount table." – A.B Aug 14 '20 at 17:48

0 Answers0