[apparmor] Mapping end-user applications to security contexts

[John Johansen]

On 08/25/2013 07:23 AM, Jamie Strandboge wrote:
> 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.
> 
nah, hitting the interface directly is fine, point being its using self
directed transitions that don't have to match profile attachment specifications.

>>> 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
possible but only guaranteed to be correct in a locked down environment where
no self directed transitions are allowed (or are strictly controlled so that it
doesn't really make sense to use them), and you might have to ban certain
policy based transitions as well dependent on what you are doing with the mapping.

> 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 {}
> 
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

> 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
Not just inheritance, self directed transitions, stacking, delegation.

> 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
sure. But the problem is larger than inheritance.  Upstart doesn't respect the
policy attachment, it makes its own choice based off of a mapping stored else
where (yes I am aware it should sort of be consistent atm) and directly transitions
to the profile. This hits on my complaint about upstart doing the transitions,
the mappings it uses aren't in regular policy so we are effectively storing
policy decisions in 2 (or more) places.

Perhaps because the application is confined by profile X then the meta information
for X could still be argued to be correct, even if it didn't inherit X nor 
doing work on behalf of X.

But then what of stacking? You now have 2+ pieces of meta information to apply.
We could apply the meta information for just the current namespace but with stacking
there is no guarantee that we have just a single profile in the current namespace.
Ordering within current namespace is arbitrary, which do you choose? Or perhaps
you choose all and do a blend of them?

> 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.
> 
sure, I just don't want to get in a situation where we are offering something
we can't really provide reliably

>> 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.
Right basically setting some kernel variables for different instances

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

right, since we don't have time to implement any atm lets bike shed