On 12/21/15, Mickaël Salaün <m...@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.