Nasty lib dependency prevents sudo execution

[Ralph Grothe]

Hello,

I have a nasty library dependency issue of a nsca client command, especially when run under sudo.
The execution via sudo is preferable because the client's config file send_nsca.cfg should only be readable by root as it contains an encryption password to authorize with the nsca server (ok, another option would be to set an acl to that file).

I guess this could be better solved than setting LD_LIBRARY_PATH (maybe relinking statically?).

This is what happens when LD_LIBRARY_PATH isn't set

$ /usr/local/nagios/libexec/send_nsca_with_mcrypt --version
/usr/lib/pa20_64/dld.sl: Unable to find library 'libmcrypt.sl.8'.
Killed

$ ll /usr/local/lib/libmcrypt.sl.8
-r-xr-xr-x 1 root sys 402351 Jan 25 11:06 /usr/local/lib/libmcrypt.sl.8

$ LD_LIBRARY_PATH=/usr/local/lib /usr/local/nagios/libexec/send_nsca_with_mcrypt --version

NSCA Client 2.4
Copyright (c) 2000-2003 Ethan Galstad (nagios@nagios.org)
Last Modified: 07-23-2003
License: GPL
Encryption Routines: AVAILABLE



I can't make this run via sudo,
even if I set these Defaults
which sudo seems to ignore altogether.

# dunno why sudo ignores this?
Defaults:someuser !env_reset, env_keep = "LD_LIBRARY_PATH=/usr/local/lib"

someuser thishost=NOPASSWD: /usr/local/nagios/libexec/send_nsca_with_mcrypt


Any ideas?

Regards
Ralph


P.S. what chatr says about the nsca client binary:

# chatr /usr/local/nagios/libexec/send_nsca_with_mcrypt
/usr/local/nagios/libexec/send_nsca_with_mcrypt:
64-bit ELF executable
shared library dynamic path search:
LD_LIBRARY_PATH enabled first
SHLIB_PATH enabled second
embedded path enabled third Not Defined
shared library list:
libmcrypt.sl.8
libnsl.1
libc.2
shared library binding:
deferred
global hash table disabled
shared library mapped private disabled
shared library segment merging disabled
shared vtable support disabled
explicit unloading disabled
linkage table protection disabled
segments:
index type address flags size
3 text 4000000000001000 ----c- D (default)
4 data 8000000000001000 ------ D (default)
static branch prediction disabled
kernel assisted branch prediction enabled
lazy swap allocation for dynamic segments disabled
nulptr dereferences trap enabled

[Ralph Grothe]

Meanwhile I found an explanation in the manpage of the sudo command.


SECURITY NOTES
sudo tries to be safe when executing external commands. Variables
that control how dynamic loading and binding is done can be used to
subvert the program that sudo runs. To combat this the LD_*, _RLD_*,
SHLIB_PATH (HP-UX only), and LIBPATH (AIX only) environment variables
are removed from the environment passed on to all commands executed.


But even though I specify env_keep as one of the Defaults in my sudoers?

[Matti_Kurkela]

As far as I've understood, you can specify variable names in the env_keep string, but not variable values.

Your defaults line would expect an environment variable _named_ "LD_LIBRARY_PATH=/usr/local/lib", which of course does not match "LD_LIBRARY_PATH".

MK

[Ralph Grothe]

Hi Matti,

your notion was my first interpretation too,
and so I first tried exactly this way with

env_keep LD_LIBRARY_PATH

But this made no difference.
sudo seemed to strip it from the environment despite.

Meanwhile I simply set an acl read access for the unprivileged user on the file send_nsca.cfg
to just make my cronjob work.
However, I don't like scattering acls because they usually upset my colleagues especially with certain backup issues (although the TSM online help claims to understand acls, but I doubt this for HP's vxfs, and I don't know about DataProtector)

Of course the best was I suppose
if I would compile a statically linked send_nsca?

[OldSchool]

How about "wrapping" the cron job in a script that sets the environment, including the LD_LIBRARY_PATH?

[Heironimus]

I think a wrapper script is really the way to go. The script can set up the environment (or sources a profile or whatever you prefer) before running the executable and you grant sudo access to run the script instead of the real binary.

It's granular - no need to allow arbitrary LD_LIBRARY_PATH settings, which is a potential risk when using sudo. It doesn't rely on ACLs or other features that are rarely used or poorly supported. It's easy for new guys to understand when they come in to your environment from elsewhere.