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

Kis, Zoltan zoltan.kis at intel.com
Wed May 14 10:49:39 GMT 2014

On Wed, May 14, 2014 at 12:32 PM, Patrick Ohly <patrick.ohly at intel.com> wrote:
> On Wed, 2014-05-14 at 11:15 +0200, José Bollo wrote:
>> IMHO, this solution is costly: time to do it, time to maintain it, time
>> to make it accepted upstream, dependency of DBus to cynara, the
>> configuration process isn't obvious.
> On the other hand, it only needs to be done once, and probably is more
> secure than relying on D-Bus service implementers to do the right thing
> in their code.

Also, it is still an order or magnitude simpler than doing a 'mother
of all APIs' wrapper.

>> It also have the drawback to be DBus specific, letting part of the world
>> outside of the scope.
> True, non-D-Bus still needs a solution. But that is a separate issue.

I have covered that in the proposal, that is why one enforcement point
could be the service proxy as proposed by Dominig (for non-DBUS,
mainly legacy interfaces). Again, the proposal is to consider:
- multiple security enforcement points, such as the dbus-daemon,
crosswalk/extension processes, security proxy
- a library collecting the runtime check code, loaded by the enforcement points
- a mechanism to have security policy data available locally to the
enforcement points and updated/sync'd with Cynara.

- works out of the box with native apps using DBUS, just add manifest
- much simpler then doing the full API wrapper, therefore faster time to market
- better performance/smaller latency for DBUS services than with the
security proxy, which is an important aspect
- more secure and more robust than doing the checks in the processes
providing DBUS services
- still has the security proxy in the picture, making it flexible and
- eventual transition to single-proxy much smoother.

Disadvantages vs the single proxy model:
- more than one enforcement points; extra code reviews on those
- the need to package (and design) the runtime checking code as
library to be used by enforcement points
- the need for a mechanism to deploy/sync policy data to the
enforcement points for the runtime checks.
Most of this seems quite controllable effort to me.

I suggest we should explore/discuss this, as it is still the
smoothest/fastest path, not excluding sole use of either option in the
future, or configurations which use only one enforcement point or

Best regards,

More information about the Dev mailing list