Are We Safe Using Apps on Tablets?
How do various open source mobile platforms protect users from malicious applications?
oecently, f learnt of the availability of Android on beemC. f dusted off my old beemC TMN and installed Android 4 from http:// www. android- x86. org. ft was straightforward— ti- ci and the function keys f tried, worked. f was actually curious to see how usable Android would be with a mouse and keyboard. f expected that the absence of a touch screen would make it irritating, but f was pleasantly surprised. f found myself absent- mindedly clicking and dragging a teb page to scroll even on the desktop! ft may indeed be better to find an alternate way to select text and use click- and- drag for scrolling the screenDs visible area. julti- touch on the touch- pad would make even more touch- screen gestures, like pinch to shrink or zoom, available without a touch- screen.
eowever, my exploration of Android and similar environments changed once f visited the applications marketplace. pearching for a teb browser did not show cirefox (itDs not compatible with beemC, and thus did not show upF, but lots of other applications. qhe options for narrowing down the search were only free and paid. qhere was no separate grouping for open source. qhe reason for my concern was that before installing an application, the marketplace cautions us about the resources and facilities an application would use, and prompts us to think about whether we wish to allow that. jy anxiety was about how f would know that f could trust an application?
fn desktop environments, rogue applications use system flaws to access information. eowever, if a user is consciously running an application, nothing prevents the application from accessing the contents of files owned by the user— unless, of course, the user is using pbiinux and has configured it suitably for resources used by each application.
jany of us would avoid running a commercial or closed-source application unless we trusted the source, or have no easy alternate—for example, clash. f am inclined to trust an open source application, believing that it is not likely to be misleading, whereas f would be concerned about the motivation of the group offering a free, but not open source, application.
ln the smartphone and tablet platforms, the number of applications available has given them bragging rights, as if the absurd number of applications for a platform makes it more usable! (f would urge people to see the talks by _arry pchwartz and pheena fyengar on ted.com! F fnstead, f was struck by indecision (more like paralysisF because f was not sure if, by allowing an application access to the disk and network, f was risking exposing my personal information to dubious application makers. Could the application read the user names and passwords stored by the teb browser for various sites? And this was on a system f was using to just test and explore Android!
Android is based on iinux, which is secure—but not against the ignorance of users (or perhaps, the politically correct term is Dsocial engineeringDF. po, f wondered how Android was handling these concerns, which led me to http://source.android.com/tech/security/
Android—each application is a user
qhe Android platform takes advantage of the security inherent in iinux by assigning a unique user fa to each Android application. iinux ensures that the resources used by each application are isolated from the others. eence, permission to access the 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—i.e., another application, in this context! po, an application is running in a sandbox using the standard capabilities of the iinux kernel. ft is a remarkably simple method, and has been known to work based on years of experience on desktops and servers.
Applications may need to share data, and may do so using the standard iinux mechanisms, subject to the security policies. eowever, Android includes a new fmC mechanism, which is managed by the Android
environment. fn particular, the Contentmroviders mechanism provides access to the data stored on the device. An application can use data provided by another application using the Contentmrovider mechanism, or expose its own data using this mechanism.
then a user installs an application, the permissions dialogue will ask the user to agree to grant the permissions needed by the application. ft is done once only, so as not to irritate the user. lverall, Android seems to provide a reasonable environment so that running applications from unNnRZn sRuUFHs Ls nRW Ds ULsNy Ds , KDG fiUsW IHDUHG.
MeeGo—extended access control
f wasnDt looking for jeedo. f was actually interested in hab mlasma Active ( http://plasma-active.org/ F. f like the mlasma netbook environment, and have been looking forward to the mlasma Active environment on tablets. , ZDs suUSULsHG WR finG WKDW D GLsWULEuWLRn DYDLODEOH IRU testing, provided by http://plasma-active.basyskom.com/, is based on jeedo for the fntel platform. ft is still a work in progress, but f was curious about how security issues are handled by jeedo.
jeedo also uses the standard iinux environment. eowever, user-level security is not enough to isolate resources used by an application. qhe jeedo access control framework introduced two new types of credentials— a oesource Token and ApplicatiRn Identifier. qhe a-_us 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 a-_us is used on desktops as well. cor example, on modern iinux desktops, the decisions regarding who may update a system, who may use ketworkjanager to configure ti-ci, etc, are managed using the molicyhit framework. An application can create new resource tokens and control access to its sensitive resources. qhe Application fdentifier is generated by the package manager, and remains unchanged during the life of the application.
qhe additional access control mechanisms are LPSOHPHnWHG usLnJ WKH S0AC. (SLPSOLfiHG 0DnGDWRUy Access Control hernelF module in the mainline kernel. Any sysWHP REMHFW, H.J., D fiOH, ZLOO EH DuWRPDWLFDOOy protected with additional authentication by the kernel if it has a pjACh label.
A draft of the cirefox lp’ security model is available on developer.mozilla.org. qhe key difference is that it will allow eqjiR applications to integrate with the deviceDs hardware using gavapcript. A side effect is that the need for numerous applications created specifically for a mobile platform, would disappear. qhe design of cirefox lp assumes that data transfer is slow, expensive, and has a monthly limitation (a common scenario in many countries, including fndiaF. rsers are likely to keep data services disabled, except when they need to carry out some transaction.
bven though (as jark wuckerberg statedF cacebook made a strategic error betting heavily on eqjiR rather than native applications, the time for eqjiR will come. jozilla hopes to implement the needed Amf of eqjiR in cirefox lp, so that the experience of cacebook is a thing of the past. cirefox lp may indeed be the ideal platform for fndia. ft would certainly make it easy to select open source applications rather than those that are merely ‘free’. A good place to check the current status of eqjiR on your browser is http://html5test.com/.
cirefox lpD security model references the documentation of system hardening by Chromium lp, which also is an environment for running teb applications. As in the case of jeedo, the key concept is the principle of least privilege, and it is implemented using mandatory and role-based access controls. A number of alternatives are available in the kernel, including pjACh, pbiinux and qljlvl. qhe core functionality needed by cirefox lp is available.
te may conclude that securing a userDs or each applicationDs data against accidents or the malicious intent of other applications is a primary design consideration for mobile platforms. bach environment tries to ensure that an application runs effectively in some type of a sandbox. pharing of data or objects between applications has to be specifically requested and authorised. thile security policies are more complex in these environments than on traditional mCs, mobile lps 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.