[apparmor] Apparmor rules for dconf confinement

[John Johansen]

On 05/27/2015 10:22 AM, William Hua wrote:
> Hi,
> 
> Currently, there's no way in Apparmor to sandbox applications from
> accessing any setting in a user's dconf database other than preventing
> access altogether. We want to add a new rule to the policy format to
> permit this. Here's the proposed syntax:
> 
> [audit] dconf <dconf-path> [r|rw],
> 
> We need to make some small changes to the Ubuntu kernel for this due
> to the internal workings of dconf. When the application starts, dconf
> needs to know on the full list of readable/read-writable paths, so the
> aa_query_label() function and its kernel implementation don't quite
> fulfil this need.
> 
> I'm proposing for review the attached kernel patch. There is also the
> corresponding Launchpad Apparmor branch at
> https://code.launchpad.net/~attente/apparmor/dconf-rules-3, which
> currently works with the patch, but is still a WIP (missing docs, and
> we're considering adding label query support as well).
> 

So first up a few questions, why are the entries stored in an array?
The kernel has no need to look at these so it could stored as a single
blob of data.

Why the separate permissions lists?
This exported data is only for establishing dconf watch lists, it can
not ever be used for permissions, or to seed cached permissions.

With reducing this to a single blob of data I think we could consider
having a more generic command, to just ask for a named blob of data.
This way the command isn't dconf specific but could serve dconf and
maybe other uses in the future.