[apparmor] Mapping end-user applications to security contexts

[John Johansen]

On 08/22/2013 01:59 AM, Alberto Mardegan wrote:
> Hi all!
>   As some of you already know, Ubuntu's OnlineAccounts plans for the
> next months include maintaining its own dynamic ACL of which
> applications are allowed to use a certain account, with the end-user
> being the decision maker. Therefore, in order to create and update the
> ACL, we ultimately need a way to map the profiles returned by apparmor
> to an application name and icon that the user can recognize.
> 
This is not so easy to do, and is impossible except in fairly restricted
environments.

AppArmor attachment is not in general statically defined and you can
get different attachments based on an applications actions (change_hat,
change_profile, stack) or on which context/view an application is launched
from.

For example Ubuntu click packages when launched via the desktop file or
upstart will invoke aa-exec to attach the desired profile. Launching the
application via a shell can result in a different confinement.

You certainly can lock down the environment to make the attachment
static but for most deployments of apparmor there is no static mapping.

> So, when an unauthorized application will want to access an online
> account, we would like to know not only the profile of this application,
> but also a display name and icon, and maybe some other metadata to
> display to the user, so that he can decide whether the application
> should be allowed to access the protected resource (the online account,
> in our case).
> 
> The .desktop files described in the freedesktop.org specification [0]
> contain all the application metadata we need (and more), so I think that
> this is the information we'd like to get.
> 
sure

> As I understand it, there are currently some hackish way to get a
> mapping from the profile to a .desktop file (matching on the Ubuntu
> Click package unique ID or, for the cases where the profile is the path
this assumes that Click ID or path to binary are the view that profiles
are being attached from. This may be a safe assumption from online accounts
and it may not be.

> to the binary application, browsing through the .desktop files checking
> the command in the "Exec" field and try to match it with the executable
> path), but they can fail in a number of ways.

yes, there are a lot of failure paths here. Again there is no static
mapping except from specific well defined views.

> In a private conversation with Jamie, he hinted that apparmor could
> store the mapping in its profile files, and provide a couple of methods like
>    - aa_desktop_file_for_profile(<profile>)
>    - aa_profile_for_desktop_file(<desktop>)
> 
No, and yes.
AppArmor policy can be extended to include new types, and it will certainly
have to provide access to those items within the profile. However it is
unlikely that apparmor policy would be extended to include that meta data
mapping as again, there is not a static policy mapping.

Profiles can be reused from different "view points" and in such cases
static mappings would be harmful. It might be possible in the future to
add such information as a dynamic mapping that could be set and queried
from an application that is running. Would that be sufficient for your
needs?

> This would indeed meet our needs, and it could be helpful for other
> software which maintains its own dynamic ACL (of which we don't have
an app maintaining its own ACL is discouraged. There are cases where it
is expedient or even the best solution but generally, extending policy
so that all confinement information can be managed in one place is the
preferred solution.

That isn't to say that trusted helpers are discouraged, just a trusted
helper storing the information in its own ACL. When security policy
gets split it makes it harder to manage and there can be all kinds of
unintended consequences when only partial policy changes happen because
some of the policy is invisible/hidden from the policy author.

> many examples, but arguably it's because of a chicken-egg problem of not
> having a security framework which can identify apps).
> 
Well its a larger problem then that. Security has long been and still
remains a largely ignored problem, because it is hard and gets in the
way. Generically there is no static mapping to "identify apps" nor can
there be.

It is certainly possible for a distro to set up an environment where such
a mapping exists but it will have to be quite locked down.

> Do you think that this is a sensible approach?
> 
We need a better definition of what environments this must work from.
Is it something that is being limited to click package applications or
are you trying to support a broader application environment.

Are we supporting on running applications (dynamic) or are we trying
to make this mapping a static thing.

Is it the mapping of name and icon to policy that is most important
or perhaps the decision of if a policy has access to an online account


In general I am in favor of centralizing security policy but I am not
sure whether this mapping falls into that.