[pulseaudio-discuss] AppArmor profile for PulseAudio
Mikhail Morfikov
mmorfikov at gmail.com
Thu Sep 14 10:33:28 UTC 2017
Hello,
I wrote an experimental AppArmor profile for PulseAudio. I also have some
profiles for bunch of other apps [1], and the question I want to ask isn't
really connected to those profiles, but rather it concerns interactions between
some processes and PulseAudio.
For instance, I use SMPlayer to watch movies. I also have AppArmor profile for
this app, and it's loaded in enforce mode. I've been using this app for some
time without any "denied" messages in the system log. After adding the
PulseAudio profile to AppArmor (in complain mode so far), I noticed that
AppArmor reports the following logs:
kernel: audit: type=1400 audit(1505370398.880:1005): apparmor="DENIED"
operation="capable" profile="/usr/bin/smplayer" pid=40033 comm="pacmd"
capability=19 capname="sys_ptrace"
kernel: audit: type=1400 audit(1505370398.880:1006): apparmor="DENIED"
operation="ptrace" profile="/usr/bin/smplayer" pid=40033 comm="pacmd"
peer="/usr/bin/pulseaudio"
As you can see, these messages concerns the SMPlayer profile and not the
PulseAudio profile. This can be solved by adding the following rules to the
SMPlayer profile:
capability sys_ptrace,
ptrace (trace) peer=/usr/bin/pulseaudio,
Why does SMPlayer need the rules now? I have its profile for a while, and
SMPlayer never asked for the rules. I know that it's because of creating the
profile for PulseAudio, but can anyone explain why?
What do the rules actually mean? What would happen when I didn't add them?
SMPlayer seems to work just fine without the CAP and ptrace rule.
Can anyone cast some light on this?
[1] https://github.com/morfikov/files/tree/master/configs/etc/apparmor.d/
More information about the pulseaudio-discuss
mailing list