On 2020-06-23 12:21, Ian Jackson wrote:
> Aurelien Jarno writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks 
> with plain filename"):
> > On 2020-06-23 11:46, Ian Jackson wrote:
> > > Should apparmor make a difference between absolute paths and leafnames
> > > in LD_PRELOAD ?  Because I can reproduce that with eatmydata:
> > >   $ eatmydata env -u LD_LIBRARY_PATH 
> > > LD_PRELOAD='/usr/lib/x86_64-linux-gnu/libeatmydata.so' man ls >/dev/null
> > >   $
> > > 
> > > strace in the run with the error message[1] shows it does successfully
> > > open the intended .so file.  But then it goes on to try lots of other
> > > places instead and eventually prints that error message.  It seems
> > > that it opened the file but rejected it.
> > 
> > It's because running man involves running many binaries, and not all of
> > them are run under apparmor.
> I don't think that can be the whole explanation.
> The strace rune I used gives a different output file for each
> process.  The process which prints the error message is the same one
> which previously successfully opens the file - see my strace output,
> which is just from man's run of preconv.

Yes, this indeed matches the glibc code. In practice they are cases were
preloading is still accepted for secure-execution, if the shared library
is suid. Here is the excerpt from the manpage:

  In secure-execution mode, preload pathnames containing slashes are
  ignored.  Furthermore, shared objects are preloaded only from the
  standard search directories and only if they have set-user-ID mode bit
  enabled (which is not typical).

So the file is opened, and fxstat is used with the resulting fd to fetch
its mode. I guess this is done that way to avoid any race condition, to
make sure that the shared library being read is the same that the one
being tested with fxstat.

> > > I notice that during startup it does this
> > >   access("/etc/suid-debug", F_OK)         = -1 ENOENT (No such file or
> > > but none of my man-db binaries are setuid (I have double-checked).
> > 
> > This is exactly my point. This happens because the binary is considered
> > like a suid binary, ie the kernel sets AT_SECURE for binaries running
> > with apparmor.
> Thanks, yes, that does seem to be the case.
> I searched my strace outputs again and the processes that print the
> error message are precisely the same processes that call access on
> /etc/suid-debug.  And I did find /etc/apparmor.d/usr.bin.man which
> does talk about preconv (for example).
> However ...
> > From the glibc point of view, this disables, among other
> > things, support for preloading. The glibc doesn't actually know the
> > reason why AT_SECURE is enabled, historically it meant suid binaries
> > (hence the suid-debug name), but nowadays, it's also used by selinux and
> > apparmor.
> I think more must be going on.
> If it were merely that support for preloading was disabled, why does
> it even try to search for the library ?
> Why does providing an absolute path make it quiet ?  (I haven't been
> able to find an easy way to see whether the LD_PRELOAD is being
> honoured.)

Again this matches the glibc code. As said in the documentation, in
secure-mode paths that contain slashes are simply discarded. In short
the libeatmydata.so is not used, something that you can confirm using

> Why does my ambient LD_PRELOAD of libgtk3-nocsd.so.0 (which applies to
> all programs in my session) not produce the same error message ?

Because libgtk3-nocsd.so.0 from the debian package is shipped with suid


Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurel...@aurel32.net                 http://www.aurel32.net

Reply via email to