ubuntu-appstore-developers team mailing list archive

[Steve Beattie <steve.beattie@xxxxxxxxxxxxx>]

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.

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

Attachment: signature.asc
Description: Digital signature