Re: [RFC][PATCH v1 0/5] Proof-of-Concept implementation of RTLD_SHARED for dlmopen

[Carlos O'Donell <carlos at redhat dot com>]

On 05/18/2018 03:53 PM, Vivek Das Mohapatra wrote:
>> Now we have a few good win/win scenarios:
>>
>> * You can now force objects into a dlmopen namespace even if you link
>>  directly with them by setting DT_LMNS to a value other than $.*
>>  You would have to look these objects up to use them via a namespaced
>>  dl_iterate_phtr?
>>
>> * You can add new objects to $PROXY if you want them to be exposed
>>  through all of the namespaces too.
>>
>> Thoughts?
> 
>  - namespaced dl_iterate_phdr would make my life easier, so thumbs up.
> 
>  - need to refresh my memory regarding dl_map_object - I think we'd need
>    to harvest this info in _dl_map_object_from_fd and set a flag in
>    the struct for easy checking later (or maybe keep a list of
>    must-proxy objects, sort of analogous to how RTLD_GLOBAL objects
>    are tracked, I guess).
> 
> Which reminds me - the code currently has a comment in it that says
> RTLD_GLOBAL is nonsensical for namespaces but this isn't exactly true:
> I think it makes sense for RTLD_GLOBAL to mean "use this for everything
> in the target namesapace" (Mesa libGL for example RTLD_GLOBAL dlopens
> _itself_ to export symbols to modules it is about to open, which I have
> to trap when isolating libGL).

I agree 100%.

The use of RTLD_GLOBAL is *absolutely* critical and it must be interpreted
to mean "GLOBAL within the namespace" as you imply.

There may be objects which use RTLD_GLOBAL which you cannot change but must
be able to load safely in a namespace.

> In effect, the $PROXY DT_LMNS DSOs become super-global (Solar?)
> and RTLD_GLOBAL is extended to mean "for this namespace".

Right. I think it's a bad design to allow objects to break out of the namespace
in a dynamic way, so I do not think we need RTLD_SUPER_GLOBAL which means to
add symbols to the base namespace.

However, I think that a compile-time, verifiable, DT_LMNS tag in .dynamic, can
be audited and verified from a security perspective to know that it will be
proxied to all namespaces.

Lastly we need test cases for things like using RTLD_GLOBAL within a namespace,
and using RTLD_SHARED, and nested dlopen within dlmopen, etc. etc. So you have
your work cutout, but I can probably help write some more test cases :-)

-- 
Cheers,
Carlos.