TL; DR: hüpake julgelt otse allosas olevale järeldusele, kui soovite :)!

SELinuksi eesmärk on vältida privileegide eskaleerumist kohustusliku reegli kehtestamise kaudu mis piirab võimalikke toiminguid nii privileegide kui privilegeeritud kasutajate poolt.

Termin "kasutajad" hõlmab siin ka kõiki seadmes töötavaid protsesse, hoolimata sellest, kas see on otseselt seotud kasutaja füüsiliste toimingutega (inimene, teie ;)), kuna iga protsess töötab mõne süsteemi "kasutaja" kontot kasutades.

Ajalooliselt käsitletakse Unix-põhiste süsteemide lubasid nn diskreetsete juurdepääsukontrollide (DAC) süsteemide abil. Selles mudelis:

• ressurssidel nagu failid on omanikud, kes saavad määratleda neile kuuluvate ressursside juurdepääsuõigused: see võimaldab neil otsustada, kas konkreetne ressurss peaks olema privaatne (sellele pääseb juurde ainult omanik) või kui seda tuleks jagada mõne teise kasutajaga.
• Lisaks on teil ülikasutaja (nn Unix-põhistes süsteemides nimega root ), mis on administraatorikasutaja ja on juurdepääs kõigele süsteemis olevale. Inimene (tavaliselt süsteemiadministraator) saab seda kontot seadme hooldamiseks või parandamiseks interaktiivselt kasutada, kuid tavaliselt kasutavad seda kontot peamiselt privileegi taset vajavad taust- või madalate tasemete teenused: seadme draiverid, võrgu konfiguratsiooniteenused, teenused vajadus juurde pääseda iga kasutaja failidele või tegeleda kasutajate sisese suhtlemisega.

See on väga tore ja pakub juba head turvalisust. Kuidas on lood selliste asjaoludega:

1. Mis juhtuks, kui leitakse viga root -na töötavas teenuses, mis võimaldaks ründajal sellist teenust petta mingi suvalise koodi käitamine? Selline ründaja saaks seadmele täieliku juurdepääsu. Mõne konkreetse näite toomiseks võib sellise vea käivitada spetsiaalselt loodud võrgu konfiguratsiooniteabe ( DHCP) või MMS telefoni saatmine.
2. Mis juhtuks, kui mõni kasutaja ei kaitse eraressursse õigesti? Siis võivad need privilegeeritud kasutajad nendele ressurssidele pahatahtlikult juurde pääseda (neid lugeda, võib-olla isegi muuta või kustutada). See on tavaliselt see, mis teil on siis, kui teie telefonis töötab pahatahtlik rakendus (olenemata sellest, kas teid on petetud installima või kui see tuli siia ise, kasutades viga mõnes teises privileegimata rakenduses, brauseris või meilikliendis näiteks) ja see pahatahtlik rakendus üritab otse juurde pääseda teistele rakenduste andmetele või salvestusruumidele (seda saab teha tavaliselt kättesaamatutele andmetele juurde pääsemiseks või installida ennast mitmesse kohta, et muuta nende eemaldamine raskemaks).
ol >

Siit tuleb SELinux.

SELinux on kohustusliku juurdepääsukontrolli (MAC) süsteem. Kui varem kirjeldatud DAC-süsteemi kasutajad vastutasid oma ressurssidele asjakohase õiguse seadmise eest, siis MAC-süsteemi puhul rakendatakse kogu süsteemipõhist (operatsioonisüsteemiga kaasas olevat) poliitikat nii privilegeeritud kui ka privileegitud kasutajatele.

See lahendab kaks ülalnimetatud probleemi järgmisel viisil:

1. Nagu ma ütlesin, kehtib see reegel ka privilegeeritud kasutajate kohta. See tähendab, et korralikult kujundatud poliitika korral ei saa teenus, mis on mõeldud seadme võrgukonfiguratsiooni haldamiseks, midagi muud teha: tal pole näiteks juurdepääsu SMS-ile ja SMS-i käsitseval teenusel pole juurdepääsu võrgu konfiguratsioonile ja kumbki neist ei pääse kasutaja andmetele vaatamata sellele, et mõlemad töötavad superkasutaja kontot kasutades.
2. Android sisaldas hiljuti mitme kasutaja funktsiooni, mille on rakendanud SELinux, mis takistab kasutajatel juurdepääsu teiste kasutajate andmetele. Kuid peale selle vastutab SELinuksi poliitika ka lubatud rakenduste käitumise kirjeldamise eest ja tõenäoliselt isegi siis, kui mõned ressursid pole DAC-süsteemi abil õigesti kaitstud, tuleb SELinux appi ja takistab pahatahtlikul rakendusel neile otsest juurdepääsu.

