How do various open source mobile platforms protect users from malicious applications?

Recently, I came across availability of Android on eepc. I dusted my old eepc 701 and installed Andorid 4 from http://www.android-x86.org on it. It was straightforward. Wifi and the function keys I tried worked.

I was actually curious to see how usable is Android with a mouse and keyboard. I expected the absence of a touch screen will make it irritating but I was pleasantly surprised. I found myself absent-mindedly clicking and dragging a web page to scroll even on the desktop! It may indeed be better to find an alternate way to select text and use click and drag for scrolling the screen's visible area.

Multi-touch on the touch pad would make even more touch screen gestures, like pinch to shrink or zoom, available without a touch screen.

However, my exploration of Android and similar environments changed once I visited the applications marketplace. Searching for a web browser did not show Firefox but lot's of other applications. (Firefox is not compatible with eepc and, thus, did not show up in the search.)

The options for narrowing down the search were only free and paid. There was no separate grouping for open source. The reason for my concern was that before installing an application, the marketplace cautions us about the resources and facilities an application would use and do we wish to allow that. My anxiety was that how would I know that I could trust an application?

On a desktop environment, rogue applications use system flaws to access information. However, if a user is consciously running an application, nothing prevents the application to access contents of files owned by the user. (Unless, of course, the user is using selinux and has configured it suitably for resources used by each application.)

Many of us would avoid running a commercial or closed source application unless we trusted the source and have no easy alternate – for example, flash. I am inclined to trust an open source application believing that it is not likely to be misleading whereas I would be concerned about the motivation of the group offering a free but not open source application.

On the mobile smart phones and tablets platforms, the number of applications is a bragging right as if the absurd number of applications for a platform makes it more usable! (I would urge people to see the talks by Barry Schwartz and Sheena Iyengar on ted.com!)

I was instead struck by indecision (more like paralysis) because I was not sure if by allowing an application to access to disk and network, I was at risk of exposing my personal information to dubious application makers. Could the application read the user names and passwords stored by the web-browser for various sites? And this was on system I was using to just to test and explore Android!

Android is based on Linux which is secure but not against ignorance of a user (or perhaps, the politically correct - 'social engineering'). So, I wondered how Android was handling these concerns which led to http://source.android.com/tech/security/

Android - Each Application is a User

The Android platform takes advantage of the security inherent in Linux by assigning a unique user id to each Android application. Linux ensures that the resources used by each application are isolated from the others. Hence, permission to access disk allows it to use the disk but does not permit it to read any other file of any other application as that is owned by a different user, that is another application in this context! So, an application is running in a sandbox using the standard capabilities of Linux kernel. It is a remarkably simple method and known to work based on years of experience of desktops and servers.

Applications may need to share data and may do so using the standard Linux mechanisms subject to the security policies. However, Android includes a new IPC mechanism which is managed by the Android environment. In particular, ContentProviders mechanism provides access to the data stored on the device. An application can use data provided by an application using the ContentProvider mechanism or expose its own data using this mechanism.

When a user installs an application, the permissions dialog will ask the user to agree to grant the permissions needed by the application. It is done once only so as not to irritate the user. Overall, the Android seems to provide a reasonable environment so that running applications from unknown sources is not as risky as I had first feared.

MeeGo – Extended Access Control

I wasn't looking for MeeGo. I was actually interested in KDE plasma active http://plasma-active.org/. I like the plasma netbook environment and have been looking forward to the plasma active environment on tablets. I was surprised to find that a distribution available for testing provided by http://plasma-active.basyskom.com/ is based on MeeGo for the intel platform. It is still a work in progress but I was curious about how the issues of security are handled by MeeGo.

MeeGo also uses the standard Linux environment. However, user level security is not enough to isolate resources used by an application. MeeGo access control framework introduced two new types of credentials – Resource Token and Application Identifier. The D-Bus interfaces for a real system object are protected and an application needing a resource needs to have the credentials to access those interfaces.

Access control via D-Bus is used on desktops as well. For example, on modern Linux desktops, the decisions regarding who may update a system, who may use NetworkManager to configure wifi, or who may power-off the system, etc. are managed using the policykit framework.

An application has the possibility of creating new resource tokens and control access to its sensitive resources.

Application Identifier is generated by the package manager and remains unchanged during the life of the application.

The additional access control mechanisms are implemented using the SMACK (simplified mandatory access control kernel) module in the mainline kernel. Any system object, e.g. a file, will be automatically protected with additional authentication by the kernel if it has a SMACK label.

Firefox OS – HTML5

A draft of the security model for Firefox OS is available on developer.mozilla.org. The key differentiation is that it will allow html5 applications to integrate with the device's hardware using javascript. A side effect is that the need for numerous applications created specifically for a mobile platform would disappear.

The design of Firefox OS assumes that data transfer is slow and expensive. The user has a limited amount of data traffic available each month. Users are likely to keep data services disabled except when they need to carry out some transaction. These are the common scenarios in many countries, including India.

Even though as Mark Zuckerberg stated that Facebook made a strategic error to bet too heavily on html5 rather than native applications, the time for html5 will come. Mozilla hopes to implement the needed api of html5 in Firefox OS so that the experience of Facebook is a thing of the past. Firefox OS may indeed be the ideal platform for India. It would certainly make it easy to select open source applications as contrast to merely free.

A good place to check about the current status of html5 on your browser is http://html5test.com/.

Firefox OS's security model references the documentation of system hardening by Chromium OS, which also is an environment for running web applications. As in the case of MeeGo, the key concept is the principle of least privilege and implemented using mandatory and role-based access controls. A number of alternatives are available in the kernel, including SMACK, SELinux and TOMOYO. The core functionality which will be needed by Firefox OS is available.

We may conclude that securing a user's and each application's data against accidental or malicious intent of other applications is a primary design consideration for mobile platforms. Each environment tries to ensure that an application runs effectively in some type of a sandbox. Sharing of data or objects between applications has to be specifically requested and authorized.

While the security policies are more complex in these environments than on traditional pc's, the mobile operating systems try to avoid presenting users with unnecessary technical details. As long as a user does not give unnecessary access rights to an application, various mobile platforms provide a pretty safe environment for a user to install and experiment with new applications.