Security

MeeGo rethinks privacy protection

By Jonathan Corbet
April 13, 2011

Companies operating in the handset market have different approaches to almost everything, but they do agree on one thing: they have seen the security problems which plague desktop systems and they want no part of them. There is little consistency in how the goal of a higher level of security is reached, though. Some companies go for heavy-handed central control of all software which can be installed on the device. Android uses sandboxing and a set of capabilities enforced by the Dalvik virtual machine. MeeGo's approach has been based on traditional Linux access control paired with the Smack mandatory access control module. But much has changed in the MeeGo world, and it appears that security will be changing too.

In early March, the project sent out a notice regarding a number of architectural changes made after Nokia's change of heart. With regard to security, the announcement said:

In the long-term, we will re-evaluate the direction we are taking with MeeGo security with a new focus on *End-User Privacy*. While we do not intend to immediately remove the security enabling technologies we have been including in MeeGo, all security technologies will be re-examined with this new focus in mind.

It appears that at least some of this reexamination has been done; the results were discussed in this message from Ryan Ware which focused mainly on the problem of untrusted third-party applications.

The MeeGo project, it seems, is reconsidering its decision to use the Smack access control module; a switch to SELinux may be in the works. SELinux would mainly be charged with keeping the trusted part of the system in line. All untrusted code would be sandboxed into its own container; each container gets a disposable, private filesystem in the form of a Btrfs snapshot. Through an unspecified mechanism (presumably the mandatory access control module), these untrusted containers could be given limited access to user data, device resources, etc.

It probably surprised nobody that Casey Schaufler, the author of Smack, was not sold on the value of a change to SELinux. This change would, he said, add a great deal of complexity to the system without adding any real security:

SELinux as provided in distributions today does not, for all its trappings, complexity and assurances, enforce any security policy. SELinux is capable of enforcing a security policy, but no general purpose system available today provides anything more than a general description of the experienced behavior of a small subset of the system supplied applications.

The people who built SELinux fell into a trap that has been claiming security developers since computers became programmable. The availability of granularity must not be assumed to imply that everything should be broken down into as fine a granularity as possible. The original Flask papers talk about a small number of well defined domains. Once the code was implemented however the granularity gremlins swarmed in and now the reference policy exceeds 900,000 lines. And it enforces nothing.

Ryan's response was that the existing SELinux reference policy is not relevant because MeeGo does not plan to use it:

At this point I want nothing to do with the Reference Policy. I would much prefer to focus on a limited set of functionality around privacy controls. I know that means it won't necessarily exhibit "expected" SELinux behavior. Given the relatively limited range of verticals we are trying to support, I believe we will be able to get away with that.

What this means is that he is talking about creating a new SELinux policy from the beginning. The success of such an endeavor is, to put it gently, not entirely assured. The current reference policy has taken many years and a great deal of pain to reach its current state of utility; there are very few examples of viable alternative policies out there. Undoubtedly other policies are possible, and they need not necessarily be as complex as the reference policy, but anybody setting out on such a project should be under no illusions that it will be easily accomplished.

The motivation for the switch to SELinux is unclear; Ryan suggests that manufacturers have been asking for it. He also said that manufacturers would be able to adjust the policy for their specific needs, a statement that Casey was not entirely ready to accept:

There are very few integrators, even in the military and intelligence arenas, who feel sufficiently confident with their SELinux policy skills to do any tweaking that isn't directly targeted at disabling the SELinux controls.

Ryan acknowledged that little difficulty, but he seems determined to press on in this direction.

The end goal of all this work is said to be preventing the exposure of end-user data. That will not be an easy goal to achieve either, though. Once an application gets access to a user's data, even the firmest SELinux policy is going to have a hard time preventing the disclosure of that data if the application is coded to do so; Ryan has acknowledged this fact. Any Android user who pays attention knows that even trivial applications tend to ask for combinations of privileges (address book access and network access, for example) which amount to giving away the store. Preventing information leakage through a channel like that - while allowing the application to run as intended - is not straightforward.

So it may be that the "put untrusted applications in a sandbox and limit what they can see" model is as good as it's going to get. As Casey pointed out, applications are, for better or worse, part of the security structure on these devices. If an application has access to resources with security implications, the application must implement any associated security policy. That's a discouraging conclusion for anybody who wants to install arbitrary applications from untrusted sources.

Comments (5 posted)

Brief items

Security quotes of the week

