ubuntu-appstore-developers team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 07/18/2013 08:36 AM, Marc Deslauriers wrote:
> On 13-07-17 12:55 PM, Colin Watson wrote:
>> 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"
>>       }
>>     }
>>   }
>>
> 
> One thing that is still a bit unclear to me: do we have any way of knowing what
> the binaries will be called for each app? Is "myapp" and "myapp-camera" the
> actual names of the binaries that are going to be in the package? What about
> html apps that will use the main "viewer" app?
> 
> In theory, this shouldn't pose a problem for our AppArmor confinement, as our
> profile will simply apply to all the binaries in the directory, and the
> appropriate profile will get switched to by the upstart job. But, what happens
> if myapp spawns myapp-camera directly? Should we prevent an app from directly
> spawning another binary in the same package, forcing it to use some system API
> to do it instead?
> 

This is not currently covered and actually leads to a bigger question of how
apps are supposed to be able to execute other applications (eg, click a link in
the app and open a browser), which is something I've been meaning to bring up on
another list.

But for your specific question, as mentioned, myapp is launched by an upstart
job and is thus running under confinement. Current template policy for myapp
allows it to execute anything within its install directory with 'ix' (once the
various SDK bugs are fixed for having application-specific writable directories
are solved, we can do the same for the writable directories to support
downloadable addons, etc). This means if myapp spawns myapp-camera directly, it
inherits myapp's policy. We can't use 'pix' because myapp-camera could be
interpreted and so we don't get correct path attachment. We can't have it use
the upstart job, because then it could launch anything (and we don't currently
have a way to limit that). Same goes for the desktop file.

I think the path forward is that we should allow for myapp to change_profile via
aa-exec/libapparmor. In AppArmor we have the ability to specify what profiles a
process can change_profile into. Eg, if myapp had the following rules (don't get
hung up on the perl abstraction, we will have an ELF aa-exec before we do
anything like this):

@{APP_PROFILE}="com.ubuntu.developer.username.myapp_myapp-camera_0.1"
profile "com.ubuntu.developer.username.myapp_myapp_0.1" {
  ...
  /usr/sbin/aa-exec ixr,
  #include <abstractions/perl>
  owner @{PROC}/@{MYPID}/attr/exec w,
  change_profile -> @{APP_PROFILE},
}

then myapp could do:
$ aa-exec -p com.ubuntu.developer.username.myapp_myapp-camera_0.1 -- ...

but could not do any of these:
$ aa-exec -p unconfined -- ...
$ aa-exec -p /usr/sbin/cupsd -- ...

There is *lots* to discuss here though, like how to express this in the click
manifest, in the easyprof arguments, how to adjust aa-clicktool, how to
autodetect abuse, how to implement the @{MYPID} kernel variable, how to express
this in policy (eg, in addition to the above, we may also need to exec
qmlscene), making this easier for developers, etc, etc. I think for now we
should simply state that executing an app that you supply directly is not
supported at this time, but it is something we plan to add in the future.


-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature