any chance for an explicitely runnable runtime linker?

[Carmelo AMOROSO]

On 13/10/2011 15.29, Carmelo AMOROSO wrote:
> 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
> 

Applied.


> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
>