apparmor_monkeys 0.0.1

Description:

apparmor monkeys 0.0.1

Monkeypatches to minimize the permissions required to run python under AppArmor.

What does this do?
Imagine you’ve written a simple Django application. Maybe you just followed the
Django tutorial. All your code does is a bit of database querying. Then you
deploy it under AppArmor and:
type=AVC msg=audit(1443087838.797:1078): apparmor="DENIED" operation="exec" profile="helloworld-application" name="/bin/dash" pid=8202 comm="python" requested_mask="x" denied_mask="x" fsuid=999 ouid=0
Suddenly your audit log is full of messages complaining that your application
is trying to run a shell. You certainly didn’t write code to do that. Whats
going on? Did you get hacked?
You (probably ;)) didn’t get hacked.
Turns out python shells out when doing some fairly mundane stuff. Up until now
you could:


Ignore it. Let your audit log have DENIED entries that you have to
ignore. Now it’s hard to spot suspicious behaviour in your monitoring.
Thinks might be broken, thinks might not be broken.
Hope you don’t have to go through that log with a security professional.
Allow it. Now your profile is broader than it needs to be. You are throwing
away the security you gain in the first place. Hope you don’t have to go
through that profile with a security professional.


This package patches several stdlib API’s to avoid subprocess usage,
letting you keep your simple profiles and clean audit logs.

ctypes vs ldconfig
One of the first things I caught by application doing was trying to run
gcc. This turned out to be a fallback for when an earlier attempt to run
ldconfig had failed.
This turned out to be how ctypes.util.find_library works. This can be used
in a few places:


Gunicorn uses it for its sendfile implementation.
Python’s uuid module uses for uuid4. Just importing the uuid
module triggers this, even if you aren’t using uuid4.




platform.uname vs os.uname
platform.uname is mostly the same as os.uname, but there is an extra
field. The field is sourced by shelling out and running uname -p:
sh -c "uname %s 2>%s"
This is used in several places:


A command trick for getting your own version number is
pkg_resources.require('myapp')[0].version, which triggers it.
Gunicorn triggers it via a platform.system() in
gunicorn.workers.workertmp before it even loads your code.





Activating the monkey patches

Manually
As early in your code as possible do:
from apparmor_monkeys import patch_modules
patch_modules()


Automatically via .pth hooks
And site-packages directory is scanned for .pth files. These are processed in order and are generally just a list of paths to add to sys.path. However any import lines will be honoured.
Create an apparmor-monkeys.pth in your virtualenvs site-packages directory containing:
import apparmor_monkeys; apparmor_monkeys.patch_modules()
It must be on a single line for this trick to work.



Switching profiles
You can harden your AppArmor profiles further using change_profile to switch into a different profile after initialising your app.
If using multiprocess gunicorn (i.e. synchronous gunicorn) then you can wrap
your workers in their own specific profile. In your gunicorn config you can add
a hook to do this:
from apparmor_monkeys import change_profile

def post_fork(server, worker):
change_profile("myapplication//worker")
You can do this for celery too:
from apparmor_monkeys import change_profile
from celery import signals

@signals.worker_process_init.connect
def switch_apparmor_profile(sender=None, signal=None):
change_profile("tenselfservice-worker//worker")