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

fykcee1 at gmail.com fykcee1 at gmail.com
Tue Dec 7 14:10:41 GMT 2010

2010/12/7 John Johansen <john.johansen at canonical.com>

> 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>>
> 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.
How to apply more than one profile to a role?

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.
Can I say we will have rules in profiles to describe:

   - What role transition is permitted?
   - Mapping user to roles.

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.
Say if a program terminates, does it have any chance that the profile only
for this program is automatically removed by kernel (i.e. the profile's
reference count reaches 0)? If yes, will the kernel load the profile
automatically when the program reruns?

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.
I'm just thinking a sandbox model: each package installed in its own
directory(something like nix package manager system). e.g. for firefox,
installed at:

   - /pkg/com.mozilla.firefox/bin/firefox
   - /pkg/com.mozilla.firefox/lib/components/libbrowsercomps.so
   - ...

A program will freely access resources in its own directory, something
like(for each in /pkg/*/bin/*):
generic_sandbox_rules {
    # SELF_DIR should point to /pkg/foo/bin/bar, I don't know whether we
have such a implicit variable currently, sorry.
    @{SELF_DIR}/../** rwxm

To access external resources(Dynamic link to libc, etc), the program needs
extra rules:

   - Include libraries's profiles
   - Add its own profile (e.g. requires socket )


- cee1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/apparmor/attachments/20101207/edd9c025/attachment.htm 

More information about the AppArmor mailing list