[apparmor] Mapping end-user applications to security contexts

[John Johansen]

On 08/26/2013 11:51 PM, Alberto Mardegan wrote:
> On 08/26/2013 09:42 PM, John Johansen wrote:
>> yes but is apparmor the right place for this information? Its clearly not part
>> of the security policy. However there is a desire to link this information to
>> the security policy. So the real question is where is the right place? I am
>> just trying to raise issues to help us figure that out
> 
> Maybe another possibility would be storing the name of the apparmor
> profile in the application .desktop file (I seem to understand that a
> single process can have more than one profile, and that this can also
> change at runtime -- but we should ensure that every application has at
> least one profile which is unique to it, to make the mapping possible).
> 
every application? Or click based applications? We can certainly setup
a default mapping that works to our needs. Part of the question is what
those needs are?

Applications launched from the desktop
Applications launched from upstart
Applications launched from the terminal
Applications launched from other applications
- working on behalf of the parent
- working independently (will these normally be launched via upstart)

does it need to work for just click packages, all packages, what of interpreted
programs.

> The problem with this is that the field would be non standard and would
> require patching all the .desktop files for Ubuntu.
> 
sure, is this worse than/more work than extending profiles with meta information
that will be distro specific?

> A third option would be to have the information stored in separate
> files, which aren't .desktop files nor apparmor profiles, and then have
> an Ubuntu-specific API to access the information. Maybe a directory
> /usr/share/apparmor/applications/ (and ~/.local/share/ for
> user-installed apps) could contain files named after the apparmor
> profiles, containing just the name (with path) of the .desktop file for
> the application.
> But then extra care should be put to ensure that these files don't go
> out of sync if apparmor profile names change (though I guess this
yep

> doesn't happen often?).
> 
hrmmm, yes and no once a profile is created it doesn't usually have to be
changed much, however changes in the application, system or kernel can all
lead to revisions on a profile being needed.

How often this will be is really hard to say, hopefully we can keep most
of the system changes encapsulated in the abstractions, which would mean
application updates would be the major source of changes.


To be clear I am not saying no to extending apparmor policy with meta tags. I
just want to make sure we look at the options/requirements and choose what is
hopefully the best solution.