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
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
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
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
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
to post comments)