- SELinux lisab Linuxi kernelile kohustusliku juurdepääsukontrolli siltide ja poliitikate kaudu, mis ulatuvad kaugemale traditsioonilistest DAC-õigustest.
- Turbekontekstid (kasutaja, roll, tüüp, tase) ja tüübipõhised poliitikad võimaldavad väga detailset juurdepääsukontrolli protsesside, failide ja portide üle.
- Tööriistad nagu getenforce, chcon, semanage, semodule ja booleans hõlbustavad SELinuxi praktilist haldamist tootmiskeskkonnas.
- Õigesti konfigureerituna leevendab SELinux nullpäeva rünnakuid ja valekonfiguratsioone, piirates rangelt iga teenuse või rakenduse võimalusi.
SELinux võib kõlada kui kerneli friikidele reserveeritud tehnoloogia, aga tegelikult on see tänapäeval üks võimsamaid Linuxi turvatööriistu . Kui haldate servereid, Dockeri konteineri turvalisust , pilveinfrastruktuuri või isegi pisut tundlikke lauaarvuteid, siis SELinuxi toimimise mõistmine muudab oluliselt süsteemi, mis on lihtsalt "hästi konfigureeritud" ja süsteemi, mida on raske kompromiteerida isegi nullpäeva haavatavuste korral.
Vaatamata oma mainele "keerulise" süsteemina pakub SELinux väga loogilist mudelit: see määratleb, mida iga protsess saab teha ja milliste objektidega see suhelda saab, ning kui midagi sellest skriptist kõrvale kaldub, peatab kernel selle kohe . Selle asemel, et pimesi usaldada, et juurkasutaja käitub õigesti või et teie deemonitel pole vigu, jõustab SELinux kohustusliku juurdepääsukontrolli, mis kehtib isegi superkasutajale, kasutades väga detailseid silte ja poliitikaid.
Mis on SELinux ja milliseid probleeme see lahendab?
Turvalisusega täiustatud Linux (SELinux) on Linuxi kerneli turvamoodul, mis põhineb LSM-il (Linux Security Modules). Algselt töötas selle välja NSA koostöös Red Hati ja teiste partneritega ning alates kerneli versioonist 2.6 on see olnud kerneli ametlik osa. See ei ole eraldi rakendus, vaid pigem kerneli laiendus, mis lisab kohustusliku juurdepääsukontrolli (MAC) süsteemi ja rollipõhise juurdepääsukontrolli (RBAC).
Erinevalt klassikalisest Unixi diskretsioonilisest juurdepääsukontrollist (DAC) – omaniku , grupi, teiste ja rwx-õiguste alusel – ei põhine SELinuxis juurdepääsuotsused failiomaniku valikul, vaid pigem turbeadministraatori kehtestatud globaalsel poliitikal. DAC on endiselt olemas ja on ülimuslik: kui DAC keelab, siis SELinux ei sekku; aga isegi kui DAC lubab, saab SELinux toimingu oma poliitika kohaselt ikkagi blokeerida.
SELinuxi arhitektuur eraldab komponendid selgelt: ühelt poolt kerneli koodi, mis teeb turvaotsuseid , ja teiselt poolt poliitikamoodulid, mis määratlevad, mis on lubatud ja mis mitte. See eraldamine võimaldab reegleid kohandada ilma kerneli uuesti kompileerimata ja lihtsustab süsteemi turvalisust mõjutavate komponentide arvu.
SELinux on vaikimisi kasutusele võetud sellistes distributsioonides nagu Fedora, Red Hat Enterprise Linux, CentOS ja Scientific Linux ning on sügavalt integreeritud ka sellistesse süsteemidesse nagu Android, kus seda kasutatakse süsteemiprotsesside ja rakenduste piiramiseks väga spetsiifiliste domeenidega. BSD ja GNU/Linuxi maailmas on alternatiive nagu AppArmor, TOMOYO ja TrustedBSD (macOS/FreeBSD-s), kuid SELinux paistab silma oma detailsuse taseme poolest, mida see pakub kõigi süsteemiobjektide suhtes.
DAC-ist MAC-ini: miks klassikalisest mudelist enam ei piisa
Traditsioonilises Unixi süsteemis hallatakse domeeni-objekti mudelit DAC-i abil: igal failil või ressursil on omanik ja õigused ning iga selle kasutajana töötav protsess saab nende ressurssidega teha mida iganes soovib . See tähendab, et kui deemon töötab root-kasutajana, võib iga ärakasutatav viga avada ukse poole süsteemi juhtimisele oma root-kontekstiga.
Tüüpiliste näidete hulka kuuluvad andmebaasid, mille andmefaile peaks manipuleerima ainult andmebaasihaldussüsteemi kaudu, kuid mida tegelikult saavad lugeda ja muuta protsessid, millel on juur-UID ; või kriitilised deemonid, mis töötavad liigsete õigustega. Programmeerimisviga, puhvri ületäitumine või halb sisendi valideerimine võivad muuta teenuse kogu süsteemi ummikuks.
SELinux lisab DAC-ile kohustusliku juurdepääsukontrolli (MAC) kihi . „Kohustuslik” tähendab, et juurdepääsukontrolli määrab administraator tsentraalselt poliitikate kaudu ning ei kasutajad ega protsessid saa neid reegleid iseseisvalt leevendada. Operatsioonisüsteem jõustab neid poliitikaid, hinnates enne iga asjakohast kerneli toimingut selle lubamist.
Kernel, kasutades LSM-konksusid, pärib SELinuxilt iga tundliku süsteemikõne (failide avamine, soklite loomine, failisüsteemide paigaldamine, IPC kaudu suhtlemine jne) korral. Igas otsustuspunktis hindab SELinux toimingut laaditud poliitika ning subjekti ja objekti turbekonteksti põhjal . Kui poliitika ei anna selgesõnaliselt luba, keelatakse toiming, olenemata sellest, kas protsess on root või mitte.
Töörežiimid: jõustav, lubav ja keelatud
SELinux saab töötada kolmes selgelt eristuvas tööolekus, mida on oluline mõista, et vältida tootmises hulluks minemist:
- JõustamineSELinux on lubatud ja jõustab poliitikat täielikult. Kõik reeglitega keelatud toimingud blokeeritakse ja logitakse.
- LubavSELinux on aktiivne, laadib poliitika ja sildistab failisüsteemi, aga ei blokeeri See salvestab tehingud ainult nii, nagu need oleksid tagasi lükatud. See on ideaalne poliitikate vigade parandamiseks ja kohandamiseks.
- invaliidistunudSELinux on keelatud. Ühtegi poliitikat ei rakendata ja sildistamist ei teostata. Süsteem tugineb klassikalisele DAC-mudelile.
Kiireteks ja ajutisteks muudatusteks jõustava ja lubava režiimi vahel kasutatakse käsku `setenforce` , kus režiim on määratud kui 0 (lubav) või 1 (jõustav). Oluline on teada, et see muutus on püsiv: pärast järgmist taaskäivitamist taastub režiim konfiguratsioonis määratletud režiimiks.
Kui vajate püsivat muudatust, peate faili redigeerima. /etc/selinux/config (või mõnes distributsioonis /etc/sysconfig/selinux) ja kohanda direktiivi väärtust SELINUX=disabled|permissive|enforcingMuudatused rakendatakse järgmisel käivitamisel ja paljudel juhtudel hõlmavad need failisüsteemi ümbermärgistamist.
Aktiivse režiimi kontrollimiseks võite kasutada käske nagu getenforce või sestatus . Esimene tagastab lihtsalt väärtuse Enforcing (jõustab), Permissive (lubab) või Disabled (keelatud); viimane annab täielikuma kokkuvõtte SELinuxi olekust, laaditud poliitikatest ja aktiivsetest moodulitest.
Turvakontekstid ja märgistussüsteem
SELinuxi südameks on selle turvamärgiste ehk kontekstide süsteem . Igal failil, protsessil, võrgupordil, soklil, seadmel jne on seotud kontekst, mis kirjeldab, kuidas seda kasutada saab. See kontekst koosneb mitmest väljast, mis koos moodustavad SELinuxi vaate sellele objektile.
Konteksti üldine vorming on user_u:role_r:type_t:level , millel on teatud nüansid olenevalt poliitikast (eriti kui kasutatakse MLS/MCS-i). Igal väljal on kindel eesmärk: SELinuxi kasutaja, roll, tüüp (protsessidele viidates nimetatakse seda ka domeeniks) ja tundlikkuse tase või kategooria.
Praktikas on kõige kriitilisem element tüüp (kolmas väli), kuna valdav enamus poliitikareegleid on sõnastatud tüüpide vaheliste seostena . Näiteks lubades httpd_t tüüpi protsessidel juurde pääseda failidele, millel on silt httpd_sys_content_t, või lubades kindlal domeenil suhelda soklitega, millel on silt http_port_t.
Need kontekstid salvestatakse kujul laiendatud failisüsteemi atribuudidSeetõttu on oluline kasutada failisüsteeme, mis toetavad xattr-e (näiteks ext4, XFS jne). Protsesside puhul avaldatakse praegune kontekst ja muud seotud kontekstid pseudofailisüsteemi kaudu. /proc/<pid>/attr/ sellistes failides nagu current, exec, fscreate, prev, sockcreate või keycreate.
Tüüpilised näited kontekstidest sihipärase poliitikaga süsteemis oleksid:
- system_u:object_r:httpd_sys_content_t:s0 Apache või Nginxi pakutava veebisisu jaoks.
- system_u:object_r:home_user_t:s0 kasutaja kodukataloogide jaoks.
- system_u:system_r:httpd_t:s0 veebiserveri enda täitmisdomeeni jaoks.
SELinuxi konteksti komponentide lahtivõtmine
Kui puutute kokku sellise kontekstiga nagu unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 , võib see tunduda hieroglüüfidena, kuid iga osa vastab SELinuxi konkreetsele kontseptsioonile ja selle viitepoliitikale.
El SELinuxi kasutaja (kokkuleppeliselt järelliitega) _uSee ei ole sama mis Unixi kasutaja failis /etc/passwd. SELinux haldab oma kasutajate andmebaasi ja seob need Linuxi kasutajatega. SELinuxi kasutaja saab grupeerida mitu Unixi kasutajat, sest idee seisneb selles, et MAC-kiht oleks DAC-ist sõltumatu.
El SELinuxi roll (järelliitega _rSee määratleb, milliseid rolle kasutaja või domeen saab kasutada. Rangelt kasutades nimetatakse seda täielikuks RBAC-iks. Enamik failiobjekte kasutab rolli object_r, samas kui rollid nagu system_r, user_r, staff_r või sysadm_r rakendatakse protsessidele olenevalt turvakontekstist, mida nad peavad omama.
El SELinuxi tüüp või domeen (järelliide _tPraktikas on tüüp ülioluline element. Tüüp kirjeldab objekti klassi või protsessi täitmisdomeeni. Poliitika määrab, millised interaktsioonid on tüüpide vahel lubatud: millised domeenid saavad lugeda, kirjutada, käivitada või suhelda millist tüüpi objektidega.
Tasemeid ja kategooriaid kasutatakse siis, kui on lubatud mitmetasemelise turbe (MLS) või mitmekategoorialise turbe (MCS) poliitikad. Tundlikkused on hierarhilised (nt s0, s1 jne), kategooriad aga mitte (c0, c1, c2 jne). Väga kriitilistes keskkondades – näiteks teatud valitsusasutustes – kasutatakse neid tagamaks, et andmeid saab lugeda ja kirjutada ainult samale tasemele või ülespoole , ning andmete isoleerimiseks väga spetsiifiliste sektsioonide järgi.
SELinuxi poliitikad: sihipärased, ranged, MLS/MCS ja modulaarsus
SELinuxi poolt rakendatava turvalisuse määrab laaditud poliitika . Poliitika on lihtsalt suur reeglite kogum, mis kirjeldab, millised domeenid saavad milliste tüüpide ja muude elementide puhul mida teha. Distributsioonid pakuvad tavaliselt standardseid poliitikaid, nii et te ei pea kõike nullist kirjutama.
Kõige levinumat poliitikat nimetatakse suunatud poliitikaks . Selles režiimis töötavad piiratud domeenides ainult kindlad protsessid – peamiselt võrguteenused ja kõrge riskiga deemonid nagu Apache, Nginx, DNS, puhverserverid, SNMP, syslog jne. Kõik muud kasutajaprotsessid töötavad "piiramata" domeenides, kus rakendatakse sisuliselt standardset Linuxi turvalisust koos teatud toimingute logimisega.
Samuti on olemas range poliitika , mille puhul praktiliselt kõik protsessid on piiratud kindla poliitikaga. See on palju turvalisem, kuid seda võib olla ka oluliselt raskem hallata, kui mudelit hästi ei mõisteta, sest igasugune lahknevus märgistuses või reeglites võib häirida standardseid töövooge.
Kõrgendatud turvalisusega keskkondade jaoks on olemas MLS/MCS (mitmetasemeline/mitmekategoorialine turvalisus) poliitikad , mis kasutavad tundlikkust ja kategooriaid veelgi täpsemate kontrollimeetmete kehtestamiseks. Need on tüüpilised väga jäikadele sõjaväe- või halduskeskkondadele ning neid kasutatakse harva väljaspool konkreetseid kontekste nende suure operatiivse keerukuse tõttu.
Kaasaegsed poliitikad on jaotatud modulaarselt . Ühe monoliitse poliitikafaili asemel kasutatakse konkreetsete teenuste jaoks eraldi mooduleid, mis lihtsustab oluliselt haldust ja värskendusi. Neid mooduleid hallatakse selliste tööriistadega nagu semodule ja semanage module , mis võimaldavad teil poliitika osi installida, eemaldada, lubada või keelata ilma kogu poliitikat iga kord uuesti kompileerimata.
Kuidas SELinux otsustab: subjektid, objektid, klassid ja õigused
Kui protsess (subjekt) üritab juurde pääseda ressursile (objektile), esitab SELinux kontseptuaalselt küsimuse: "Kas X-tüüpi domeen saab sooritada toimingut Y C-klassi kuuluva Z-tüüpi objektiga?" . Seejärel otsitakse vastust poliitikast määratletud reeglite kaudu.
Tüübijärelevalve (TE) poliitikates, mida kasutab enamik distributsioone ja Android, kuulub iga objekt klassi ( fail, kaust, fifo_fail, tcp_socket, protsess jne) ja poliitika määratleb, millised õigused on iga klassi jaoks võimalikud: lugemine, kirjutamine, käivitamine, sidumine, ühenduse loomine, getattr, avamine ja pikk käsk jne.
TE reeglid on väga otsekoheselt väljendatud. Lihtne näide oleks:
luba httpd_t http_port_t:tcp_socket nimi_sidumine;
Selle reegliga näitab poliitika, et httpd_t domeeni protsessid saavad teostada name_bind toimingu TCP soklitel sildiga http_port_t. Lähenemisviis keskendub objektitüüpidele ja klassidele, mitte konkreetsetele teedele , mis hoiab ära üllatused failide teisaldamisel või kataloogistruktuuride muutmisel.
Näiteks Androidis kasutatakse SELinuxi atribuute tüüpide rühmitamiseks üldisemate siltide (nt `appdomain`) alla , nii et üks reegel saab kehtida mitmele domeenile (`untrusted_app`, `isolated_app` jne) ilma definitsioone kordamata. Makrosid (nt `rw_file_perms`) kasutatakse ka mitme levinud failiõiguse rühmitamiseks ja möödalaskmistest tingitud vigade vähendamiseks.
Sisemised staatused, AVC ja keeldumiste register
Juurdepääsutaotluse esitamisel konsulteerib SELinux kõigepealt juurdepääsuvektori vahemäluga (AVC) , mis on vahemälu, mis salvestab hiljutised juurdepääsuotsused protsessi kiirendamiseks. Kui otsus on juba vahemälus, kasutatakse seda otse; vastasel juhul esitatakse päring tulemüürile (SELinuxi sisemine osa kernelis), mis hindab toimingut poliitika ning subjekti ja objekti konteksti põhjal.
Kui puudub reegel, mis otseselt lubab taotletud toimingut, on vaikimisi otsus keelata . See "vaikimisi keelamise" filosoofia on üks SELinuxi alustalasid ja see annab sellele vastupidavuse lubavatele konfiguratsioonivigadele.
Kui jõustamisrežiimis toimub keeldumine, logib kernel tüüpi teate avc: keelatud süsteemilogides. Sõltuvalt levitamisest võib see ilmuda /var/log/audit/audit.logsisse /var/log/messages või jäädvustada auditd deemon. Need sõnumid sisaldavad protsessi konteksti (scontext), objekti konteksti (tcontext), klassi, taotletud toimingut ja muid silumiseks väga kasulikke andmeid.
Lubavas režiimis on toiming lubatud, kuid sündmus „avc: denied“ genereeritakse ikkagi , mis on tähistatud väärtusega permissive=1. See on poliitikate loomiseks ja kohandamiseks puhas kuld, sest see võimaldab teil näha, mis süsteemi lõhkuks, kui jõustamine rakendataks normaalset tööd katkestamata.
SELinuxi integreerimine distributsioonidesse ja Androidi
Linuxi serveri ja töölaua ökosüsteemis on SELinux vaikimisi lubatud Fedora, RHEL, CentOS ja derivaadidDebian ja Ubuntu pakuvad oma kernelites ja pakettides täielikku tuge, kuigi aktiveerimine on tavaliselt valikuline ja nõuab selliste pakettide nagu selinux-basics, selinux-policy-default ja auditd installimist, millele järgneb globaalne ümbersildistamine fixfiles relabel.
Android integreeris SELinuxi algselt versioonis 4.3 lubavas režiimis, läks üle osalisele kasutamisele versioonis 4.4 (ainult kriitiliste domeenide, näiteks installd, netd, vold ja zygote jaoks) ning on olnud täielikult integreeritud alates Android 5.0-st . Androidi poliitika keskendub rakenduste, süsteemiteenuste ja tundlike protsesside isoleerimisele tüüpide ja atribuutide abil, eesmärgiga minimeerida ohustamise mõju mis tahes neist komponentidest.
Android kasutab tavaliste rakendusprotsesside jaoks selliseid kontseptsioone nagu tüüp „untrusted_app”, rakenduste domeenide rühmitamiseks atribuudid „appdomain” ja andmete isoleerimiseks rakenduste ja füüsiliste kasutajate vahel MLS/MCS kategooriad. Kõik see toimib koos, et takistada ohustatud rakendusel oma liivakastist väljumist, isegi kui see saab väga laialdased kasutajaõigused.
Tähtis: Android lihtsustab SELinuxi mudelit, ignoreerides kasutajaid, rolle ja täpsemaid tundlikkusi. SELinuxi kasutajaid on ainult üks (u), kaks põhirolli (r subjektide ja object_r objektide jaoks) ning tundlikkus on alati s0. Kategooriad on need, mis määravad andmete isoleerimise.
Võrdlus AppArmori ja teiste LSM-idega
Paljudes aruteludes kerkib paratamatult esile SELinuxi ja AppArmori võrdlus , kuna mõlemad on Linuxi turvamoodulid ja pakuvad MAC-e. Nende lähenemisviisid on aga üsna erinevad ja enne oma keskkonna jaoks ühe või teise valimist tasub seda mõista.
SELinux defineerib poliitika, mis keskendub objektidele ja nende tüüpidele: igale süsteemi objektile (failid, protsessid, soklid, pordid, seadmed, IPC-d jne) määratakse silt. Juurdepääsuotsused tehakse subjekti ja objekti konteksti põhjal, sõltumata täpsest failiteest. See muudab süsteemi stabiilsemaks kataloogistruktuuri muutuste või alternatiivsete failisüsteemi vaadete (chroot, konteinerid, bind mounts jne) korral.
AppArmor seevastu rakendab ülesandekeskset ja teepõhist poliitikat. See määratleb iga programmi profiilid, täpsustades, millistele failiteedele, portidele jne see juurde pääseb ja milliste õigustega. See on intuitiivsemalt konfigureeritav ja üldiselt kasutajasõbralikum administraatoritele, kes ei soovi SELinuxi ekspertideks saada, kuid selle juhtimine on mõnevõrra vähem detailne ja sõltub rohkem failisüsteemi struktuurist.
Mõlemad jagavad vaikimisi keelamise põhimõtet, kuid rakendavad seda erinevalt: AppArmor keelab vaikimisi ainult need ülesanded, mida see profiilidega katab, samas kui SELinux laiendab seda ranges režiimis kogu süsteemile ja kõigile sildistatud objektidele. Seetõttu pakub SELinux tavaliselt sügavamat piiramise taset ulatuslikuma ja keerukama poliitika hinnaga.
Praktilised tööriistad SELinuxi haldamiseks
SELinuxiga töötamine tugineb reale käsurea tööriistadele, mis lihtsustavad režiimide, sildistamise, tõeväärtuste ja poliitikamoodulite haldamist. Kuigi see võib alguses tunduda üle jõu käiva arsenalina, hõlmavad mõned utiliidid enamikku igapäevaseid ülesandeid.
Failide ja protsesside turbekonteksti vaatamiseks saate kasutada valikut -Z tavalistes käskudes nagu ls, ps või id. Näiteks ls -Z Lisaks DAC-õigustele näitab see iga faili SELinuxi konteksti, mis võimaldab teil kiiresti kontrollida, kas sildistamine on ootuspärane.
Käsk `chcon` ("change context") võimaldab käsitsi muuta kogu faili konteksti või ainult teatud osi (roll, tüüp, vahemik), kasutades selliseid valikuid nagu `-r`, `-to` ja `-l`. See on kasulik ühekordsete paranduste tegemiseks, kuid oluline on meeles pidada, et muudatused võivad kaduma minna, kui sildistust rakendatakse uuesti vastavalt poliitikale selliste tööriistade abil nagu `restorecon` või `fixfiles`.
Semanage'i tööriist on käitusaja poliitika haldamise Šveitsi armee nuga. Erinevate alamkäskude abil saate hallata püsivaid failikontekste (fcontext), sisselogimise seoseid Linuxi ja SELinuxi kasutajate vahel (login), SELinuxi kasutajaid ja nende rolle (user), sildistatud porte (port), tõeväärtusi ja isegi poliitikamooduleid. Kõik see ilma, et peaksite kogu poliitikat lähtekoodist uuesti kompileerima.
Tõeväärtuste (väikesed lülitid, mis lubavad või keelavad poliitikas reegleid) oleku kontrollimiseks ja muutmiseks kasutatakse lisaks setsebool-tõeväärtusele endale ka getsebool ja setsebool . Tüüpiline tõeväärtus on httpd_enable_homedirs, mis aktiivsena lubab veebiserveril juurde pääseda kasutajate kodukataloogidele (kasulik ~user/public_html/ puhul).
Lõpuks võimaldavad käsud nagu fixfiles teil sundida failisüsteemi täielikku ümbermärgistamist vastavalt määratletud reeglitele ja semodule hoolitseb poliitikamoodulite (.pp) installimise, loetlemise, lubamise või keelamise eest, mis on pakendatud ja levitatud viitepoliitika või administraatori poolt.
Kohandatud poliitikate loomine ja kohandamine
Kui rakendusel pole oma SELinuxi moodulit või vajate täpsemat piirangut, on aeg asja kallale asuda ja luua kohandatud poliitikad . See võib tunduda keeruline, kuid töövoog on üsna hästi määratletud, kui järgite teatud samme hoolikalt.
Esimene samm on tagada, et asjakohased objektid (käivitatavad failid, andmekataloogid, soklid jne) oleksid märgistatud sobivate tüüpidega. Seda saab saavutada faili kontekstireeglite määratlemisega ` semanage fcontext` abil ja nende rakendamisega `restorecon` abil, kasutades regulaaravaldisi tervete kataloogipuude hõlmamiseks.
Seejärel lülitatakse süsteem tavaliselt selle masina (või mõnel juhul konkreetse domeeni) jaoks lubavasse režiimi ja rakendusel lubatakse normaalselt töötada, samal ajal kui SELinux logib kõik ` avc: denied` laused , mis oleksid võinud esineda. Neid logisid, mida tavaliselt analüüsitakse selliste tööriistadega nagu audit2allow , kasutatakse kandidaatreeglite eraldamiseks.
Viitepoliitikad on tavaliselt struktureeritud kolme failina rakenduse kohta: .te-fail, mis sisaldab TE-reegleid (luba, tüüp, domeenitüüp jne), .fc-fail, mis sisaldab faili kontekstireegleid, ja .if-fail, mis sisaldab avalikke liideseid, mida teised moodulid saavad taaskasutada. Kõik see kompileeritakse make abil .pp-mooduliteks ja laaditakse semodule abil.
On ülioluline mitte pimesi usaldada kõike, mida audit2allow soovitab: see kipub olema lubavam kui hädavajalik . Ideaalis peaksite soovitatud reeglid käsitsi üle vaatama, looma vajadusel uusi tüüpe, et eraldada tundlikud andmed ebaolulistest andmetest, ja kui keelatud toiming pole kriitiline, kaaluma dontaudit-reeglite kasutamist, et peatada müra salvestamine ilma lubasid andmata.
Sellistes keskkondades nagu SUSE Linux Micro või Android pakutakse lisatööriistu (näiteks Udica konteineripoliitikate genereerimiseks JSON-kirjelduste põhjal), mis automatiseerivad osa protsessist, kohandades poliitikat kiiresti konkreetsetele konteineritele ilma kogu poliitikakeelt nullist õppimata.
See kontekstide, modulaarsete poliitikate, tõeväärtuste ja haldustööriistade ökosüsteem muudab SELinuxi äärmiselt töökindlaks ja paindlikuks turvaplatvormiks . Mõningase esialgse investeeringuga õppimisse võimaldab see iga teenuse või rakenduse võimeid väga täpselt piirata, tugevdades oluliselt süsteemi rünnakupinda ärakasutamise, pahavara ja inimlike vigade eest.
