Messages in this thread | | | From | (really ) | Date | 28 Apr 1996 14:42:24 +0400 | Subject | Re: As 2.0 looms |
| |
Marek Michalkiewicz (marekm@i17linuxb.ISts.pwr.wroc.PL) wrote:
: 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.
| |