Re: Fwd: [PATCH v5 00/22] Some rtld-audit fixes

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 22/11/2021 14:46, jma14 wrote:
> 
> On 11/19/21 14:31, Florian Weimer       wrote:
> 
>> * Adhemerval Zanella:
>>>> "" for the main executable is widely known.  Usually code uses it to
>>>> implement a fallback on argv[0] or /proc/self/exe, though.
> 
> If this is widely known, it would be helpful if this was added to the man pages. Currently the man pages define l_name as the "absolute pathname where object was found." That sounds (to me at least) like dlinfo(dlopen(NULL)) is a portable alternative to the Linux-specific AT_EXECFN, contrary to reality.

To provide an absolute pathname it would require to use realpath() or similar
strategy either before issuing la_objopen() or while parsing the arguments
or reading AT_EXECFN.  I am not sure if this best approach, specially if the
executable is executed through a namespace or any kernel abstraction where
obtaining the full path though filesystem walk is not possible or restricted.

> 
>>> There are still the issue where audit interface does not have direct
>>> access to argv[0] from the audited process and '/proc' might also not
>>> be accessible.  I am still not convinced that provided argv[0] for
>>> l_name for main executable is worse than "", specially because the
>>> fallback might not work.
>>
>> I think it's better to give the auditor a chance to figure out whether
>> they want to use program_invocation_name (if that's not available in the
>> inner libc, that's for sure a bug we must fix), AT_EXECFN, or
>> /proc/self/exe.  If we pick one of these for the auditor, we make it
>> more difficult to make the appropriate choice.
> 
> Apologies, but I don't understand the logic here. The main executable is easy to identify in la_objopen as `l_prev == NULL && lmid == LM_ID_BASE`, the same (effectively) is done in gdb [1]. Applications have dlinfo(dlopen(NULL)) to directly obtain the main executable's link_map. I fail to see how setting l_name to "" is superior to either of those options, especially given the downsides.
> 
> I agree with Adhemerval. There is no portable way for an auditor to acquire the resolved path to the main executable, AT_EXECFN and /proc are Linux-specific and dladdr (currently) often crashes from the auditor. An l_name of "" means auditors *cannot* make the appropriate choice.

In fact I think rather than using the argv[0], since it passing the executable
path is just a convention; I think it would be better to use AT_EXECFN.  On
recent kernel it is always passed to userland and kernel should be responsible
to hide any filesystem information if it is required.

And it also helps for the case where execve() is called with bogus initial
argument.

> 
> [1] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/solib-svr4.c;hb=d3de0860104b8bb8d496527fbb042c3b4c5c82dc#l1230