On Wed, May 14, 2014 at 12:32 PM, Patrick Ohly <[email protected]> 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
