[Dev] enforcing priviliges of web apps (was: Re: New Tizen Bluetooth Framwork (NTB) wiki page)
jose.bollo at open.eurogiciel.org
Tue May 13 08:49:41 GMT 2014
On mar, 2014-05-13 at 10:30 +0200, Patrick Ohly wrote:
> 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?
The process model of Crosswalk is more complicated: IIRC, for one
application, 2 processes are launched. The launcher (aul, aul-ng) will
take care to set good ids and context to these processes.
But anyway, you are right, we have to trust crosswalk because it is
providing native standard API that must be checked against privileges.
> 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.
right but is it needed?
> 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.
(*) Are native apps to be supported? The answer seems to depend on the
people you are asking. For me the answer is yes because it is harder to
More information about the Dev