DAC- ja MAC-süsteemid ei välista üksteist, vastupidi, MAC-süsteem (SELinux) toimib DAC-süsteemi teise kaitsekihina (traditsioonilised Unixi-laadsed õigused). SELinuksi ülesanne on blokeerida igasugune tegevus, mis on vastuolus poliitikaga, mis muidu aktsepteeritakse ainult DAC-süsteemi arvestades.

Keeruline on see, et sellise poliitika kirjutamine võib olla väga keeruline: see peab tõepoolest olema katke iga seadme komponendid iga võimaliku kasutamise jaoks igas olukorras. Tegelikult, olenemata sellest, kas mõni tegevus võib teie olukorras olla õigustatud: kui seda pole eeskirjades, on see keelatud . Halvasti kujundatud poliitikatel võivad seetõttu olla juhuslikud tagajärjed, nagu rakenduste krahhid, kasutamiskõlbmatud funktsioonid ja nii edasi.

Sellepärast lisasid Android shipping SELinuxi esimesed versioonid selle vaikimisi režiimi „Lubav”. Selles režiimis logib SELinux logi eeskirjade rikkumisi, kuid ei püüa seotud tegevust blokeerida. Saadud logifailide analüüsimisel on võimalik reegleid parandada ja täiustada kuni hetkeni, mil ainsaks järelejäänud eeskirjade rikkumiseks on tõepoolest pahatahtlik või soovimatu käitumine. Siinkohal saab SELinuxi muuta režiimi "jõustamine": see mitte ainult ei logi, vaid blokeerib ka kõik rikkuvad toimingud.

Järeldus

SELinux on leevendustehnika. See ei takista ründajaid teie telefoni sisenemast, kuid see tagab, et kui nad seal on, saavad nad teha nii vähe asju kui võimalik, ideaalis pole midagi kasulikku, eemaldades sellega igasuguse huvi telefoni ründamise vastu.

mida vanem on ROM, seda suurem on turvavigade arv, mis sellise juurdepääsu avavad. SELinux oleks tõhus viis minimaalsest ohutusest hoolimata nendest teadaolevatest haavatavustest hoolimata, kuid nõuetekohaseks toimimiseks tugineb SELinux keerukale poliitikale.

Kui teie ROM on vaikimisi SELinuxiga varustatud režiimis "Permissive", see tähendab tõenäoliselt, et selles sisalduv poliitika ei ole piisavalt usaldusväärne, et seda saaks ohutult režiimi "jõustamine" sisse lülitada.

Kui olete piisavalt tehniline ja teil on juurdepääs telefonilogile ( dmesg vähemalt, kuid tavaliselt kopeeritakse need ka logcat -i: on rakendusi, mis võimaldavad viimast näha, kuid sõltuvalt teie Androidi versioonist võivad need vajada juurjuurdepääsu), saate kontrollida, kas leiate "avc" kirjed: need on sõnumid, mis ütlevad teile, et SELinux on just avastanud poliitikaga vastuolus oleva tegevuse.

Siin on näide sellisest kirjest, mis on võetud CyanogenModi veebisaidilt:

  type = AVC msg = audit (1363289005.532: 184): avc: denied {read} for pid = 29199 comm = "Trace" name = "online" dev = "sysfs" ino = 30 scontext = staff_u : staff_r: googletalk_plugin_t tcontext = system_u: object_r: sysfs_t tclass = fail  

Kui neid pole, siis mõned neist või arvate, et need ei pruugi teid telefoni kasutamist takistada , võite proovida lülitada SELinuxi režiimi "jõustamine". Vanemates CyanogenMod ROM-ides oli see lihtne ja võimalik lihtsalt GUI-s peidetud valiku abil (pole vaja telefoni juurida ega mõnda konkreetset rakendust installida), ma ei tea, kas teised ROM-id pakkusid sama funktsioon, kuid kuna kasutasite silti CyanogenMod, siis võib teil olla õnne;).