ubuntu-appstore-developers team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 13-07-17 12:55 PM, 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:
>>> 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.

Except now we have to parse multiple json files and correlate the information we
need. For example, we find myapp.json. We now need to parse manifest.json to
figure out that myapp.json maps to the binary called "myapp", that the version
is "0.1", that the desktop file is "myapp.desktop", etc. It seems to me this is
overly complicated.

We also need a global security section somewhere, so we're going to need a
security section in manifest.json anyway.


  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.

I don't understand this part. What exactly is creating the symlinks? Is this
just for tracking which profiles have been generated already?

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

We need to have a checklist which we manually go through when the app gets
uploaded. At some point, this will be automated.

Marc.