[apparmor] PulseAudio profile: sys_ptrace, ptrace, 'rwcdmr' denied masks and example rules.

daniel curtis sidetripping at gmail.com
Wed Aug 10 17:54:11 UTC 2016


Hello.

I would like to use an AppArmor profile for a PulseAudio - a networked
low-latency sound server. After many experiments, tests etc., everything
seems to work, but there are some aspects and issues, which make me
curious.

After creating an /etc/apparmor.d/usr.bin.pulseaudio file, then
subsequently, I made this profile "enforced" via 'aa-enforce'. Next, I
executed 'pulseaudio' command - in console - with such result (just for
testing purposes etc.):

[~]$ pulseaudio
E: [pulseaudio] pid.c: Daemon already running.
E: [pulseaudio] main.c: pa_pid_file_create() failed.

And for example /var/log/syslog file contained such entries (NOTE: I
omitted date, hostname):

type=1400 audit(1470725743.218:86): apparmor="DENIED" operation="capable"
parent=2314 profile="/usr/bin/pulseaudio" pid=3009 comm="pulseaudio"
capability=19  capname="sys_ptrace"

type=1400 audit(1470725743.218:87): apparmor="DENIED" operation="ptrace"
parent=2314 profile="/usr/bin/pulseaudio" pid=3009 comm="pulseaudio"
target=B00280F4B00280F4F7

So, should I use a rule for "sys_ptrace" and "ptrace" (in PulseAudio
profile)? Anyway, in a 'complain' mode log files contains something like
this:

type=1400 audit(1470726298.790:97): apparmor="ALLOWED" operation="mknod"
parent=1 profile="/usr/bin/pulseaudio" name="/home/t4/orcexec.aILTFz"
pid=3246 comm="alsa-sink" requested_mask="c" denied_mask="c" fsuid=1000
ouid=1000

This is a sample entry, because there was a couple of similar - related to
the /home/t4/orcexec.* file (NOTE: in the user home directory, there was no
such file!) Some of them:

comm="alsa-sink" requested_mask="rwc" denied_mask="rwc"
comm="alsa-sink" requested_mask="d" denied_mask="d"
comm="alsa-sink" requested_mask="w" denied_mask="w"
comm="alsa-sink" requested_mask="mr" denied_mask="mr"

Another entries from a log files, which are also related with a 'complain'
mode. I would like to ask what AppArmor rules should I use if it is about
such things?:

1. name="/usr/lib/i386-linux-gnu/libpulse.so.0.13.5" pid=3559
comm="pulseaudio" requested_mask="r" denied_mask="r"

2. name="/usr/lib/i386-linux-gnu/libpulsecommon-1.1.so" pid=3559
comm="pulseaudio" requested_mask="r" denied_mask="r"

3. name="/usr/lib/libpulsecore-1.1.so" pid=3559 comm="pulseaudio"
requested_mask="r"

4. name="/usr/bin/pulseaudio" pid=3559 comm="pulseaudio" requested_mask="x"
denied_mask="x"

5. name="/etc/ld.so.cache" pid=3560 comm="pulseaudio" requested_mask="r"
denied_mask="r"

For now I'm using something like this:

1. /usr/lib/i386-linux-gnu/ r,
    /usr/lib/i386-linux-gnu/* r,

2. /usr/lib/i386-linux-gnu/*.so r,

3. /usr/lib/ r,
    /usr/lib/*.so r,

4. /usr/bin/pulseaudio mixr,

5. /etc/ld.so.cache r,

NOTE: 1., 2. and 5. examples are, probably, wrong. This should be done in a
different way.

I have one more question: let say, that in my system there is not
/usr/lib/pulse-[2-9].[0-9]/modules/ directory but
/usr/lib/pulse-1.1/modules/ and I need to allow 'mr' mode for '*. so'
files, can I use this rule?:

/usr/lib/pulse-1.1/modules/*.so mr,

It is sufficient? One more thing: I've done one thing, which I shouldn't:
run 'sudo pulseaudio' command (NOTE: just as before - for testing
purposes.) There appeared, of course, appropriate message message about
this type of things.

The result: log files contains plenty of ALLOWED capabilities: 6, 7, 23, 24
etc. which means, respectively:

6. - capname="setgid"
7. - capname="setuid"
23.- capname="sys_nice"
24. - capname="sys_resource"

I guess, that I should not put any rules in the PulseAudio profile, which
are related with above capability, right? As I wrote: it was done only for
testing purposes.

It seems, that it's all for now. I can paste somewhere a full profile if
needed. Some "technical" informations:

release: 12.04 LTS
apparmor: 2.7.102-0ubuntu3.10

Best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20160810/8a38735d/attachment.html>


More information about the AppArmor mailing list