There appears to be some confusion about the current plan for enforcing application level privilege in Tizen 3. After investing serious consideration in the Service API (SAPI) scheme it became clear that instead of reducing effort, cost and risk there was a real possibility that it would do just the opposite. The services that could use the mechanism were proving more complex, and there proved to be fewer of them than originally anticipated. SAPI eligible services seem to be the exception rather than the rule.
One of the most important observations from the effort is that dbus is very heavily used by the Tizen system services. We are taking advantage of this dependence on dbus by integrating Tizen application privilege processing in dbus. In most cases services that already use dbus will be able to support the Tizen application privilege model using proper dbus configuration. The Cynara team is working closely with the dbus maintainers. The service applications that provide protected application resources that do not use dbus may seem to have a tougher row to hoe without SAPI, but that is actually not the case. The access checks that are the responsibility of the service would have had to have gone into the service daemon and the protocols emulated. The current plan is to use dbus configuration where convenient and add access checks (Cynara) to services that do not use dbus. There may be cases where an intermediate process, much like the service daemon was intended to be, is the most prudent approach. Our expectation is that the overhead and complexity of a "man in the middle" will be sufficient to demonstrate the wisdom of changing the service programs instead. As always, the Intel and Samsung security teams are more than happy to help work out how best to address the unique and critical needs of the service programs you are working with. Thank you. _______________________________________________ IVI mailing list IVI@lists.tizen.org https://lists.tizen.org/listinfo/ivi
