[apparmor] Mapping end-user applications to security contexts

[Jamie Strandboge]

On 08/28/2013 05:08 AM, Ángel González wrote:
> I have been thinking on this and my conclusion is that they are orthogonal
> problems.
> 
> The question «Is the music player allowed to use an online account?» should be
> answered by apparmor (by providing the appropiate dbus rule).
> 
> On the other hand, the user-defined decision of «Allow access to the [music
> stored at] account to banshee but not to mplayer» shall be taken by the trust
> helper, *not* apparmor.
> 
> 
> In fact, nothing from the problem description «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.» requires AppArmor at all.
> The applications should be confined (and the helper may enforce that they have
> any profile). And enabling the account usage may involve changing the
> application profile.
> 
You are describing the 'expedient case'-- ie, that is pretty much what we are
doing now and what the online accounts and lp:trust-store will initially do. Eg,
online accounts is the trusted helper and it determines if the app is confined
by interfacing with libapparmor. If it is, it will handle interacting with the
user and caching the results (it is not able to update policy for the app or
itself). This is easier in the short term and ok for now.

The problem John described (and I agree) is that while it is online accounts job
to query the user and cache the result, online accounts is doing a sort of
mediation. Eg, when an app (that is allowed by policy) talks to online accounts
to obtain a token for facebook, online accounts checks its cache to see if it is
allowed or not (and may prompt). It can be argued that this is a policy
decision. Now we have policy in AppArmor rules and in online accounts' cache
database. Add other services like location and friends, and now policy is in 4
places. Even with everyone using trust-store, it is still two places. Better
would be that all this policy is captured in AppArmor somehow-- perhaps as
dynamic rules. Ie, the trust-store instead of maintaining its own database of
results from various trusted helpers could interface with apparmor to add/remove
dynamic rules so that the mediation decision rests with AppArmor--
trusted-helpers/trust-store need only enforce the result that AppArmor returns
when AppArmor is queried. This is actually how DBus works now (except of course
its rules are static rules in policy as opposed to dynamic).

> But the problem is to identify applications, not profiles. (And the solution
> will end up being more general, which is good too)

Yes, you are right, but what I was responding to was the comments surrounding
how trusted helpers should work. I then noted that trust-store could possibly be
used to help identify applications/store metadata about applications (and
trust-store is a separate project from AppArmor).

-- 
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/20130828/8ace9d33/attachment.pgp>