ubuntu-appstore-developers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

On Tue, Jul 16, 2013 at 05:16:44AM -0700, Steve Beattie wrote:
> For the apparmor side of the things, my vision of the hook workflow
> would look like so: when notified of a click package install,
> the apparmor hook identifies the added manifest file for that click
> package, converts it to an apparmor profile or profiles, writes those
> profile(s) to disk in an expected location[0], and then loads those
> profiles into the kernel to be enforced.
> 
> I've shoved some very prototype-y code up to
> lp:~sbeattie/+junk/click-apparmor for you to play with,
> which implements the apparmor.click.to_profile() and
> apparmor.click.load_profiles() steps. You can get a rough idea of
> how to use them through the aa-clickprototype utility.
> Example invocation:

Thanks, this is very useful.

>   sudo ./aa-clickprototype -d /etc/apparmor.d/ \
>      /opt/click.ubuntu.com/com.ubuntu.ubuntu-calculator-app/0.1.3/.click/info/com.ubuntu.ubuntu-calculator-app.manifest
> 
> Afterwards, 'sudo grep com.ubuntu.ubuntu-calculator-app /sys/kernel/security/apparmor/profiles'
> should show you something like:
> 
>   com.ubuntu.ubuntu-calculator-app_ubuntu-calculator-app.desktop_0.1.3 (enforce)
> 
> I still need to implement bits for handling removal of packages.
> 
> Some questions and notes that I have:
> 
>  - do we get any information when our hook is invoked? For cases
>    like help indexers, they likely need to re-walk all of the
>    information they're indexing[1]; however, we'll want to avoid
>    regenerating/reloading all click apparmor policy each time a
>    package is installed, as that would be very expensive.
> 
>    Based on what I last saw of the click documentation, the executed
>    hook would be expected to walk its directory of click symlinks
>    trying to identify which one is newest/hasn't had apparmor policy
>    generated for it. Furthermore, if there's no version information
>    passed/attached, the hook has to identify which version below the
>    package is the most recently installed -- I'd assume it's possible
>    it may not be the highest version since we're allowing multiple
>    versions to exist. Is this understanding correct?

I'm indeed deliberately trying not to pass very much information to
hooks, and instead require hook implementations to operate in a "catch
up to current state" model.  My experience with implementing hooks
elsewhere in packaging is that when I don't do this I later wish I had.
:-)  While it doesn't apply to apparmor since that's installed by
default, this model makes it much easier to have optional hooks provided
by packages that aren't installed by default, and in general makes
things more robust.

You seem to be storing profiles in (effectively) a cache directory and
loading them from there.  If you can arrange to only reload those
profiles generated in the current run, then that should do the trick.

Similarly, for removal of packages, this should be a catch-up affair: if
your cache directory has identifiers not present in the set of symlinks
populated via Pattern declarations, then remove those profiles from the
kernel and the file system.

I think the business in the Click hooks documentation about symlinks to
the current version is a mistake; as you note, it has problems with
multiple co-existing versions, which is a concept whose implications I
hadn't fully absorbed when I wrote that documentation.  I'm going to
revise this to reflect the app ID ideas recently discussed with Ted.

>  - on the apparmor side, we will need a force regeneration/reload
>    capability, both for handling the possibility of click packages
>    that have been installed before the apparmor hook is registered

dh_click should handle this for you.

>    as well as when updates to the ubuntu apparmor policy templates
>    occur to fix whatever issues come along.

Right, if you change the format of your hook output then you need to
regenerate/reload everything in your postinst.

> [0] for the demo, /etc/apparmor.d/ is fine; this will likely need to
>     move with single image updates, where /etc/ may not be writable.

I'm not totally sure we won't be on system-image-updates for the demo.

> [1] not relevant for apparmor, but I wonder how aggregators like help
>     indexers are supposed to handle multiple versions?

Right, one size isn't going to quite fit all here, although we can make
it as uniform as possible and try to resist the impulse to overengineer
it.  I am inclined to revise the hooks spec as follows:

 * System hooks are those which operate on the full set of installed
   package/version combinations.  They may run as any (system) user; add
   a new User field to the hook declaration to declare which.  (Example:
   apparmor profile handling.)

 * User hooks are those which operate on the set of packages registered
   by a given user.  They run as that user, and thus would generally be
   expected to keep their state in the user's home directory or some
   similar user-owned file system location.  (Example: desktop file
   handling.)

 * By default, system hooks are expected to handle multiple versions.
   The %s substitution in a Pattern will expand to PACKAGE_KEY_VERSION,
   where KEY is a string given in the manifest for each instance of a
   hook (so for a package with multiple .desktop files it might be the
   base name of the .desktop file; I'll flesh this out more rigorously
   in the spec and give examples).  Target path handling is simplified
   accordingly.

 * In the case of some system hooks, it may not be possible to handle
   multiple versions, so add a "Multi-Version: no" flag which causes %s
   to expand to PACKAGE_KEY and to always correspond to only the version
   tagged as "current".  (IMO there is no rush to implement this since
   we only have theoretical uses at present; it should not be a demo
   blocker.)

 * Each user has at most one version of any package registered at any
   one time, so user hooks are only expected to handle single versions.
   The %s substitution in a Pattern will expand to PACKAGE_KEY.

Does this make sense?  It seems to me to be about the minimum necessary
and sufficient spec that covers the various use cases that have come up,
and I should be able to implement it by the end of this week if people
agree.

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]