ubuntu-appstore-developers team mailing list archive

[Steve Beattie <steve.beattie@xxxxxxxxxxxxx>]

Hi Colin,

On Fri, Jul 12, 2013 at 11:14:46PM +0100, Colin Watson wrote:
> I don't think I can do it without examples to work on; that's just how
> my brain works.  So it would really help if you could give me your side
> of the hook: as close as possible to a script to take a desktop file as
> we'd find in an app and install it in the desired way in a real Ubuntu
> Touch system so that it will appear as a launchable app.  If it has gaps
> where you need to know about some feature of click before you can write
> them, that's fine, but I need to know the kinds of parameters I need to
> support in hooks before I can implement them properly, and the ability
> to experiment would be very helpful.
> 
> (I've said much the same thing to Steve Beattie, but in case the message
> didn't get across: I would prefer to be given a partial implementation
> of the apparmor confinement hook which I can experiment with and use to
> flesh out the hooks design/implementation, than for the security team to
> struggle to try to fit it into the current rough draft.)

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:

  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?

 - 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 as
   well as when updates to the ubuntu apparmor policy templates occur
   to fix whatever issues come along. But that's postinst handling
   on the apparmor side of things, not relevant to the click hook
   infrastructure itself.

[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.

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

-- 
Steve Beattie
<sbeattie@xxxxxxxxxx>
http://NxNW.org/~steve/

Attachment: signature.asc
Description: Digital signature