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

[John Johansen]

On 12/06/2010 05:51 PM, fykcee1 at gmail.com wrote:
> 2010/12/7 John Johansen <john.johansen at canonical.com <mailto:john.johansen at canonical.com>>
> 
>     >     * 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.
> 
> If a user logged in, then run a program from login shell(e.g. /bin/bash), how does this program be confined if no profile attached with it? e.g.:
> 
That would depend on the profile confining the login shell.

If the login shell is not confined then, regular profile attachment based off of the executables name is applied, but this is not what you want for RBAC.  For RBAC you confine the login shell and every application it runs.  Often you will want only a single profile per role,
that is this user can access these resources, not a profile per application.  To do this you would set up your exec rules using an ix (inherit current profile), rule.
  eg. Allow running all programs, but they will be confined by the current profile
    /** ix,

The actual level of control has to be decided by the policy.  You could just allow a few applications, or only applications that can live with in the rule set.  If you are using more than one profile for a role then you will want to make sure all profiles are defined.

>     * The program will not run, because this is not described in login shell's profile.
>     * Or profile stacking? (mentioned at https://apparmor.wiki.kernel.org/index.php/AppArmorRBAC), what is it in detail? Is it available(shipped with linux-2.6.36 and the userland tools are ready)?
Sorry the wiki is in such a shambles.  Its a work in progress, and most of it is brain dumps at the moment.  Profile stacking is not currently available, and is still at least a couple releases away.  Sadly its one of the features that largely existed and then got cut out so that we could clean things up and get a release out the door.

The idea behind profile stacking is simple, a task may be confined by more than one profile, and its effective permissions are the intersection of the profiles.  There are a few places we want to leverage this, sandboxing, containers, user profiles (user is allowed own set of profiles, and the system has a set applying as well).

Most of these cases also will be leveraging profile namespaces, which already exit at the kernel level and are supported by the parser but
don't have support in any of the tools yet.  Profile namespaces allow for independent sets of profiles, so the system can have its own set and the container can have its own independent set that it can load.  Without profile stacking (the current situation), the container can only have its own set of profiles if the system isn't confining the container.

> 
> 
>     >     * 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.
> 
> How to express a user has role A, role B, etc? A user changes his/her role to C, but role C may not be allowed for this user. How to confine role transition?
> 
AppArmor doesn't have the concept of shadow user or role.  With the current set up, AppArmor needs a helper application which hasn't been written yet.  All the pieces are in place so some one can write it, it just doesn't exist yet (partly because there are a few other things that have taken higher precedence).

Under the current setup, the helper application (or pam module) would handle the mapping of users to profiles, it would then make the change_hat, change_profile, api calls to make the transitions.

Within the roles, inter role transitions are easy to control at the profile level.  Eg. role A can transition to role B but not at the user level.  ie.  role A can transition to role B if the user is foo.  This ability is coming it just hasn't hit yet.  The goal has been get the base upstream and then getting the rest of the bits in place. 

If we are careful how we set this up, the user mappings can be shared by the profile and helper app, or pam module.
>  
> 
>     >
>     >
>     > 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.
> 
> Say implement sandbox executing for each application with AppArmor, I need profiles for each application. It may have many applications installed, loads all profiles will take a long time/occupy a large memory, so I expect a profile-load when an application get executed, and a profile-unload when termination. Does AppArmor support an profile-unload feature?
> 
Yes apparmor supports both live replacement and removal.  There is however a couple of important caveats with removal.
1. Once an application has its profile removed, it is becomes unconfined and there is no way to reconfine it unless it chooses to confine it self (or you restart the service).  If you only remove profiles when it is not confining a process this should not be a problem.
2. Just because a profile has been removed does not mean that is memory is immediately freed, profiles are reference counted and there may be references from kernel objects other than tasks that pin the profile in memory for a while after it has been removed.

Sandboxing is an interesting problem, and yes you can do it per application or, have more generic sandboxes.  It is something I have tinkered with but we haven't been able to provide the frame work yet to make it easy.  This will come, but it will follow the next round of kernel patches.