[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.

Advantages:
- 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
future-proof
- 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
multiple.

Best regards,
Zoltan


More information about the Dev mailing list