[Dev] enforcing priviliges of web apps (was: Re: New Tizen Bluetooth Framwork (NTB) wiki page)

Patrick Ohly patrick.ohly at intel.com
Tue May 13 08:30:50 GMT 2014

On Mon, 2014-05-12 at 20:30 +0200, Dominig ar Foll (Intel OTC) wrote:
> Le 12/05/2014 16:51, Xu, Martin a écrit :
> > Hi:
> >> Does that mean for every API involved in the huge list on the page above we
> >> intend to create a new wrapping middleware component to add the security
> >> checks and other "added value"?
> > One of effort in NTB is to split the security checking out.
> > In fact, Samsung originally do that at the initial version of Bluetooth framework.
> > Later, after F2F meeting at Helsinki (Samsung, Comms upstream/Tizen, Smack team), we agree that that can be handle at Smack.
> >
> > Someone can educate me what is the security check here, thanks!
> As described in
>    https://www.tizen.org/privilege/tizen
> When an App is installed its privileges are stored in the privilege DB 
> (soon with the extra information: user only, or any user).
> When the App  is executed an request for a service, we need to enforce 
> the respect of the declared manifest.
> We cannot trust the App itself to enforce the respect of the manifest 
> and so the system must do it.
> Furthermore when moving from the legacy WRT to Crosswalk, we benefit of 
> an optimisation, having a single Web process for all App, which would 
> have made the enforcement via Smack even more complex than in Tizen 2.2.

I understand and agree that the system needs to enforce privileges. But
if all Web apps run in the same Crosswalk process, doesn't that force
Crosswalk to become a trusted part of the system?

It can't delegate the enforcement to the rest of the system, because
that rest will just see one process making various requests, without
being able to tell on behalf of which app that request was made.

Cynara as discussed so far on this list does not cover this. From

        Service asking Cynara for a check of privilege must pass an
        application context as one of arguments. This context is build
              * UID - id of user running an application;
              * SMACK label - for identifying application itself.

D-Bus has a mechanism to retrieve both for the caller. It doesn't have
something for "faking" the context so that it matches a certain web app.

Even if we had some fictitious alternative IPC mechanism for sending
requests from Crosswalk to the system, the core problem remains:
Crosswalk cannot just call a method "do_something(x,y,z)" where x/y/z
are parameters of this method on the system side. Instead Crosswalk must
also pass some kind of app ID.

Either that, or do the enforcement internally before it calls the
system. The system then must be configured such that Crosswalk can do
anything that any app might be allowed to do. This option is perhaps a
bit less secure than trusting Crosswalk to pass the right app ID, but
not much.

In both cases Crosswalk must be trusted.

Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

More information about the Dev mailing list