Security

Ubuntu has started outlining its plans for supporting third-party applications on mobile devices. The larger plan involves enabling independent developers to deliver their apps to phone and tablet users, but without going through the lengthy process currently used for maintaining packages in the desktop and server repositories. Consequently, new measures are planned to protect system security from potentially malicious applications. The blueprint is based on AppArmor, but it attempts to address several distinctions in the mobile device platform that AppArmor on desktops usually ignores.

The primary motivator for the new security work is that on desktop systems, the user session has historically been treated as "trusted"; Unix-like systems sport mechanisms that programs could use to attack other programs, but in practice programs have generally been trusted not to do so. Perhaps this is because the vast majority of desktop software on Linux systems is delivered through distribution (or project-specific) software repositories, which by and large have established review processes in place—or else the software in question is compiled locally, which places more of the burden for watching out for security issues on the user or administrator.

But mobile Linux systems are different. Casual phone users are less likely to be security-conscious developers or longstanding participants in the (at times) wild open source community. A far higher percentage of mobile phones apps are deployed as third-party apps on Linux desktop applications. Android copes with this distinct risk profile by several means, including restricting apps to its application sandbox and running each app as a separate user, but also by developing its own services for inter-process communication (IPC) and similar features.

The Ubuntu mobile platform, however, is intended to stay as close as possible to the system stack used on desktops and servers. Creating a separate IPC mechanism, permission system, and storage system solely for mobile devices is out of the question. The Ubuntu Security Team has published a specification outlining both the security risks found in the desktop environment, and how it plans to compensate for those risks on mobile devices.

The risks and requirements

The basic requirements needed from the "application confinement" framework (as it is called) include the ability to pre-define filesystem locations that the app can access, the ability to restrict Internet access, and the ability to log events for debugging and auditing purposes. AppArmor already meets those requirements, and it offers several additional options, such as the ability to restrict things like library loading, capabilities, and certain privileged operations.

But AppArmor does not currently address some other important system components, such as D-Bus, the GConf or GSettings configuration storage frameworks, or the display server. D-Bus runs several IPC "buses," including the privileged system bus and the user session bus. But on desktop systems it does not enforce any restrictions on using the session bus, so malicious apps could potentially send harmful messages to other programs. GConf generally uses a single settings database for all applications associated with a user account, and GSettings has a similar per-user settings database. The X display server features several mechanisms that a malicious app could use to sniff data from other applications, such as the clipboard, screenshots, input events, drag-and-drop, and the XSETTINGS configuration framework.

Many desktop systems also take a lax approach to environment variables, such as allowing applications to load arbitrary modules by setting a special environment variable. Applications can also send signals to other processes (such as SIGTERM), and potentially discover information about other processes through /proc. The specification also notes that the GNOME Keyring and Ubuntu Online Accounts programs are both potential security risks, since they store user credentials of various types, but both respond to queries from other applications over D-Bus.

And they have a plan

The risks posed by X constitute a challenge on their own. Obviously, the display server issues fall under Ubuntu's plans to develop its own Mir display server and Unity-Next graphical shell. The application confinement specification notes in brief that Mir should prevent arbitrary applications from taking screenshots and from sniffing input events belonging to other applications, and that Mir will not support XSETTINGS. Mir will also utilize AppArmor policy rules to limit access to the clipboard and to drag-and-drop events.

Many of the other challenges will be addressed through AppArmor profiles, though some necessitate changes to AppArmor or to the system frameworks involved. Each app will be shipped with its own AppArmor profile, which will enumerate its permissions. The app launcher will handle loading the AppArmor profile, configuring the environment, and launching the app (as well as cleaning up after the app shuts down). This process also requires some changes to AppArmor, since the way it currently works, all profiles are loaded at system start-up. The launcher process will also remain alive to monitor running apps, shutting them down if they violate CPU or memory limits, or cause an AppArmor failure event. The specification notes that cgroups were considered for this resource-monitoring task, but that they were not deemed a good fit for the mobile use-case.