This has not changed since I started working in security in the days when dinosaurs roamed the earth and megabytes were only found on disk drives. We released a Unix variant that we charged $5000 extra for because it had an unprivileged root (using POSIX capabilities) and every customer's first questions was "How do I become Real Root?".

-- Casey Schaufler

So here we are on the cusp of something. At long last, we're finally approaching the critical mass necessary to replace the CA system that we've long since grown out of. But when evaluating replacement models for the CA system, the very first question we should ask is "who do I have to trust, and for how long?" If the answer is "a prescribed set of people, forever" we should probably proceed with extreme caution. I believe that if we don't develop a solution which offers trust agility, we will inevitably find ourselves back in the exact same place that we're currently trying to escape from.

-- Moxie Marlinspike on "trust agility"

It might happen that someday ICANN will create some of these TLDs. There is even talk that they might allow people to register (at a high cost) arbitrary TLDs like .milk or .cookies. In that case, these currently-invalid certificates will become valid because they will suddenly refer to usable internet names. For example, imagine if Microsoft were able to, in the future, register the .microsoft TLD so that they could have www.microsoft for their web site address. As the Observatory shows, an attacker can probably get a CA to sign that name today. Such an attacker would be able to hijack Microsoft's web site on the very minute the new name goes live.

-- Chris Palmer on the EFF Deeplinks blog

Comments (1 posted)

New vulnerabilities

dhcp: man-in-the-middle attack

Package(s):

dhcp

CVE #(s):

CVE-2011-0997

Created:

April 7, 2011

Updated:

May 31, 2011

Description:

From the Slackware advisory:

In dhclient, check the data for some string options for reasonableness before passing it along to the script that interfaces with the OS. This prevents some possible attacks by a hostile DHCP server.

Alerts:

Gentoo	201301-06	dhcp	2013-01-09
Red Hat	RHSA-2011:0840-01	dhcp	2011-05-31
SUSE	SUSE-SR:2011:008	java-1_6_0-ibm, java-1_5_0-ibm, java-1_4_2-ibm, postfix, dhcp6, dhcpcd, mono-addon-bytefx-data-mysql/bytefx-data-mysql, dbus-1, libtiff/libtiff-devel, cifs-mount/libnetapi-devel, rubygem-sqlite3, gnutls, libpolkit0, udisks	2011-05-03
Ubuntu	USN-1108-2	dhcp3	2011-04-19
SUSE	SUSE-SR:2011:007	NetworkManager, OpenOffice_org, apache2-slms, dbus-1-glib, dhcp/dhcpcd/dhcp6, freetype2, kbd, krb5, libcgroup, libmodplug, libvirt, mailman, moonlight-plugin, nbd, openldap2, pure-ftpd, python-feedparser, rsyslog, telepathy-gabble, wireshark	2011-04-19
Fedora	FEDORA-2011-0848	dhcp	2011-01-28
CentOS	CESA-2011:0428	dhcp	2011-04-14
Fedora	FEDORA-2011-4897	dhcp	2011-04-06
Ubuntu	USN-1108-1	dhcp3	2011-04-11
Mandriva	MDVSA-2011:073	dhcp	2011-04-11
Debian	DSA-2217-1	dhcp3	2011-04-10
Debian	DSA-2216-1	isc-dhcp	2011-04-10
CentOS	CESA-2011:0428	dhcp	2011-04-08
openSUSE	openSUSE-SU-2011:0321-1	dhcp	2011-04-08
openSUSE	openSUSE-SU-2011:0320-1	dhcp	2011-04-08
Red Hat	RHSA-2011:0428-01	dhcp	2011-04-08
Slackware	SSA:2011-097-01	dhcp	2011-04-07
Pardus	2011-71	dhcp	2011-05-02

Security

MeeGo rethinks privacy protection

Brief items

Security quotes of the week

New vulnerabilities

dhcp: man-in-the-middle attack

ikiwiki: cross-site scripting

kdelibs: HTML injection

kernel: multiple vulnerabilities

Kernel: two denial of service vulnerabilities

libvirt: denial of service

moonlight: multiple vulnerabilities

php: symlink attack

php: denial of service

python-feedparser: multiple vulnerabilities

rsyslog: multiple vulnerabilities

shadow: denial of service

spice-xpi: multiple vulnerabilities

tmux: privilege escalation

vlc: arbitrary code execution

vlc: arbitrary code execution