AppArmor blocks apport python hook from working

Reassigning to the kopanocore package as that is what contains the problematic profile.

Do you have any examples of the denials it is hitting?

This is specifically not a kopanocore issue, but an issue with all Python programs that have an AppArmor profile. Patching each of them to allow Apport to run vs. the Python abstraction would make no sense.

I don't have any examples atm, but we know it tries to read cputable at least:

/usr/share/dpkg/cputable r

It might also need access to apt lists, but this needs investigating

/var/lib/apt/lists/** r
/etc/apt/apt.conf r
/etc/apt/apt.conf.d/** r
/etc/apt/sources.list r
/etc/apt/sources.list.d/** r

maybe

/etc/apt/preferences r
/etc/apt/preferences.d/** r

Traditionally we have actually put these accesses in the packages that ship the profile, like Marc said, because profilers may not want the profile to automatically have everything apport requires. These accesses should *not* be in the python abstraction because the accesses have nothing to do with python applications, they have to do with python applications with apport hooks that are confined with apparmor.

There was always the idea that perhaps we could create an apport abstraction and maybe move distro profiles to using it, but it isn't yet clear this is what we want to do since the accesses aren't fully understood.

For now, moving this back to kopanocore and adding an apparmor wishlist task.

I might also mention on IRC the exact type of thing why we've had these rules in the profile that ship them:

[119698.000187] audit: type=1400 audit(1555405334.985:222): apparmor="DENIED" operation="exec" profile="/usr/sbin/kopano-search" name="/usr/bin/x86_64-linux-gnu-gcc-8" pid=15647 comm="kopano-search" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

We aren't going to put compiler execution into the python (or likely any other) abstraction. It is difficult because for security you only want enough access so the application can behave normally which is often at odds with access the the application needs when it crashes or behaves unexpectedly (indeed, we wrap applications with apparmor precisely to limit what they can do when behaving unexpectedly).

> they have to do with python applications with apport hooks that are confined with apparmor.

The hook is defined in site.py, so by definition all python applications have the hook, and thus all python applications that are confined with apparmor.

So either we want that apport for all of them, or (what I think makes more sense) none of them.

I guess the question is: Shouldn't we have a python-apport abstraction that apps (or local admin) can include to make debugging work under apparmor? It should probably live in apport, I guess, so apport can define which files it needs.

IIRC, the gcc stuff is irrelevant, that comes from ctypes, imported from magic, not from apport. But that might also be a case where it could be useful to have a python-ctypes abstraction, probably shipped in python.

"I guess the question is: Shouldn't we have a python-apport abstraction that apps (or local admin) can include to make debugging work under apparmor? It should probably live in apport, I guess, so apport can define which files it needs."

Perhaps an abstraction makes sense to optionally add it in for debugging, but it is not clear what should be in that abstraction. I mean, if these things are running in process and the hooks can do anything, it might simply make sense to temporarily disable the profile while debugging via apparmor_parser -R /path/to/profile. Of course, that changes the environment of the application (but so does adding the abstraction).