[apparmor] Change hat explanation

[John Johansen]

On 09/23/2013 01:58 PM, azurIt wrote:
> Hi,
> 
> i'm little confused about how changing hat is supposed to work. Example from my environment:
> I have Apache web server which serves web sites of our users. It has only privileges which users needs. The same Apache (but another instance) is serving also administration system - it needs little more privileges. I created a hat for admin interface which has more privileges than main profile and our admin system is changing into it immediately after starting.
> 
> My questions:
> 1.) Is this what are hats for?
possibly, it largely depends on if the process needs to be reused of return
from a function of different privilege

> 2.) How do i prevent normal Apache/users from changing hats too and getting more privileges?
> 
Hats are a specialized subprofile (profile within a profile) that are used
in places where a return from an alternate privileged domain is needed. If
an application is designed so that it does not need to return change_profile
should be used instead.

change_hat is the same as change_profile except that it requires a magic
token, and it stores a reference to the previous domain (profile) so that
the application can return to it.

The magic token should be a random value and stored in a memory location
that the function with different privilege does not have access to (easily).
Because change_hat allows a return to the previous confinement when the
magic token is provide, its security value is less than that of
change_profile. There are cases where this is an acceptable trade off and
it provides security that is similar to change_profile or at least better
than nothing.

When it is used with a VM (like mod_php, mod_perl, ...) that do not provide
direct access to the task memory to the application being run, then it is
unlikely a hack of the application can get the token that allows returning
from the domain. A hack of the VM may allow access to the token but, this
still requires finding the token in the VMs memory.

Brute forcing of the token is not possible (if it is randomly chosen at run
time) because a failed token match results in the task being killed. Even
if change_hat is used in a situation where a hack/hacker may have access to
the memory where the token is stored the attacker must know change_hat is
being used, where the token is stored and how to invoke the return
change_hat to return to the previous privilege domain (profile), so
change_hat at least raises the bar for a successful attack (and if the
attacker makes a mistake they will be killed).

Using change_hat to change into a hat of greater privilege is a little
strange but does have some value. It enforces a privilege separation that
can pick up casual errors, it however does have a problem that the reverse
 (lower privilige hat) doesn't have. The parent profile is always allowed
to enter the hat profile so an attacker just has to change_hat into that
profile to raise privilege (the attacker gets to choose the token that is
required for return at this point so there is no failure kill protection).
With that said there is some value, the attack has to know that the
application's privilege have been divided using change_hat in this way, and
he must know the name of the hat to transition into, with out this an
attacker can not transition the parent profile into the child hat that
allows the higher privilege. Its not perfect security but it an additional
barrier the attacker has to overcome.

There is one other note about the safety of change_hat/change_profile to
be aware of. Changing the task security domain without an exec has lower
security than doing it across an exec boundry because the memory and files
of the task are shared in the tasks image. AppArmor mitigates the file
accesses by requiring a revalidation of file accesses. However if the
attacker can get direct access to the tasks memory apparmor can't provide
any protections, between that hat and the parent for memory based data.