[apparmor] Initial thoughts on profiling with signal and ptrace

[Jamie Strandboge]

Running the kernel and userspace from the dbus-dev ppa[1], I finally got around
to profiling signal and ptrace with the current syntax. In general, I like it
and it is straightforward (lack of 'label=' notwithstanding). However I have
found myself repeating a couple of rules everywhere and I've barely gotten started.

= signal (send) set=("exists"), =

Curiously, this isn't used by all applications, but I did notice it was used by
several gui applications (firefox, thunderbird, rhythmbox, a pygi application,
Ubuntu Touch apps, ...).

Applications will use kill(2) or sigqueue(3) specifying '0' as the signal to see
if a pid is running (interestingly, signal(7) didn't mention "exists"). In some
ways I think this could probably be added to the base abstraction, but many
applications don't use it (eg, rsyslog, qemu, dhclient, etc). Perhaps we should
add this to the gnome abstraction and (possibly) the kde abstraction?

Interestingly, when running chromium-browser, I end up with these types of denials:
apparmor="DENIED" operation="signal"
profile="/usr/lib/thunderbird/thunderbird{,*[^s][^h]}" pid=13092
comm="chromium-browse" requested_mask="receive" denied_mask="receive"
signal=exists target="/usr/lib/chromium-browser/chromium-browser"

With this in mind, perhaps the rule should be:

  signal (receive,send) set=("exists"),

We could just have apparmor let this through and my initial thinking was that I
thought I'd prefer that we not assume all applications need it, but after seeing
how chromium-browser is behaving, I'm less sure mediating this one is useful (we
could let it through be allow deny rules I guess-- would need to document it
though).


= signal "<profile name>", =

Some applications like to send signals to themselves, for example, rsyslog and
qemu. Eg:

  apparmor="DENIED" operation="signal" profile="/usr/sbin/rsyslogd" pid=700
  comm="rsyslogd" requested_mask="receive" denied_mask="receive" signal=term
  target="/usr/sbin/rsyslogd"

  apparmor="DENIED" operation="signal"
  profile="libvirt-3a12a1f5-c8f5-c946-0357-021a3555aade" pid=8252
  comm="qemu-system-x86" requested_mask="receive" denied_mask="receive"
  signal=usr1 target="libvirt-3a12a1f5-c8f5-c946-0357-021a3555aade"

  apparmor="DENIED" operation="signal"
  profile="libvirt-3a12a1f5-c8f5-c946-0357-021a3555aade" pid=8406
  comm="qemu-system-x86" requested_mask="send" denied_mask="send" signal=usr1
  target="libvirt-3a12a1f5-c8f5-c946-0357-021a3555aade"

For rsyslog, this is easy to fix with a rule like this:

  signal "/usr/sbin/rsyslogd",

However, adjusting libvirt is considerably more complicated because the profile
name is autogenerated by virt-aa-helper based on the domain UUID. We would need
to adjust virt-aa-helper to add a rule like this:

  signal "libvirt-3a12a1f5-c8f5-c946-0357-021a3555aade",

At first glance, this isn't difficult, but I was reminded that virt-aa-helper
then needs to introspect the kernel to see if signal mediation is present at
all, which I don't think we want virt-aa-helper or things like it to have to do.

In all honesty, I was surprised that a process is not allowed to send signals to
itself and found that it isn't allowed counter-intuitive (though I appreciate
arguments to the contrary). I see a few options:

1. leave it as is and add introspection code to virt-aa-helper
2. allow processes to send themselves signals by default, but allow the use of
   deny rules to remove them. We would need to cover this in documentation.
3. have apparmor parser set a variable for the profile name so we can add rules
   like 'signal "@{PROFILE_NAME}",'.

I prefer '2' as it is intuitive, makes profiling more straightforward and
doesn't make other applications like libvirt have to jump through unnecessary
hoops. It allows for profilers to go more strict if desired (though not sure how
useful it really is to say "I'm going to allow this app to send SIGUSR1 to
itself but not SIGHUP").

Based on the profiles I've done, if we decide on '1' or '3', I will definitely
be adding 'signal "<my profile name>",' rules for Ubuntu Touch applications and
have a feeling we'll be adding it a bunch of other places in Ubuntu. '3' is
interesting and while it does allow us to put a generic rule in
abstractions/libvirt-qemu such that virt-aa-helper doesn't have to be modified,
it doesn't help with being counterintuitive.

If people violently object to '2', how hard would it be to do '3' in the short
term? Even if we do '2', we probably still want '3' in the medium term since I
think it could be useful.


-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140324/9049f682/attachment.pgp>