From: torvalds@klaava.Helsinki.FI (Linus Torvalds) Subject: Re: Security hole? (was: GCC FAQ. Please read before posting...) Date: 9 Aug 1993 00:23:32 +0300
In article <243ngc$t76@klaava.helsinki.fi> kankkune@klaava.Helsinki.FI (Risto Kankkunen) writes:
>
>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...
No. The startup code checks if the binary was loaded suid (or sgid),
and clears the LD_LIBRARY_PATH environment variable if so. Note the
*clears*: not only doesn't LD_LIBRARY_PATH get used for suid programs,
but no programs that get executed by the suid programs will get the
LD_LIBRARY_PATH variable by mistake.
>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.
libc doesn't get any special handling (unless something changed in the
startup code that I'm not aware of). The LD_LIBRARY_PATH handling
concerns everything.
>> 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?
It could be considered a misfeature, but is in fact not a big problem:
the LD_LIBRARY_PATH should always contain the trusted path (ie
"/usr/lib:/lib:/") at the end, so that the above simply isn't a problem
(in that case, if it's not found in LD_LIBRARY_PATH, it's not found at
all, so we'd have to abort the binary anyway).
Linus