Security
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.
Brief items
Security quotes of the week
EFF Tool Offers New Protection Against 'Firesheep'
The Electronic Frontier Foundation (EFF) has launched a new version of HTTPS Everywhere. "This new version of HTTPS Everywhere responds to growing concerns about website vulnerability in the wake of Firesheep, an attack tool that could enable an eavesdropper on a network to take over another user's web accounts -- on social networking sites or webmail systems, for example -- if the browser's connection to the web application either does not use cryptography or does not use it thoroughly enough."
Freedesktop.org shenanigans
Subscribers to the xorg-devel list will have seen Luc Verhaegen's November 23 note complaining about a prank commit added to the (moribund) radeonhd tree. As he rightly noted, this kind of trick (which required root access to carry out) can only serve to compromise the community's trust in the X.org project's repositories as a whole. After some hours, the perpetrator came forward; it was, as expected, an X.org developer. So there is no remaining concern that X.org's systems may have been compromised, but we may see a new discussion on how the organization's systems are managed in the future.
New vulnerabilities
php: double free flaw
| Package(s): | php | CVE #(s): | CVE-2010-4150 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | November 19, 2010 | Updated: | April 5, 2011 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Mandriva advisory:
A possible double free flaw was found in the imap extension for php. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
suricata: TCP evasions
| Package(s): | suricata | CVE #(s): | |||||
| Created: | November 22, 2010 | Updated: | November 28, 2010 | ||||
| Description: | From the Red Hat bugzilla:
It was reported that a number of TCP evasions existed in versions of Suricata prior to 1.0.2. Upstream has released version 1.0.2 to address these flaws. | ||||||
| Alerts: |
| ||||||
systemtap: denial of service
| Package(s): | systemtap | CVE #(s): | CVE-2010-4171 | ||||||||||||||||
| Created: | November 19, 2010 | Updated: | November 23, 2010 | ||||||||||||||||
| Description: | From the Red Hat bugzilla:
A security flaw was found in the way systemtap runtime tool (staprun) removed unused modules. A local attacker could use this flaw to conduct various denial of service attacks. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>