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 https://wiki.tizen.org/wiki/Security:Cynara:ApplicationCredentials: Service asking Cynara for a check of privilege must pass an application context as one of arguments. This context is build with: * 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. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
