[apparmor] Mapping end-user applications to security contexts

[Jamie Strandboge]

On 08/25/2013 09: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:

...

>>> 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. :)
> 
In Ubuntu there are two other apps that are currently considered trusted helpers
in addition to online accounts: location-service and friends. These all will
interface with apparmor in some way (currently to get a security label) and then
prompt the user for a decision and cache the result. Because they do similar
things, lp:trust-store (CC'ing Thomas Voss who is currently designing this) is
being created so that much of this can be abstracted away from the trusted
helpers. The trusted helper interfaces with the trust-store so the trust store
can handle the caching, etc. In the short term (expedient case) I imagine this
is just an indirection and the trust-store backend would just store the cached
results and allow queries on if the result was cached (API TBD) like online
accounts is doing now. Moving forward though, the trust-store backend could use
our preferred-but-yet-to-be-implemented apparmor solution to better unify
policy. The trusted helpers don't have to change, thus saving people time, which
is good. :)

This got me thinking that the trust-store might also be a good place to store
the meta-data Alberto needs (ie, the desktop file) since per this thread
providing metadata storage in apparmor is not necessarily the best place and
trusted helpers shouldn't have to jump through hoops to have this either. I
don't know how the trust-store would get this extra metadata that it would
store, but that isn't really AppArmor's (and therefore this list's) concern and
would be distro-specific. This can certainly be discussed on another list when
Thomas announces the project.

-- 
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/20130827/6790e50f/attachment.pgp>