ubuntu-appstore-developers team mailing list archive

[Steve Beattie <steve.beattie@xxxxxxxxxxxxx>]

On Wed, Jul 17, 2013 at 05:55:17PM +0100, Colin Watson wrote:
> On Wed, Jul 17, 2013 at 08:55:10AM -0500, Jamie Strandboge wrote:
> > On 07/17/2013 08:01 AM, Colin Watson wrote:
> > >  * 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.

Ah, if nothing else, the PACKAGE_KEY_VERSION %s substitution is an
improvement over what I had initially (mis-?)interpreted the click
documentation to indicate, that the symlink would only contain the
top level PACKAGE name, which would be a symlink to the top level
package directory, wherein I then believed the hook would need to
walk the different versions beneath that.

> It's also occurred to me that, really, I've been talking about hooks the
> wrong way up for the multi-application case.  We don't have a set of
> hooks each of which can be applied to several applications; we have a
> set of applications which can make use of several hooks.  This becomes
> obvious when you think about what the current design would require for
> the common case of a single-app package with an AppArmor profile and a
> desktop file:
> 
>   "security": {
>     "profiles": {
>       "myapp": {
>         ...
>       }
>     }
>   }
>   "hooks": {
>     "desktop": {
>       "myapp": "myapp.desktop"
>     }
>   }
> 
> The duplication is clear, and it gets worse the more hooks you use.
> This means that it ought to be the other way up; and to get rid of the
> duplication entirely we need to be considering AppArmor profiles as more
> like other hooks.

I agree, in that these things are really attributes of the
applications: the security policy, the desktop file, etc.

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

[One nice feature about this scheme from the apparmor perspective
 is that if the package is for something like the ubuntu-terminal
 where it's not really acceptable for it to be confined by apparmor,
 the manifest can just not provide the hook entry, rather than
 using the somewhat hacky 'unconfined' template like we do now.
 Manual/automated inspection of manifests can red-flag those, to
 detect app authors who try to do this. Similarly, secondary apps
 that don't need/provide desktop files just won't provide that entry.]

> The one remaining non-generic thing here is as follows: my understanding
> is that for 13.10 the server is not going to have any facilities for
> scanning apps for problems and rejecting them.  This means that, IMO, we
> need to reject such things at the client end.  But that at least is a
> relatively small amount of code.

What would a hook be expected to do to reject it, without causing
the install to fail?

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

Attachment: signature.asc
Description: Digital signature