[apparmor] Questions about apparmor

[John Johansen]

On 12/05/2010 06:18 AM, fykcee1 at gmail.com wrote:
> Hi all,
> 
> Apparmor seems quite interesting, and I have got some questions about apparmor:
> 
>    1. If an access permitted path is a symbol link, will a confined program with this profile be able to access it (i.e. can access the inode pointed by the symbol link)?
No, all path in the profile are post symlink resolution, and the enforcement engine
only generates post symlink resolution paths.

>    2. How to restrict "change_profile"? A program may change_profile to a privilege-less profile, then can injected malicious code calls change_profile to a more privileged profile?
change_profile and change_hat are for pseudo trusted applications, that is the task
doing the change is trusted enough to select for it self a profile to transition to,
from the prescreened set provided by the profile.

change_profile is mediated by the change_profile rule
   change_profile -> <profile name>,

change_hat is mediated by the present of a hat profile with in the profile
   ^hat1 {  }

also note while a hat is a local profile a local profile is not a hat profile as
it hasn't been declared to have the special hat flag.

When using both change_hat and change_profile there are several things that must
be considered.
  1.  The change in profile happens at the point of the api call, it is not delayed
      until a clean exec boundary.
  2. All resources that were opened/mapped before the transition continue to be
     accessible.
  3. Resource mapped within the profile transitioned too, will be available if/when
     that profile is exited.

This limits change_hat, and change_profile uses, as if they were used incorrectly,
they could indeed weaken security.  Generally for security auditing you must consider
what would be possible for the transitive closure of the profiles accessable in
change_hat, change_profile transitions before an exec.

There is a third api change_onexec which sets the profile to transition to at exec
time.  It is also mediated by the change_profile rule, so that a tasks self directed
transitions are limited and controlled.

  change_profile <executable_name> -> <profile_name>,

Generally if possible we recommend using apparmor's x transitions.  Any time a self
directed transition is allowed, extra caution must be taken.

>    3. Does it make sense to implement "per code segment profile"? i.e. attach each executable VMA with a profile. Then it can make profiles for libraries -- any program calls into a library, will apply the library's profile (just like a implicit change_hat, should take care of static link case, need a modified ld?). This can also be done by including profiles provided by libraries, and call change_hat appropriately, but not convenient.
I can see the appeal to this, but it isn't possible at this time.  Nor do I see this
being possible in the future do to technical limitations of the LSM.