[Dev] enforcing priviliges of web apps (was: Re: New Tizen Bluetooth Framwork (NTB) wiki page)
zoltan.kis at intel.com
Wed May 14 11:44:48 GMT 2014
Please let's move the security discussion from this thread (and
reference this discussion from there) to this one: 'Tizen 3 platform
On Wed, May 14, 2014 at 1:49 PM, Kis, Zoltan <zoltan.kis at intel.com> wrote:
> 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