ubuntu-appstore-developers team mailing list archive

[Colin Watson <cjwatson@xxxxxxxxxx>]

On Wed, Jul 17, 2013 at 08:55:10AM -0500, Jamie Strandboge wrote:
> On 07/17/2013 08:01 AM, Colin Watson wrote:
> > On Tue, Jul 16, 2013 at 05:16:44AM -0700, Steve Beattie wrote:
> >>  - 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?

It's in click-dev.

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

I'm not sure.  Perhaps Stéphane Graber can advise.

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

Exactly - we have trivial differences in naming, but the semantics
match.

The only mismatch I see is that in general I'm using a "hooks" manifest
subtree, so it'll look something like:

  "hooks": {
    "desktop": {
      "phone": "phone.desktop",
      "video-chat": "video-chat.desktop",
    }
  }

Now, this doesn't quite match up with your "security"/"profiles"
subtree.  Perhaps I could just hardcode that as a separate manifest
subtree that's handled in a somewhat similar way to hooks.  That still
leaves the question of how to hand off the per-app manifest subtrees to
apparmor.  Steve's prototype does this by parsing the whole manifest and
finding the sections it wants.  This works, but it's all very specific
to this application and I'm trying to make hooks as general as I can if
possible so that I won't need to do so much random hacking around later.

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.

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.

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 do you think?  I know this is late, but I think it is better.

Thanks,

-- 
Colin Watson                                       [cjwatson@xxxxxxxxxx]