[Dev] Some Tizen Platform Security Confusion
Dominig ar Foll (Intel OTC)
dominig.arfoll at fridu.net
Wed Aug 6 08:18:51 GMT 2014
it must also be noticed that services which need to protect conflict to
resources access induced by multi user and were expecting to get that
protection (not directly related to security) handle at the SAPI demon
need now to provide that protection by themselves and that will not be
possible to add in the dbus server.
In that case the conflict protection will have to be included in a
Example would for example to restrict pairing of a phone to the user who
did it but accept to share the pairing of a remote control.
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Le 06/08/2014 02:25, Schaufler, Casey a écrit :
> 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
> 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.
> Dev mailing list
> Dev at lists.tizen.org
More information about the Dev