ubuntu-appstore-developers team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

On 13-07-18 10:29 AM, Jamie Strandboge wrote:
> 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.

Oh, that's no good. myapp could have a completely different policy than
myapp-camera, which would result in either myapp-camera failing to work, or
running with an inadequate 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.

If we don't already have one, I think we need a dbus API that would allow an app
to spawn another. I think we should block apps from directly execing stuff in
it's own directory.

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

This is problematic, as now it has been started outside of an upstart job, which
prevents it from being tracked properly, etc. I think we should just block it.

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

Yes, I think blocking exec is the most sane option for now.

Marc.