The Ubuntu SDK is intended to help developers create these per-app AppArmor profiles; there will be some sort of review process involved which will hopefully catch security violations, but it is still in development. Ultimately, though, the purpose of the confinement scheme is to make the app review process short, but still provide end users with improved security.

To that end, Ubuntu is working on adding D-Bus monitoring to AppArmor policies. Apps will not be allowed to access D-Bus services that belong to the system; there is a blacklist including com.canonical.*, net.launchpad.*, org.gnome.*, org.gtk.*, and other reserved namespaces. Access to GConf and GSettings will be blocked by default. Since GConf has been deprecated in favor of GSettings, it will not receive any further work, but the plan is to develop a fine-grained access mechanism for GSettings. Each app will be allowed to access only specific, whitelisted GSettings paths.

The current plan for environment variable handling is for each AppArmor profile to specify which environment variables the app is authorized to change, and to either deny the app from launching if it attempts to set other environment variables, or to "scrub" those variables before launch. Similarly, AppArmor profiles will whitelist which signals an app is allowed to send. AppArmor will also get support for using the PID variable in profile rules, so profiles will restrict apps to reading only the information in their own /proc/PID directory.

The plan is for Ubuntu Online Accounts to gain AppArmor integration; initially this will be boolean support—an app will either be allowed to access online accounts, or it will not—but support for finer-grained access in later releases is planned, which will enable restricting access on the basis of each configured account. The plan for GNOME Keyring is less clear. Initially, it, too, will be subject to coarse, boolean access restrictions (which will default to "no access"). Apps will also be restricted so that those with GNOME Keyring access will only be permitted to read credentials that the app itself has stored. But the specification says that it is possible that fine-grain access may be added later, perhaps prompting the user when an app requests access to a credential stored by a different application.

The specification also lays out a plan for confining an app's access to the filesystem. Each app will have its own private directory for storing data and settings, in ~/.confined/foo. For access to other data in the filesystem, apps will first need permission for the specific data type in their AppArmor profile (e.g., "Photos", "Contacts", "Music", and so on). When the app requests a file, a separate file-chooser process will launch, allowing the user to select the file; this selection will then be returned to the app over D-Bus. The point of this setup is to force file-selection to be run past the user, so that unauthorized access will not go unnoticed. But the specification points out that exactly how the selected file gets returned may depend on the file type; the details have yet to be fleshed out.

All in all, the Ubuntu application confinement scheme is designed to be "lightweight"; a decision that the wiki says rules out several other possible sandboxing mechanisms, such as LXC containers and virtualization. It is also interesting to note how the decision to run all programs as the same user drives many of the engineering decisions which follow. Android, by comparison, creates a separate user for each app. The Ubuntu application confinement scheme does not use separate user IDs, which in turn is what necessitates setting up security mechanisms to restrict signals, environment variables, D-Bus, and the GConf and GSettings configuration systems.

An interesting thought experiment is to consider that all of the risks that these well-known frameworks present on mobile devices also exist on desktops and servers. But users and administrators are accustomed to them, perhaps in large part because third-party binary applications are relatively scarce on desktops and servers. Although if Linux were to ever "hit it big" in the traditional, world-marketshare-domination sense, that could change. That might make much of the AppArmor work in Ubuntu's application confinement plan considerably more widely applicable.

Comments (10 posted)

Brief items

Security quotes of the week

Comments (8 posted)

New vulnerabilities

icedtea-web: multiple vulnerabilities

Comments (none posted)

java: multiple vulnerabilities

Comments (none posted)

java: multiple unspecified vulnerabilities

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

kernel: privilege escalation

Comments (none posted)

kernel: denial of service

Comments (none posted)

mysql: multiple unspecified vulnerabilities

Comments (none posted)

owncloud: multiple vulnerabilities

Comments (none posted)

tinc: code execution

Comments (none posted)

xen: denial of service

Comments (none posted)

xorg-server: information disclosure

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>