Are We Safe Us­ing Apps on Tablets?

How do var­i­ous open source mo­bile plat­forms pro­tect users from ma­li­cious ap­pli­ca­tions?

OpenSource For You - - EXPLORING SOFTWARE -

oe­cently, f learnt of the avail­abil­ity of An­droid on beemC. f dusted off my old beemC TMN and in­stalled An­droid 4 from http:// www. an­droid- x86. org. ft was straight­for­ward— ti- ci and the func­tion keys f tried, worked. f was ac­tu­ally cu­ri­ous to see how us­able An­droid would be with a mouse and key­board. f expected that the ab­sence of a touch screen would make it ir­ri­tat­ing, but f was pleas­antly sur­prised. f found my­self ab­sent- mind­edly click­ing and drag­ging a teb page to scroll even on the desk­top! ft may in­deed be bet­ter to find an al­ter­nate way to se­lect text and use click- and- drag for scrolling the screenDs vis­i­ble area. julti- touch on the touch- pad would make even more touch- screen ges­tures, like pinch to shrink or zoom, avail­able with­out a touch- screen.

eow­ever, my ex­plo­ration of An­droid and sim­i­lar en­vi­ron­ments changed once f vis­ited the ap­pli­ca­tions mar­ket­place. pearch­ing for a teb browser did not show cire­fox (itDs not com­pat­i­ble with beemC, and thus did not show upF, but lots of other ap­pli­ca­tions. qhe op­tions for nar­row­ing down the search were only free and paid. qhere was no sep­a­rate group­ing for open source. qhe rea­son for my con­cern was that be­fore in­stalling an ap­pli­ca­tion, the mar­ket­place cau­tions us about the re­sources and fa­cil­i­ties an ap­pli­ca­tion would use, and prompts us to think about whether we wish to al­low that. jy anx­i­ety was about how f would know that f could trust an ap­pli­ca­tion?

fn desk­top en­vi­ron­ments, rogue ap­pli­ca­tions use sys­tem flaws to ac­cess in­for­ma­tion. eow­ever, if a user is con­sciously run­ning an ap­pli­ca­tion, noth­ing pre­vents the ap­pli­ca­tion from ac­cess­ing the con­tents of files owned by the user— un­less, of course, the user is us­ing pbi­inux and has con­fig­ured it suitably for re­sources used by each ap­pli­ca­tion.

jany of us would avoid run­ning a com­mer­cial or closed-source ap­pli­ca­tion un­less we trusted the source, or have no easy al­ter­nate—for ex­am­ple, clash. f am in­clined to trust an open source ap­pli­ca­tion, be­liev­ing that it is not likely to be mis­lead­ing, whereas f would be con­cerned about the mo­ti­va­tion of the group of­fer­ing a free, but not open source, ap­pli­ca­tion.

ln the smart­phone and tablet plat­forms, the num­ber of ap­pli­ca­tions avail­able has given them brag­ging rights, as if the ab­surd num­ber of ap­pli­ca­tions for a plat­form makes it more us­able! (f would urge peo­ple to see the talks by _arry pchwartz and pheena fyen­gar on ted.com! F fn­stead, f was struck by in­de­ci­sion (more like paral­y­sisF be­cause f was not sure if, by al­low­ing an ap­pli­ca­tion ac­cess to the disk and net­work, f was risk­ing ex­pos­ing my per­sonal in­for­ma­tion to du­bi­ous ap­pli­ca­tion mak­ers. Could the ap­pli­ca­tion read the user names and pass­words stored by the teb browser for var­i­ous sites? And this was on a sys­tem f was us­ing to just test and ex­plore An­droid!

An­droid is based on iinux, which is se­cure—but not against the ig­no­rance of users (or per­haps, the po­lit­i­cally cor­rect term is Dso­cial en­gi­neer­ingDF. po, f won­dered how An­droid was han­dling these con­cerns, which led me to http://source.an­droid.com/tech/se­cu­rity/

An­droid—each ap­pli­ca­tion is a user

qhe An­droid plat­form takes ad­van­tage of the se­cu­rity in­her­ent in iinux by as­sign­ing a unique user fa to each An­droid ap­pli­ca­tion. iinux en­sures that the re­sources used by each ap­pli­ca­tion are iso­lated from the oth­ers. eence, per­mis­sion to ac­cess the disk al­lows it to use the disk, but does not per­mit it to read any other file of any other ap­pli­ca­tion, as that is owned by a dif­fer­ent user—i.e., an­other ap­pli­ca­tion, in this con­text! po, an ap­pli­ca­tion is run­ning in a sand­box us­ing the stan­dard ca­pa­bil­i­ties of the iinux ker­nel. ft is a re­mark­ably sim­ple method, and has been known to work based on years of ex­pe­ri­ence on desk­tops and servers.

Ap­pli­ca­tions may need to share data, and may do so us­ing the stan­dard iinux mech­a­nisms, sub­ject to the se­cu­rity poli­cies. eow­ever, An­droid in­cludes a new fmC mech­a­nism, which is man­aged by the An­droid

en­vi­ron­ment. fn par­tic­u­lar, the Con­tentm­roviders mech­a­nism pro­vides ac­cess to the data stored on the de­vice. An ap­pli­ca­tion can use data pro­vided by an­other ap­pli­ca­tion us­ing the Con­tentm­rovider mech­a­nism, or ex­pose its own data us­ing this mech­a­nism.

then a user in­stalls an ap­pli­ca­tion, the per­mis­sions di­a­logue will ask the user to agree to grant the per­mis­sions needed by the ap­pli­ca­tion. ft is done once only, so as not to ir­ri­tate the user. lver­all, An­droid seems to pro­vide a rea­son­able en­vi­ron­ment so that run­ning ap­pli­ca­tions from unNnRZn sRuUFHs Ls nRW Ds ULsNy Ds , KDG fiUsW IHDUHG.

MeeGo—ex­tended ac­cess con­trol

f was­nDt look­ing for jeedo. f was ac­tu­ally in­ter­ested in hab mlasma Ac­tive ( http://plasma-ac­tive.org/ F. f like the mlasma net­book en­vi­ron­ment, and have been look­ing for­ward to the mlasma Ac­tive en­vi­ron­ment on tablets. , ZDs suUSULsHG WR finG WKDW D GLsWULEuWLRn DYDLODEOH IRU test­ing, pro­vided by http://plasma-ac­tive.basyskom.com/, is based on jeedo for the fn­tel plat­form. ft is still a work in progress, but f was cu­ri­ous about how se­cu­rity is­sues are han­dled by jeedo.

jeedo also uses the stan­dard iinux en­vi­ron­ment. eow­ever, user-level se­cu­rity is not enough to iso­late re­sources used by an ap­pli­ca­tion. qhe jeedo ac­cess con­trol frame­work in­tro­duced two new types of cre­den­tials— a oe­source To­ken and Ap­pli­catiRn Iden­ti­fier. qhe a-_us in­ter­faces for a real sys­tem ob­ject are pro­tected, and an ap­pli­ca­tion need­ing a re­source needs to have the cre­den­tials to ac­cess those in­ter­faces.

Ac­cess con­trol via a-_us is used on desk­tops as well. cor ex­am­ple, on mod­ern iinux desk­tops, the de­ci­sions re­gard­ing who may up­date a sys­tem, who may use ket­work­jan­ager to con­fig­ure ti-ci, etc, are man­aged us­ing the mol­i­cy­hit frame­work. An ap­pli­ca­tion can cre­ate new re­source to­kens and con­trol ac­cess to its sen­si­tive re­sources. qhe Ap­pli­ca­tion fden­ti­fier is gen­er­ated by the pack­age man­ager, and re­mains un­changed dur­ing the life of the ap­pli­ca­tion.

qhe ad­di­tional ac­cess con­trol mech­a­nisms are LPSOHPHnWHG usLnJ WKH S0AC. (SLPSOL­fiHG 0DnGDWRUy Ac­cess Con­trol her­nelF mod­ule in the main­line ker­nel. Any sysWHP REMHFW, H.J., D fiOH, ZLOO EH DuWRPDWLFDOOy pro­tected with ad­di­tional authentication by the ker­nel if it has a pjACh la­bel.

Fire­fox OS—HTML5

A draft of the cire­fox lp’ se­cu­rity model is avail­able on de­vel­oper.mozilla.org. qhe key dif­fer­ence is that it will al­low eqjiR ap­pli­ca­tions to in­te­grate with the de­viceDs hard­ware us­ing gavapcript. A side ef­fect is that the need for nu­mer­ous ap­pli­ca­tions cre­ated specif­i­cally for a mo­bile plat­form, would dis­ap­pear. qhe de­sign of cire­fox lp as­sumes that data trans­fer is slow, ex­pen­sive, and has a monthly lim­i­ta­tion (a com­mon sce­nario in many coun­tries, in­clud­ing fn­diaF. rsers are likely to keep data ser­vices dis­abled, ex­cept when they need to carry out some trans­ac­tion.

bven though (as jark wucker­berg stat­edF cace­book made a strate­gic er­ror bet­ting heav­ily on eqjiR rather than na­tive ap­pli­ca­tions, the time for eqjiR will come. jozilla hopes to im­ple­ment the needed Amf of eqjiR in cire­fox lp, so that the ex­pe­ri­ence of cace­book is a thing of the past. cire­fox lp may in­deed be the ideal plat­form for fn­dia. ft would cer­tainly make it easy to se­lect open source ap­pli­ca­tions rather than those that are merely ‘free’. A good place to check the cur­rent sta­tus of eqjiR on your browser is http://htm­l5test.com/.

cire­fox lpD se­cu­rity model ref­er­ences the doc­u­men­ta­tion of sys­tem hard­en­ing by Chromium lp, which also is an en­vi­ron­ment for run­ning teb ap­pli­ca­tions. As in the case of jeedo, the key con­cept is the prin­ci­ple of least priv­i­lege, and it is im­ple­mented us­ing manda­tory and role-based ac­cess con­trols. A num­ber of al­ter­na­tives are avail­able in the ker­nel, in­clud­ing pjACh, pbi­inux and qljlvl. qhe core func­tion­al­ity needed by cire­fox lp is avail­able.

te may con­clude that se­cur­ing a userDs or each ap­pli­ca­tionDs data against ac­ci­dents or the ma­li­cious in­tent of other ap­pli­ca­tions is a pri­mary de­sign con­sid­er­a­tion for mo­bile plat­forms. bach en­vi­ron­ment tries to en­sure that an ap­pli­ca­tion runs ef­fec­tively in some type of a sand­box. phar­ing of data or ob­jects be­tween ap­pli­ca­tions has to be specif­i­cally re­quested and au­tho­rised. thile se­cu­rity poli­cies are more com­plex in these en­vi­ron­ments than on tra­di­tional mCs, mo­bile lps try to avoid pre­sent­ing users with un­nec­es­sary tech­ni­cal de­tails. As long as a user does not give un­nec­es­sary ac­cess rights to an ap­pli­ca­tion, var­i­ous mo­bile plat­forms pro­vide a pretty safe en­vi­ron­ment for a user to in­stall and ex­per­i­ment with new ap­pli­ca­tions.

Anil Seth

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.