[Dev] Some Tizen Platform Security Confusion
casey.schaufler at intel.com
Wed Aug 6 00:25:45 GMT 2014
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.
More information about the Dev