Tizen's new access-control broker "Cynara"

Like all computing platforms that allow users to install arbitrary applications, the Tizen project has expended considerable effort designing its security framework. At the 2014 Tizen Developer Conference (TDC), Casey Schaufler and Tomasz Świerczek presented a talk on the latest iteration of Tizen's application-security design, which introduces a privilege-checking service called Cynara.

The fundamental problem that Tizen faces in application security, Schaufler said, is that privileges are specified (in documents like the W3C APIs that Tizen supports for app development) with respect to abstract services, such as "telephony," rather than with respect to system components, such as network devices. All security policies attempt to bridge this gap by writing set of rules and exceptions that map the abstracts onto specific devices and filesystem locations.

In Tizen 2.x, he explained, the system's security policy was written as a set of Smack rules that attempted to isolate individual applications from each other by creating a separate Smack domain for each installed application. Each app package includes a manifest file detailing the files and directories it creates, and the API privileges it requests. At install time, the system's package manager would read the manifest, create a domain for the new app, and assign a Smack label for that domain to each file and directory installed. It would also compute the new Smack rules that correspond to the new app's combination of privileges and its Smack domain, and add those rules to the system Smack policy.

The problem is that this level of granularity resulted in a huge policy database that was difficult to maintain. "It was almost as big as an SELinux policy," Schaufler said; "I had to go apologize to people at the Security Summit." The upcoming Tizen 3.0 changes things dramatically, however—starting with a simplified, three-domain policy model, which puts all installed apps at one basic privilege level, the "User" domain. It also defines a "Floor" domain for static system data that will not change and a "System" domain for basic system services. This model defines a well-known set of Smack rules (such as allowing all processes to access /tmp and /dev/null) that do not need to be appended to for every installed app.

The Tizen security team decided to revisit how the app privilege framework was implemented as well, so it held a "policy-off" face-to-face meeting at which representatives from Intel and Samsung offices each presented their ideas. When the two offices presented essentially the same design, they decided to move forward with it.

The centerpiece of the new plan is a policy "service" called Cynara. Each installed app is still assigned its own unique Smack label (to protect its private files and directories), but rather than creating a new set of Smack rules and exceptions for each privilege an app requests, Cynara creates a shorter record of the label and its privileges. The complicated mapping between the set of available privileges and the system's resources is created beforehand and is implemented in the Smack rule set, but does not grow for every new app.

When a running app requests access to a system component (for example, the current geolocation reading), the component sends a cynara_check() query to Cynara, including the app's Smack label, the user ID that the app is running as, and the name of the privilege the app is requesting. The Cynara service returns either ALLOW or DENY, based on whether the policy database indicates that the combination of Smack label and privilege are allowed. Other return values are also supported, the speakers said, such as "Ask the user," but the essence is that a straightforward yes-or-no question is answered.

Thus, the Cynara API is quite simple, but the real benefits come by maintaining the simpler database of allowed privileges. In performance testing, Świerczek said, the average response time was under 10ms, as opposed to more than 30ms for some of the alternative solutions they explored—such as PolKit. He also noted that PolKit performance suffers due to some design decisions, such as its use of D-Bus for communication and its use of JSON and XML to store the policy database. That database format meant that the entire policy had to be read and parsed for every call; Cynara, in contrast, stores its database in SQLite.

The two then described the current state of Cynara development and outlined a rough roadmap. The core privilege-checking library is operational, they said, but is not yet working as a full-fledged service. That milestone would likely be reached by the end of June, as would the utilities for updating the policy database. The essential tools necessary for deployment should be in place by the end of July, after which the team would work on adding an asynchronous privilege-checking API and a mechanism for adding extensions to the system's security policy.

There were several questions from the audience, many of which concerned how Tizen uses Smack labels. For example, one audience member asked whether there was a possibility that two apps could accidentally or maliciously get assigned the same Smack labels when installed—which would cause several security problems. Schaufler explained that apps do not choose or assign their own Smack labels; the package manager does. In the Tizen 2.2 release, the Smack label is created from the app's cryptographic signature, so it is guaranteed to be unique (barring collisions, of course).

Perhaps the most difficult aspect of the system to grasp in a 40-minute conference talk is how the Cynara approach to storing security privileges compares in real-world terms to the older Tizen approach of storing a longer, more convoluted set of Smack rules. Unfortunately, time makes it difficult to compare the approaches in detail, but the real-world test will have to wait for the deployment of actual apps—some of which, no doubt, will test the security framework in ways its creators have not yet contemplated. Cynara, however, promises a simpler way to keep track of privileges and access-control rules, so hopefully it will also make it simpler to catch—and fix—problems.

[The author would like to thank the Tizen Association for travel assistance to attend TDC 2014.]