Talking Smack for Tizen security

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing.

At the 2013 Tizen Developer Conference (TDC) in San Francisco, several sessions dealt with the challenges of implementing security on mobile phones and other consumer electronics devices. Among the security sessions, Casey Schaufler and Michael Demeter described their work applying Smack to Tizen, including the effort required to develop a sensible set of security domains that are not too complicated to maintain.

Bringing the Smack down

Schaufler and Demeter presented a session that can only be described as part talk, part vaudeville act—complete with props, audience participation, and Three Stooges clips. They began with a brief overview of Smack itself, but quickly moved on to how it should be used; that is, how application developers should determine what sorts of Smack rules their code needs. They also discussed the difficulty of finding the right system-level policies for a platform like Tizen, and presented case studies comparing two approaches—including the one they officially adopted.

Smack implements mandatory access control, they explained, starting with the basic rule "what's mine is mine; what's yours is yours." That rule, of course, means that no processes can talk to each other, so working with Smack in practice is a matter of defining the right exceptions to that basic premise, which are known as Smack rules. Each Smack rule grants one "access mode" to an object to a particular outside party. To illustrate the key exceptions needed by applications, Schaufler and Demeter went through a series of Abbott and Costello–esque routines mimicking processes trying (usually unsuccessfully) to share data via a notebook, while arguing about what permissions were needed. They then pulled a volunteer from the audience on stage, and mimicked processes trying to exchange packets by tossing rubber balls from one side of the stage to the other.

For example, Schaufler would announce that he had write access to send a packet to the audience member on the other end of the stage, then throw the ball, at which point Demeter would shout "Smack!" and slap it to the crowd mid-flight, explaining that the audience member also needed read access in order for the packet to be delivered. With read and write permissions for files and network message-passing thus artfully explained, the two moved on to the problem of granularity in Smack rule sets, which they illustrated with an attempt to build a tower out of dice.

The issue is that the Smack identifiers used to distinguish "mine" and "yours" in Smack are simple text labels, and generally the identifier used is chosen to be the same as the name of the application's main process. In Tizen, they explained, installable HTML5 applications declare their Smack identifier in their .manifest file. The Tizen application installer is a privileged process, and sets up the Smack identifier when it installs the app. The manifest essentially allows each application to create its own unique Smack domain. But that approach quickly becomes unworkable because using a domain for every application means each application must specify Smack rules for every other application on the system—or, at least, the sheer number of Smack rules can grow that fast. Too many rules to manage means more mistakes, and more resources used up on the system.

However, Schaufler explained, there are about a dozen different definitions of what a "security domain" is, so trying to reduce the number of Smack rules by grouping applications and services into fewer domains is not trivial. They described a "case study" of an unnamed mobile OS that used the one-domain-per-app model (an approach which had previously been announced as the plan for Tizen). In that "naive" setup, just 600 applications generated more than 20,000 Smack rules. Furthermore, there were numerous rules in the rule set that were obviously bad (such as apps that wanted write access to the system clock). And, by and large, the huge corpus of rules simply sketched out an "everybody shares with everybody else" platform, which is functionally equivalent to not having the one-domain-per-app configuration, but is unmaintainable.

Less is more

Considering these results, eventually the Tizen security team decided to reducing the granularity of the Smack configuration problem as much as possible, primarily by putting all end-user apps into a single security domain—by default, though individual apps can still create a domain of their own if necessary.

The concept stratifies the system into three levels. The lowest is called the "floor" domain, which includes those filesystem locations that every process must have read access to: /, /dev/, /bin/sh, system libraries, and so on; read-only access is available to all applications. Above "floor" sits the "system" domain, which is reserved for system processes like systemd, D-Bus, and DNS, which need read/write access to platform resources. The "application" domain sits at level furthest from the floor; by default all apps belong to this domain and can exchange messages and files. It is possible that the team will add another domain specifically for telephony apps, they said, but they are being cautious about any such expansions. The three-tiered system still requires a set of Smack rules to define access to "system" domain items; there will just be fewer of them required.

Any application can still declare its own Smack domain, so those applications that need to protect data (such as a password storage app) can do so. The decision to lump all end-user apps into one domain shifts more of the responsibility for protecting the device onto the maintainers of the application store. Defining how any device vendor implements its store is out of scope for Tizen itself, although the project does discuss many of the angles in its documentation. The most common scenario is expected to be an app creating a domain of its own (and listing the access rules for other apps); related apps can share a single Smack domain, with reviewers at the vendor's application store testing submissions to find apps that ask for questionable access.

The upcoming Tizen 3.0 release will be the first implement the three-domain system, and will include a base set of Smack rules. The Tizen 2.1 release used much finer granularity; its rule set contains 41,000 access rules. At this point the focus is on making the default rule set "more correct," with "smaller" still to come, but it is already considerably smaller and easier to understand than the competition. Schaufler and Demeter said that while Tizen 2.1's Smack rule set contained 41,000 rules, the SELinux reference policy is over 900,000 lines.

[The author wishes to thank the Linux Foundation for travel assistance to Tizen Dev Con.]