[Dev] enforcing priviliges of web apps

Kis, Zoltan zoltan.kis at intel.com
Wed May 14 15:26:57 GMT 2014


On Wed, May 14, 2014 at 5:34 PM, José Bollo
<jose.bollo at open.eurogiciel.org> wrote:
> On mer, 2014-05-14 at 17:16 +0300, Kis, Zoltan wrote:
>> On Wed, May 14, 2014 at 5:00 PM, José Bollo
>> <jose.bollo at open.eurogiciel.org> wrote:
>> > On mer, 2014-05-14 at 16:56 +0300, Kis, Zoltan wrote:
>> >> On Wed, May 14, 2014 at 3:50 PM, Lukasz Wojciechowski
>> >
>> >> > 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
>> >
>> > The problem is with accesses to the file system and other "filesystem
>> > named" objects: the Smack context will not be the one of the App. That
>> > is what explained Rafal.
>> >
>>
>> In this model, the extension process could check the app identity,
>> manifest, security policy,
>
> Yes it could
>
>>  and won't allow access to file system or
>> similar secured objects unless the app has permission for it.
>
> 1) how to know if an access to the file system is authorized? You should
> read the Smack labels of the accessed entity and check the Smack
> database using the application id. It's heavy but could work.

This part could come from a library that could be part of Cynara, right?
Also, the data needed for decisions could be deployed and synchronized
with the security server. It that way, the decision is local and no
IPC is needed, apart from eventual updates of the policy.

> Except
> with that corner case if a part of the filesystem can't be accessed by
> your process but could be by the application (ex: the app has context A
> and the browser that is checking has the context B, if the accessed item
> is under context I granted for A but not for B it doesn't work)

Again, we have a dynamic rule, which could be checked by the library
and enforced by the extension process.

>
> 2) when the browser creates an object in the filesystem, it gives him
> its context. In that case, how to distinguish the objects created by an
> application?

Files are created using an API. Checks would be done at the
implementation of that API. Is it simplistic/overlooking something?

> And how to avoid an other application to access the object
> of an other one? It is possible to achieve it using transmutation of
> labels. Is it always possible? I don't know.

Same origin policy. Accessing other apps objects has been extensively
discussed in W3C, it's mainly a matter of policy. We should only
develop the mechanism supporting that policy.

>
> Then it could work... At what cost?

Still less cost than a single security proxy for all, exposing new
API's (to be defined and standardized) to native/web apps.

Best regards,
Zoltan

>
> Best regards
> José
>
>> Similarly to the proposed security proxy.
>>
>> Then, by another model, the extension process (one per app/instance),
>> could inherit the app identity; then indeed security needs to be
>> enforced at lower layers, but then the smack context will be of the
>> app.
>>
>> Did I misunderstand something? :)
>>
>> Best regards,
>> Zoltan
>
>


More information about the Dev mailing list