[apparmor] Dynamic AppArmor rules

[John Johansen]

On 06/13/2014 09:00 AM, Paul Johnston wrote:
> Hi,
> 
> Has anyone done any work on dynamic AppArmor rules? I think these could massively help develop secure profiles for interactive applications.
> 
yes, part of the reason for the base rework is to provide better support
for things like dynamic rules.

> For example, consider the Firefox profile. To maintain 100% compatibility it needs read/write access to the whole file system, because you could upload a file from anywhere (or save a file anywhere). That would pretty much kill any security benefit. So we have the tradeoff where the profile breaks compatibility a bit, doesn't do all the security it could, it just does the best it can.
> 
well it really shouldn't be able to download to anywhere nor would I allow
it to upload from anywhere, but yes static rules can be quite restrictive.

> But what if we could have a rule that was "prompt". So when Firefox tries to access a file outside the explicitly permitted directories, the user gets a prompt asking them to approve or deny the access. Potentially this could have options like "Just now" "Allow for this session" "Allow permanently".
> 
> I couldn't find anything online on "dynamic AppArmor rules" but perhaps this is called something else? If so, just let me know, and I can look fro that!
> 
So the general approach to doing this is via what we call trusted helpers.
Which are applications external to the confined application, that handle
the communication with the user and then update the profile or delegate
object access to an application.

The interaction (file dialog, etc) have to be external to the application
as we can not trust any dialogs the application it self shows.

We are in the early stages of providing support for this. Ubuntu touch
has some basic trusted helpers, the new permission format has the ability
tag specific accesses as "prompt". There is support for per user profiles,
and user defined profiles in the works.

We do not currently have a generic mechanism to query a user, and allow the
user to make a decision. There are some reasons for this, up calling from
the kernel to userspace is problematic at best, at usually lies in the
category of verboten. By the time the kernel receives a request it may
not have the context needed to make a meaningful request to the user.
And there are several cases where the kernel just can not up call to the
user (checking permissions in interrupt context, etc).

So for a first pass we have been focusing on trusted helpers. That means
that the application needs to know it needs to contact the helper (portal,
intent, what ever you want to call it). Or the access mechanism is in
a library call that can be overload, access to the gnome file dialog can
be redirected to an external application transparently via dynamic
linker techniques.

That is not to say that a more generic solution doesn't have its place,
just that we are still working on laying the foundations of much better
dynamic policy support and will target the low hanging fruit first.