[apparmor] Mapping end-user applications to security contexts

[Jamie Strandboge]

On 08/23/2013 01:19 PM, John Johansen wrote:
> On 08/22/2013 01:59 AM, Alberto Mardegan wrote:

...

> 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.
> 
Nitpick-- currently aa-exec is used for non-upstart launched applications.
upstart will use /proc (effectively the same, I know). This may be
refined/changed going forward.

>> 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.

Now to be clear, what I said is that it would be possible to do a static
mapping, but I didn't know if that would be a great idea. It isn't clear to me
yet how this would be harmful though. My thought (and again, I am not proposing
this-- I am bringing it up as a discussion point) was apparmor could provide a
sort of database so that profile names could have attached to them various
metadata. Eg (syntax, again, is not proposed just something to help express
thoughts):
 meta foo {
  "desktop": "/path/to/foo.desktop",
  "icon": "/path/to/icon.png",
 profile foo {}

A trusted helper could then do:
 desktop = aa_profile_meta("foo", "desktop");
 icon = aa_profile_meta("foo", "icon");

I realize things could get bad if we tried to do this in an abstraction and
there are some questions surrounding inheritance, but if we attach meta to a
profile name (expressed via "profile" or binary attachment), then if the process
is running under that profile name, couldn't it be argued that the metadata is
still relevant for that process (yes, even if '/bin/ls' inherited foo's profile,
I think it could be argued that ls is working on behalf of foo, and therefore
the meta still applies)? I'm thinking of this database of meta information as
more of a service that apparmor provides that trusted helpers could tap in to
and as such, they would need to designed in a manner where this would make sense
for them.

> 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 sounds interesting.

...

>> 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.

To reiterate the 'expedient' case-- in the short term we don't have time to
implement the preferred solution as John suggests and so we'll have to have this
for now with online accounts, location and maybe friends, but we can refine this
in the future. Also note, my thought about static mapping also could not be done
in the short term-- so if we can do a proper solution first, that would be best. :)



-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130825/b658b80b/attachment.pgp>