any chance for an explicitely runnable runtime linker?

[Carmelo AMOROSO]

On 17/09/2011 11.34, u-uclibc-y2lt at aetey.se wrote:
> Actually, I would suggest to make the use of the loader path
> optional for the standalone loader too. The less magic, the less
> security implications and possible confusion.
> 
> On Fri, Sep 16, 2011 at 11:27:23PM +0200, u-uclibc-y2lt at aetey.se wrote:
>> I have found a subtle bug in the corresponding code (besides possible
>> unexpected searches depending on the contents of argv[0] and cwd,
>> a segfault when argv[0] lacks '/'), a naive fix is as follows:
>> (otherwise ignoring argv[0] unless it is an absolute path would be more robust)
> 
> ----
> --- ldso/ldso/ldso.c.ori        2011-09-17 10:59:30.000000000 +0200
> +++ ldso/ldso/ldso.c    2011-09-17 11:01:39.000000000 +0200
> @@ -562,23 +562,25 @@
>                         if (ppnt->p_type == PT_DYNAMIC) {
>                                 dpnt = (ElfW(Dyn) *) DL_RELOC_ADDR(app_tpnt->loadaddr, ppnt->p_vaddr);
>                                 _dl_parse_dynamic_info(dpnt, app_tpnt->dynamic_info, debug_addr, app_tpnt->loadaddr);
>                         }
>                 }
>  
> +#ifdef __LDSO_SEARCH_INTERP_PATH__
>                 /* Store the path where the shared lib loader was found
>                  * for later use
>                  */
>                 _dl_ldsopath = _dl_strdup(tpnt->libname);
>                 ptmp = _dl_strrchr(_dl_ldsopath, '/');
>                 if (ptmp && ptmp != _dl_ldsopath)
>                         *ptmp = '\0'; /* leaking some string memory */
>                 else
>                         _dl_ldsopath = NULL; /* leaking the whole string memory */
>  
>                 _dl_debug_early("Lib Loader: (%x) %s\n", (unsigned) DL_LOADADDR_BASE(tpnt->loadaddr), tpnt->libname);
> +#endif
>         } else {
>  #endif
>  
>         /* At this point we are now free to examine the user application,
>          * and figure out which libraries are supposed to be called.  Until
>          * we have this list, we will not be completely ready for dynamic
> ----
> 
> Cheers,
> Rune
> 
> 

Hi Rune,
reading it again, in the security context, indeed it could be useful to
avoid loading libraries from the directory of the customized ld.so.

By default this option should be enabled, but on an hardened system, it
could be disabled... something as we have already done for LD_PRELOAD
for example.

I'll consider to write a proper patch for this.
Thanks for the hint.

Carmelo