[Dev] enforcing priviliges of web apps

Kis, Zoltan zoltan.kis at intel.com
Wed May 14 13:56:22 GMT 2014


On Wed, May 14, 2014 at 3:50 PM, Lukasz Wojciechowski
<l.wojciechow at partner.samsung.com> wrote:
>
> W dniu 2014-05-14 07:43, Zhang, Xu U pisze:
>
>>
>>> -----Original Message-----
>>> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Patrick Ohly
>>> Sent: Tuesday, May 13, 2014 10:29 PM
>>> To: José Bollo
>>> Cc: dev at lists.tizen.org
>>> Subject: Re: [Dev] enforcing priviliges of web apps
>>>
>>> On Tue, 2014-05-13 at 16:09 +0200, José Bollo wrote:
>>>>
>>>> On mar, 2014-05-13 at 15:59 +0200, Rafał Krypa wrote:
>>>>>
>>>>> On 2014-05-13 14:29, Patrick Ohly wrote:
>>>>>>
>>>>>> On Tue, 2014-05-13 at 11:13 +0000, Counihan, Tom wrote:
>>>>>>>
>>>>>>> I will end up with a total count of 1 browser process and 4
>>>>>>> other processes (2x extension & renderer) = 5 processes?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Is this correct?
>>>>>>
>>>>>> And to extend the question, which process will be the one talking
>>>>>> to the rest of the system services?
>>>
>>> [...]
>>>
>>>> I agree with you. There is a problem. Is was thinking that the W3C API
>>>> was handled at the renderer process level. Having it common to all
>>>> apps is a problem for the reasons you written.
>>>
>>> Note that my question about "which process talks to services" (or, in a
>>> similar
>>> vain, accesses files) has not been answered yet. It might still be the
>>> per-app
>>> render process which does it.
>>
>> [Zhang Xu ] Tizen extension APIs will be implemented in extension process.
>> So extension process in crosswalk will talk to service.
>> For W3C APIs, it is up to how system implements W3C API module. For W3C
>> APIs other than Tizen extension APIs in crosswalk, the process which
>> implements the module follows the design of chromium. In chromium, the
>> render process will send IPC message to browser process firstly. And browser
>> process will talk to the service to get the result. Then browser process
>> will transfer the result to render process.

That is for internal extensions.
Tizen API's (and W3C API implementations in Tizen) are external
extensions to crosswalk.

>
> If we follow such design all calls to services will be made by browser
> process and not by application process. It means that services won't be able
> to provide application granularity access control because all calls will be
> made with SMACK label of browser.
> It is a problem.

Except if the browser / extension process become security enforcement
points, doing the runtime checks.  Since they are different processes
than the the one running the app, they could load a library
implementing the runtime security checks and enforce permission. Of
course then the platform becomes as secure as the browser... but
Chromium security is rather high.

Best regards,
Zoltan


More information about the Dev mailing list