Bug#605090:

[Jacob Appelbaum <jacob@appelbaum.net>]

On 12/21/15, Mickaël Salaün <mic@digikod.net> wrote:
> On 21/12/2015 00:14, Jacob Appelbaum wrote:
>> I was left with:
>>
>> [ 1802.373906] grsec: denied untrusted exec (due to not being in
>> trusted group and file in non-root-owned directory) of
>> /run/user/1000/orcexec.bCtW1V by
>> /usr/bin/pulseaudio[alsa-source-ALC:3038] uid/euid:1000/1000
>> gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
>> uid/euid:0/0 gid/egid:0/0
>> [ 1802.373967] grsec: denied untrusted exec (due to not being in
>> trusted group and file in non-root-owned directory) of
>> /home/error/orcexec.SzaIXb by
>> /usr/bin/pulseaudio[alsa-source-ALC:3038] uid/euid:1000/1000
>> gid/egid:1000/1000, parent /lib/systemd/systemd[systemd:1]
>> uid/euid:0/0 gid/egid:0/0
>> [ 1802.374015] grsec: denied untrusted exec (due to not being in
>> trusted group and file in world-writable directory) of
>> /tmp/orcexec.5bPuTr by /usr/bin/pulseaudio[alsa-source-ALC:3038]
>> uid/euid:1000/1000 gid/egid:1000/1000, parent
>> /lib/systemd/systemd[systemd:1] uid/euid:0/0 gid/egid:0/0
>>
>> I have no idea why pulse audio is trying to exec anything but audio
>> works fine regardless - so I'm just going to ignore it.
>
> grsecurity enforce a healthy execution environment not respected by liborc.
> Pulseaudio creates executable files in /tmp, writable by everyone (with the
> sticky-bit exception), which are then forbidden from being executed.
>

Oh - I'm well aware that grsecurity is doing the correct thing! I'm
rather asking, why does pulse audio do this crazy thing? :-(

> You can set $TMPDIR to a private directory (e.g. /home/<user>/tmp) and this
> should do the trick. However, the better solution is to create a private FS
> namespace for your user (e.g. using pam_namespace) to polyinstanciate a
> private /tmp for every user.

I think grsecurity will still stop it as the trusted path execution
should stop it.