ubuntu-appstore-developers team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 07/18/2013 09:47 AM, Marc Deslauriers wrote:
> 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:

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

> 
>  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 don't know of one. I'm not sure what that would look like either-- it would
need to be a trusted helper and I guess it would be a contextual prompt, like
with online accounts, but there is a lot to discuss there both in terms of
usability and security.

>>
>> 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.
> 
Point taken, but it may still be something we want to support (perhaps for
legacy apps or other things I've not thought of).

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

Yeah, it has been expressed elsewhere that other parts of the system won't
support multiple desktop files in 13.10 anyway, but I'll add something to our
bps so this is tracked going forward.


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

Attachment: signature.asc
Description: OpenPGP digital signature