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

[Seth Arnold]

Hi Daniel,

I have some general advice that I'll give up here, and then some specific
comments in-line in response to your email. (I know, it's unusual, which
is why I mention it. But I think it'll be easier this way.)

First, you may wish to try the aa-genprof tool. It will automate some of
these steps for you and interactively prompt you for each denied access in
the logs. It'll offer one-touch keys to "glob" files, and knows the
correct syntax for most of the language. I think you'll prefer it.

Second, if you want to continue with this profile, I'd recommend adding
the line #include <tunables/global> to the top of the profile (outside the
body of the profile, look at another profile for an example), and
#include <abstractions/base> within the profile.

<abstractions/base> includes read-only access to a lot of libraries and
some accesses that are just so common that it makes sense to include them
everywhere by default.

On Wed, Aug 10, 2016 at 07:54:11PM +0200, daniel curtis wrote:
> 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)?

I can't recall what level of ptrace support existed in this AppArmor.
Granting full "ptrace" and "capability sys_ptrace" in the profile
drastically reduces the usefulness of the AppArmor profile. If your
version of AppArmor allows restricting ptrace further I'd recommend to do
so.

(In newer versions, for example, <abstractions/base> includes this line:

ptrace (read) peer=@{profile_name},

as it is generally safe -- no control or data moves across profiles this
way. And hopefully this would cover whatever it is that pulseaudio
requests.)

> 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"

It's quite common to create new files using a temporary filename in the
destination directory, fill them with whatever they need, then perform an
unlink() rename() sequence. (Most text editors work this way, too, so a
file can't have mixed new and old content, in the event of a crash.)

So you shouldn't see the orcexec.XXXXXX files in normal use, unless you
look -very- quickly. :)

> 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.

Almost all of these should be covered by #include <abstractions/base>.

> 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?

Sure, if this matches the files on your system, that's fine. We've tried
to make our profiles a little flexible for possible upgrades; it's not fun
to have an upgrade fail partway through because an AppArmor policy denies
accesses that a new executable expects.

> 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.

Yes, feel free to omit from the profile anything that you don't want. If
you then try to run pulseaudio in system mode, it may not function
properly, but that's fine. You get to tailor your profiles to your
expected uses.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20160810/d9203cce/attachment.pgp>