ubuntu-appstore-developers team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 13-07-18 02:01 AM, Steve Beattie wrote:
> On Wed, Jul 17, 2013 at 02:36:42PM -0700, Steve Beattie wrote:
>> On Wed, Jul 17, 2013 at 05:55:17PM +0100, Colin Watson wrote:
>>> So, I know it's annoyingly late to be asking for this, but would it be
>>> at all feasible to refactor the security manifest format to fit into a
>>> more general system?  What I'm thinking of is this:
>>>
>>> manifest.json:
>>>
>>>   {
>>>     "name": "com.ubuntu.developer.username.myapp",
>>>     "version": "0.1",
>>>     ...
>>>     "hooks": {
>>>       "myapp": {
>>>         "apparmor": "apparmor/myapp.json",
>>>         "desktop": "myapp.desktop"
>>>       },
>>>       "myapp-camera": {
>>>         "apparmor": "apparmor/myapp-camera.json",
>>>         "desktop": "myapp-camera.desktop"
>>>       }
>>>     }
>>>   }
>>>
>>> apparmor/myapp.json:
>>>
>>>   {
>>>     "policy_groups": [
>>>       "networking"
>>>     ],
>>>     "policy_version": 1.0
>>>   }
>>>
>>> apparmor/myapp-camera.json:
>>>
>>>   {
>>>     "policy_groups": [
>>>       "camera",
>>>       "location"
>>>     ],
>>>     "policy_version": 1.0
>>>   }
>>>
>>> (You could use a non-JSON format for the profiles if that's more
>>> convenient.)
>>>
>>> I like this layout a lot better: it actually makes some kind of sense to
>>> me, it's easier to read, and it repeats itself less.  Furthermore, this
>>> way, click's hook execution can be almost entirely general: in this
>>> case, it would create symlinks in /some/apparmor/cache/directory/ named
>>> com.ubuntu.developer.username.myapp_myapp_0.1.json and
>>> com.ubuntu.developer.username.myapp_myapp-camera_0.1.json, each of which
>>> contains just the profile declaration for a single application, and
>>> something like click-apparmor can walk that directory for changes and
>>> generate and load profiles.
>>
>> This scheme looks good, as long as we can use the symlink name to pull
>> out the package, key, and version, as they won't be repeated within
>> the apparmor JSON files. (And keeping JSON for the sub-entries is
>> fine for our use.)
>>
>> The only situation I can see where this would be problematic is
>> if global level information was added to the manifest format that
>> hooks might need or be interested in, or information that multiple
>> hooks might want to know. For example, earlier you had proposed
>> alternate install locations than /opt/click.ubuntu.com/ for things
>> like vendor/carrier installed applications. The apparmor hook would
>> want exposure to this somehow, but having the author/sdk repeat this
>> information both at a global level and within the security json
>> for each application within the package would potentially lead to
>> inconsistencies.
>>
>> That in fact is why the apparmor hook would be parsing apart the
>> symlink name, as it encapsulates the global information from the
>> manifest that apparmor is interested in.
> 
> To clarify for the record, while (in the existing scheme) we build the
> apparmor policy out of the PACKAGE, KEY, and VERSION elements combined
> in the same way as the hook symlink is constructed, we make use of
> the individual elements (namely PACKAGE and VERSION) as part of path
> elements in the generated apparmor policy (for example, the ability to
> read files underneath /opt/click.ubuntu.com/PACKAGE/VERSION/ as well
> as for application data storage locations in users' home directories).
> 
> Upon reflection, one thing I noticed that apparmor and other system
> hooks would lose from direct access to the manifest would be the
> contents of the Framework; field. I'm not sure how significant of a
> loss this is... for apparmor, we do encode a policy version field in
> the security structure in an attempt to cope with future iterations
> of templates, course-grained permissions, etc. and still have older
> applications/versions install and work unchanged.
> 

Yes, we are going to have to parse the manifest.json file each time we parse the
apparmor-specific json files.

Marc.