On Tue, Jun 23, 2020 at 11:46:58AM +0100, Ian Jackson wrote:
> Aurelien Jarno writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks 
> with plain filename"):
> > You probably have apparmor installed and enabled on your system.
> > Binaries that are run with an apparmor profile get AT_SECURE enabled,
> > which disables many features that have an impact on security, including
> > preloading libraries.
[...]
> 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).

The name is a slight misnomer, presumably because it predates other
reasons why ld.so might be in secure-execution mode.

> I also notice that something in the invocation stack (presumably
> something in man-db) is changing the LD_PRELOAD value from
>   LD_PRELOAD=libgtk3-nocsd.so.0 libeatmydata.so
> to
>   LD_PRELOAD=libgtk3-nocsd.so.0:libeatmydata.so
> and I didn't even know spaces were allowed!  But this doesn't seem
> relevant.

man-db never sets LD_PRELOAD.

> If this were apparmor I would expect to see an EACCES or EPERM or
> something.

I believe Aurelien's contention is not that AppArmor is denying the
request as such (which would indeed produce some kind of errno along
these lines), but rather that the fact that there's an AppArmor policy
defined for /usr/bin/man puts ld.so into secure-execution mode when
executing that binary.

> > > Colin Watson (CC'd) reports that sid works.
> > 
> > I have tested on sid and on experimental, I do not find a different
> > behaviour.

Apologies for the misdirection here: I was only testing in a sid chroot,
and hadn't considered the possible AppArmor issue.

In general, I don't regret my decision to add various confinement
tactics to man as a defence against possible vulnerabilities in the
rendering pipeline for manual pages.  However, it is clearly
inconvenient in the sort of case that Ian brings up.  I wonder if I need
to provide a separate utility for linting manual pages that doesn't
involve secure-execution mode in any way, in order that it can be used
by build systems without needing to worry about all this stuff.

-- 
Colin Watson (he/him)                              [cjwat...@debian.org]

Reply via email to