The MeeGo security framework

Several kernel security solutions that haven't been used very widely—at least visibly—are making an appearance in the Mobile Simplified Security Framework (MSSF). Elena Reshetova and Casey Schaufler of Nokia presented MSSF at the recently held MeeGo conference, and it will be the basis of the MeeGo security architecture. While MSSF is targeted at MeeGo, it is not necessarily specific to that platform and, since it is an open project that has expanded from its smartphone roots, it could be adopted by other platforms.

Reshetova opened the talk with a description of the components of MSSF, starting with the chipset security, which provides secure cryptographic and key management services that can be used by the higher levels. Integrity protection will ensure that the system software, applications, and data, are protected against both on-line and off-line attacks. The access control layer will limit the resources that applications can access at runtime, while the privacy protection layer protects both data integrity and confidentiality for applications.

MSSF relies on a secure software distribution model, where packages can be authenticated before being installed. A smartphone does not have an administrator, she said, so MSSF relies on secure software distribution for managing the security policy remotely. The security policies from the device maker and user are what determine which parts of MSSF are used and how they are utilized.

Version 1 of MSSF was presented at this year's Ottawa Linux Symposium, but it was designed for Maemo—one of the two precursors to MeeGo, Moblin being the other—and smartphones. It was designed to use Debian packages, but MeeGo is RPM-based. In addition, MSSF v1 needed more features to support the various MeeGo targets (netbook, connected TV, tablet, etc.), which led to MSSF v2 that will be delivered in MeeGo 1.2.

The chipset security layer "abstracts away the hardware" and provides a "trusted execution environment", Reshetova said. It provides services to the other layers in addition to verifying the integrity of the bootloader and kernel image prior to boot. There are two main keys used: a symmetric root device specific key that is used for local cryptographic operations and a root public key that is used to verify the software chain.

For access control, MSSF and applications define "protected resources", which are things like cellular functionality, location information, or calendar data that require access limitations. A new credential type has been created for MSSF called a "resource token", which is a "string that names the protected resource". There are both global tokens for system-provided resources (UserData, Cellular, Location) and package specific tokens (e.g. calendar data). Applications must declare which resource tokens they need or provide in the package manifest.

Smack for access control

Access control will be enforced using Smack (Simplified Mandatory Access Control Kernel), which is a mainline Linux security module (LSM) that was developed by Schaufler. Smack was added to Linux in April 2008, but hasn't been seen much outside of presentations and some secret embedded projects, so MeeGo will be the first highly visible user of this technology.

Schaufler described his reasons for developing Smack as a "reaction to SELinux", because of the complexity of that solution. Like SELinux, Smack provides mandatory access control (MAC), but does it in a much simpler way. "Mostly what it [Smack] does is to stay out of the way", he said. Smack is a complete MAC model, Schaufler said, and there is an implementation of resource tokens being added for MSSF v2.

Smack is based on the idea of labels on files, which are stored in the file's extended attributes (xattrs), and processes. In order for a program to access a file, those labels must match; if they are different then access is denied. That "doesn't work well for things like the root of the filesystem", Schaufler said, so there are two special Smack labels, "_" (floor) and "*" (star) that allow for wider access.

In addition, simple rules can be added to allow specific kinds of access between labels that don't match. Rules are specified with subject (access requester) and object labels along with the access allowed (based on the traditional read, write, execute permission bits). In order to write to an object, a subject must have both read and write permission; read permission is required to read the inode. Many operations require directory access (governed by the execute bit) as well.

Networking is handled differently from file access, he said. Sockets are not elements in the security model, and it is the labels on the two communicating tasks that govern access. A sender must have write access to the receiver's label in order to send it a packet. Writing without being able to read a response is "very useful in an environment where applications don't want to trust each other", he said. Packets get labeled by Smack, and processes can query the packet label to do different things based on that label.

The MeeGo package manager will be responsible for setting up the Smack configuration based on the package manifest. It will attach the Smack labels to the files, modify the stored Smack rules, and update those rules in the kernel. There is a "whole lot of information" that will need to go into the manifest, so it is something to be aware of when creating MeeGo packages, but it won't be too difficult to do, he said.

IMA and EVM

Two other lightly used kernel facilities are also part of MSSF: the integrity measurement architecture (IMA) and the extended verification module (EVM). Reshetova came back to the microphone to explain how those two facilities will be used.

IMA is being used, rather than the "validator" that was part of MSSF v1, because it is in the mainline and uses xattrs to store its reference hashes. Essentially, IMA keeps track of the contents of files by storing a hash value in their security.ima xattr. When files are opened, the integrity of their contents are verified, and IMA ensures that when the contents have changed, the reference hash is updated. In order to do that update, the access control framework (i.e. Smack) must allow that operation.

Binary program files are the main target for IMA checking, though libraries and data files can be protected as well. The MeeGo package manager will be responsible for setting the initial reference hash value based on information in the package. IMA only guards against attacks that change those files while the system is running, as off-line attackers can change both the file contents and hash value.

EVM is what provides protection against these off-line attacks. It stores a "keyed hash across the security attributes" of files. Those attributes include the IMA and Smack xattrs, as well as the owner, group, and permissions of the file. The key that is used comes from the chipset security layer, so that an off-line attacker cannot change any of those attributes (which effectively includes the file contents because the IMA xattr is included) without it being detected by EVM.

Reshetova also described the cryptographic services being offered to applications by MSSF. Applications that wish to protect the integrity or confidentiality of user data can call into libaegis-crypto (Aegis is a now-deprecated name for MSSF) to request certain security services like encryption or hashing. The library handles the interaction with the chipset security layer to create application-specific or shared keys that are never exported to user space. Applications can then request various operations by using a key identifier, rather than the key itself. By using EVM, user data can be protected even from off-line attacks.

Schaufler and Reshetova then fielded a few questions, the first of which was about the effect of IMA/EVM on boot speed. Schaufler said that they don't, yet, have measurements they are comfortable with, and Reshetova said that their earlier work with the validator found that there weren't major effects from integrity checking.

Another asked about who else was using Smack, and Schaufler was a bit cagey in his response, noting that there is one TV that you can buy which is using Smack, but that there are "some people that don't like to share" that kind of information. He also noted that "MeeGo adopting Smack is going to take it someplace special" but the adoption makes sense because Smack is "considerably more lightweight and easier to deal with than other leading brands".

While not specifically addressed in the presentation—though Ryan Ware touched on it briefly during his presentation immediately prior—is the complete system lockdown that MSSF could enable. Device makers can use the facilities to require that only their signed kernels run on the devices, and that only approved applications get installed. It remains to be seen how many MeeGo integrators make that choice. Device makers may well have chosen to do that regardless of whether MSSF supported it, but its presence there certainly makes it easier to create freedom-hostile devices. One hopes that at least some device makers choose otherwise.

---

(Log in to post comments)