AppArmor blocks apport python hook from working

[Julian Andres Klode]

The Python profile is very strict, but it prevents Python applications from producing proper crash reports using apport, as the apport hook cannot be loaded, as it requires access to dpkg's cputable, and likely also apt config files and dpkg status files.

I'm wondering what the right approach here is: Should the apport hook work under AppArmor, and do we thus have to add the files the hook needs; or should we just say "screw it, we want the additional security" and not get proper error reporting while AppArmor is confining the program?

This can be seen in recent autopkgtest failure for kopanocore:

+ kopano-search --help
Traceback (most recent call last):
  File "/usr/sbin/kopano-search", line 4, in <module>
    import kopano_search
  File "/usr/lib/python3/dist-packages/kopano_search/__init__.py", line 18, in <module>
    from queue import Empty
  File "/usr/lib/python3.7/queue.py", line 16, in <module>
    from _queue import Empty
ImportError: /usr/lib/python3.7/lib-dynload/_queue.cpython-37m-x86_64-linux-gnu.so: failed to map segment from shared object
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/apport_python_hook.py", line 63, in apport_excepthook
    from apport.fileutils import likely_packaged, get_recent_crashes
  File "/usr/lib/python3/dist-packages/apport/__init__.py", line 5, in <module>
    from apport.report import Report
  File "/usr/lib/python3/dist-packages/apport/report.py", line 30, in <module>
    import apport.fileutils
  File "/usr/lib/python3/dist-packages/apport/fileutils.py", line 23, in <module>
    from apport.packaging_impl import impl as packaging
  File "/usr/lib/python3/dist-packages/apport/packaging_impl.py", line 24, in <module>
    import apt
  File "/usr/lib/python3/dist-packages/apt/__init__.py", line 35, in <module>
    apt_pkg.init_system()
apt_pkg.Error: E:Error reading the CPU table

[Marc Deslauriers (mdeslaur)]

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

[Marc Deslauriers (mdeslaur)]

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

[Julian Andres Klode (juliank)]

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.

[Julian Andres Klode (juliank)]

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

[Jamie Strandboge (jdstrand)]

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.

[Jamie Strandboge (jdstrand)]

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

[Julian Andres Klode (juliank)]

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

[Jamie Strandboge (jdstrand)]

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