From: kankkune@klaava.Helsinki.FI (Risto Kankkunen) Subject: Security hole? (was: GCC FAQ. Please read before posting...) Date: 8 Aug 1993 23:25:48 +0300
> Linux's LD_LIBRARY_PATH is very security concious, and do NOT expect
> to work the way SunOS do it or the way you'd like it to.
> If on the other hand you are a normal user, (uid != 0), and the
> binary to be executed is a suid executable, then the libc.so.x is
> force loaded from somewhere in the trusted search path, and the
> remaining required libraries are searched in LD_LIBRARY_PATH. This
> stops a normal user from emulating his own, for example, setuid()
> calls from a libc library (s)he created.
Whoa there! This is security conscious? What if I have a setuid root X
program (like xterm), and I make a modified libX11 and point
LD_LIBRAY_PATH to it? Do I understand it correctly that under linux I
get immediate root access? Under (the not security conscious?) SunOS
this isn't possible...
I don't like to see libc having special handling. The C library is just
another shared library and any shared library can be a security hole
with setuid programs.
One solution would be to load all shared libs of a setuid program from
the trusted directories. Another alternative would be to use the normal
search algorithm, but check the permissions and ownership of the library
before loading it. If they match the executable (i.e. is root or the
same as the setuid or setgid), then use it, otherwise reject.
> For Linux, as a runtime linking time comsideration, if a binary
> requires multiple libraries to link to and one, (yes just one - and
> it could be the first), of the libraries is NOT found in the users
> LD_LIBRARY_PATH then the *whole* search process in the
> LD_LIBRARY_PATH is aborted and switched to the trusted search path.
What does this buy? For things to work, everyone using LD_LIBRARY_PATH
has to insert the trusted paths to the environment variable. You have to
be careful in this and check out, what the trusted paths happen to be in
your particular host and the current compiler and library version.
Otherwise you might have missed one default path and your search path
gets silently ingnored and you wonder wgy things don't work. And all
this just to save some time staring up a program when some poor soul has
hosed up his LD_LIBRARY_PATH?
For things to be consistent I suggest that either the trusted paths are
always used after LD_LIBRARY_PATH, or trusted paths are not used at all,
if the environment variable is set. The second option lets you override
the system libraries totally, if you want. It also lets you mess things
up badly, and in normal operation requires you to insert the trusted
paths to LD_LIBRARY_PATH anyway, so I think the first option is better,
overall. That is, LD_LIBRARY_PATH should tell the directories tried
before the trusted paths when searching for a shared library.
--
Other people like awk too, although in these days of kitchen sink
languages with chainsaw syntax and dishwasher semantics [see perl],
it sure looks light-weight. --Ozan S. Yigit