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. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
