[Dev] enforcing priviliges of web apps

Rafał Krypa r.krypa at samsung.com
Thu May 15 16:24:48 GMT 2014

On 2014-05-15 11:59, Kis, Zoltan wrote:
> Here we have options.
> A. Security (service) proxy is the only enforcement point. Dominig's proposal.
> In this case the EP is totally transparent and inherits the app identity.
> We need to solve how the browser process will know to pop up a user
> dialog for permissions.
> Also, all API's that are accessed by the web runtime need to be
> exposed by the service proxy, which is a huge work with huge delay.
> B. There may be multiple enforcement points (EP, dbus-daemon,
> service-proxy). This allows direct DBUS access from apps, and in the
> rest works like in A. Sub-options:
> 1.) EP is also enforcement point, and part of the system. Then, EP
> checks if access is allowed, either by
> a) asking Cynara, or
> b) EP caches policy data from Cynara (with an update/sync mechanism
> for that data) and makes a local decision, which is much faster than
> a).
> 2.) EP is not an enforcement point (only dbus-daemon and service-proxy
> are). Then it works like in A, but EP would have direct access to DBUS
> API's, making the transition much easier, and the work much lighter
> than in A.
> In either case, you can reuse the upper part of your design.
> Currently only A. is a proposal, although B. is forming up to be a
> proposal, too.
> The issue is still debated in the architecture forum, but IMO it would
> be enough if security experts would analyze both, publish it here, and
> select one of them (A, B1a, B1b, or B2). So far the analysis part is
> not clear (except for A). Personally, I would be fine with either B1b
> or B2.

If EP is going to be an actual process making the access to protected resources and services then I don't think it's a good point for enforcement. If I understood correctly, there will be one EP per application and it will run with user's UID and application's Smack label. In such case I would vote
for option B2. Option B1 doesn't protect against applications hijacking their EPs and running malicious code in it, bypassing the enforcement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20140515/a32d6a6c/attachment.html>

More information about the Dev mailing list