[apparmor] Questions about RBAC and profile load-time of AppArmor

[John Johansen]

On 12/06/2010 05:44 AM, fykcee1 at gmail.com wrote:
> Hi all,
> 
> I've read documents on apparmor.wiki.kernel.org <http://apparmor.wiki.kernel.org>, it mentions different RBAC implementations for each release of AppArmor.  What is the preferred way of using RBAC? 
> 
>     * Using pam_apparmor to change hat for login service, and then forks a confined session(e.g. /bin/bash)?
yes, pam_apparmor is better than all the other methods, unless you aren't using pam.

currently pam_apparmor is a bit of a pain to setup because it uses change_hat*, instead of change_onexec (that
ability will get added at some point).

Basically the idea is to setup a hat for each user, with a named profile transition on the user's login shell to
the profile that defines the role.

eg.

  ...
  ^jj {
    /bin/bash px -> role_x,
  }
}

profile role_x {

}

>     * If the confined session launches a process without a corresponding profile, will this process be confined?
No, (maybe?)  Basically if a process is launched unconfined then it will remain unconfined, even if a profile that
would confine it is loaded.

There is currently no way to force confinement on an unconfined running process, however that process can use
the change_profile api to confine it self and then it and its children launched after taking on the confinement
will have profiles attached.

>     * Does a role transition require a  logout and login to another account?
If the user is unconfined, it does require the user to log out before confinement will take affect.

Logging into another account is entirely dependent on how the roles are setup, but is certainly not necessary.

> 
> 
> Also, does AppArmor support "on daemon profile load"? i.e. Load a profile just before related program get executed automatically, and then unload the profile when program terminates -- saving some memory footprint.
> 
Not yet and yes.  AppArmor supports incremental profile load, ie. new profiles can be loaded at anytime, as
long as they are loaded before an application is run they will attach properly.

If the program is a service managed by the startup service (upstart, systemd) it would be possible to setup
those to load the profile before the service is started.

There are plans to add an interface that would allow a daemon profile load triggered by apparmor it self.
This would greatly enhance the current learning tools ability.


* change_hat is limiting for a few reason's
1. It requires the login service to be confined, so that it can have hats.
2. It requires that the admin assigning the roles has the privilege to modify/load policy
3. It requires a hat per user or group that is being mapped

The use of change_onexec fixes this because
1. change_onexec can be used by unconfined processes so the login service can be left unconfined
   if the admin is so inclined.
2. The mapping will be external to policy, so roles can be assigned independent from policy
   2.1 admin assigning roles doesn't need privileges to modify/load policy
   2.2 mapping are handled without needing extra hat profiles


> 
> 
> 
> -- 
> Regards,
> 
> - cee1
>