ubuntu-appstore-developers team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 07/17/2013 08:01 AM, Colin Watson wrote:
> On Tue, Jul 16, 2013 at 05:16:44AM -0700, Steve Beattie wrote:
> 
...
> 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.
> 
This is actually quite important for performance reasons-- needlessly
regenerating profiles on ARM, while not particularly heavyweight with our
current policy, is something we want to avoid.

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

I couldn't find dh_click, where is this? Steve, I'm guessing we would update
apparmor-easyprof-ubuntu to use this, though now I'm thinking that we may not
need to. Because the click profiles are stored somewhere other than
/etc/apparmor.d, then we can have postinst just regenerate them all
unconditionally. Eventually, we could possibly build smarts into what postinst
does and possibly regenerate only those that are needed (eg, all if the template
is changed, only those with networking defined as a policygroup is the
networking policygroup changed). That would take some thought.

>> [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.
>
Do we have a location defined where we can store such things? We'll need to
adjust our apparmor boot script to load profiles from here as well.

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

This is the bit that we need to make sure we are all are all in agreement on
(click, application confinement, application lifecycle). We have in our docs[1]
the following: "Because we then need versioned profile names and filenames for
the profiles, the AppArmor click hook will generate a versioned profile name in
the form of: $name_$application_$version". Considering the following json snippet:

   "name": "com.ubuntu.developer.username.myapp",
   "version": "0.1",
   ...
   "security": {
     "profiles": {
       "myapp": {
         ...
       },
       "myapp-camera": {
         ...
       }
     }

we generate the profile names to be:
 * com.ubuntu.developer.username.myapp_myapp_0.1
 * com.ubuntu.developer.username.myapp_myapp-camera_0.1

As such, for utmost clarity, your PACKAGE_KEY_VERSION == our
$name_$application_$version such that PACKAGE is the "name" from the manifest
and VERSION is the "version" in the manifest? I guess the bit you are fleshing
out is how KEY is defined-- in my example json, are "myapp" and "myapp-camera"
keys for the security profiles dictionary?

[1]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest#Click


-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature