Please let's move the security discussion from this thread (and reference this discussion from there) to this one: 'Tizen 3 platform security overview.' https://lists.tizen.org/pipermail/dev/2014-May/002699.html
Thanks, Zoltan On Wed, May 14, 2014 at 1:49 PM, Kis, Zoltan <[email protected]> wrote: > 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
