: I believe core dumping is OK (the dumpable flag is cleared if the program
: is unreadable). I know of at least one program (deslogin) which has
: encryption key compiled in (the binary is mode 711). I shouldn't have
: to link it statically to be safe... Another solution, which doesn't
: need kernel support, would be to have two versions of ld.so: one which
: ignores LD_xxx and one which is like the current ld.so. You decide
: which one you want to use at link time (default is to ignore LD_xxx -
: it's not necessary except for testing new shared libraries). I think
: HP-UX does something like this. If we had this, we wouldn't have the
: infamous telnet environment security hole...
Remember, that LD_LIBRARY_PATH is not only environment variable,
that affect setuid programs. There are a lot of obscure
(sometimes even not documented) variables:
f.e. terrible Linux libc's RESOLV_*
So that, setuid programs must purge all the environment variables,
that they do not understand. (though, it is useless for LD_*)
HP-UX (and, seems, CRAY) proposed more nice solution for telnet problem:
All the environment variables passed to login via command line options.
I did the same thing, and I sleep quietly now 8).
Moreover, my login purges all the environment
at the very start of main and complains if it was started by root
with not-empty environment.
Alexey Kuznetsov.