SELinux Security: Kontrolloni sistemin tuaj Linux deri në milimetër

Informatec Digital » Burime » SELinux Security: Kontrolloni sistemin tuaj Linux deri në milimetër

SELinux mund të duket si teknologji e rezervuar për ata që e kanë idenë e kernel-it, por në fakt është një nga mjetet më të fuqishme të sigurisë që ofrohen sot në Linux . Nëse menaxhoni servera, siguri kontejnerësh Docker , infrastrukturë cloud ose edhe kompjuterë desktop paksa të ndjeshëm, të kuptuarit se si funksionon SELinux bën gjithë ndryshimin midis një sistemi që është thjesht "i konfiguruar mirë" dhe një sistemi që është i vështirë për t'u kompromentuar, madje edhe me dobësi zero-day.

Pavarësisht reputacionit të tij si "i ndërlikuar", SELinux ofron një model shumë logjik: ai përcakton se çfarë mund të bëjë secili proces dhe me cilat objekte mund të komunikojë, dhe nëse diçka devijon nga ai skript, kerneli e ndalon atë menjëherë . Në vend që të besojë verbërisht se rrënja do të sillet mirë ose se daemonët tuaj nuk do të kenë gabime, SELinux zbaton kontrollin e detyrueshëm të aksesit që zbatohet edhe për superpërdoruesin, duke përdorur etiketa dhe politika shumë të detajuara.

Çfarë është SELinux dhe çfarë problemi zgjidh?

Linux i Përmirësuar me Siguri (SELinux) është një modul sigurie i bërthamës Linux bazuar në LSM (Linux Security Modules). Fillimisht u zhvillua nga NSA në bashkëpunim me Red Hat dhe partnerë të tjerë, dhe që nga versioni 2.6 i bërthamës, ka qenë një pjesë zyrtare e bërthamës. Nuk është një aplikacion i veçantë, por më tepër një zgjerim i bërthamës që shton një sistem kontrolli të detyrueshëm të aksesit (MAC) dhe kontroll aksesi të bazuar në role (RBAC).

Ndryshe nga kontrolli klasik i aksesit diskrecionar (DAC) i Unix - pronari , grupi, të tjerët dhe lejet rwx - në SELinux, vendimet për akses nuk bazohen në zgjedhjen e pronarit të skedarit, por në një politikë globale të përcaktuar nga administratori i sigurisë. DAC është ende i pranishëm dhe ka përparësi: nëse DAC refuzon, SELinux nuk ndërhyn; por edhe nëse DAC lejon, SELinux mund ta bllokojë ende operacionin sipas politikës së tij.

Arkitektura SELinux i ndan qartë komponentët: nga njëra anë, kodin e bërthamës që merr vendime për sigurinë , dhe nga ana tjetër, modulet e politikave që përcaktojnë se çfarë lejohet dhe çfarë jo. Kjo ndarje lejon rregullimin e rregullave pa rikompiluar bërthamën dhe thjeshton numrin e komponentëve që mund të ndikojnë në sigurinë e sistemit.

SELinux është adoptuar si parazgjedhje në shpërndarje të tilla si Fedora, Red Hat Enterprise Linux, CentOS dhe Scientific Linux, dhe është gjithashtu thellësisht i integruar në sisteme si Android, ku përdoret për të kufizuar proceset dhe aplikacionet e sistemit në domene shumë specifike. Në botën e BSD dhe GNU/Linux, ekzistojnë alternativa të tilla si AppArmor, TOMOYO dhe TrustedBSD (në macOS/FreeBSD), por SELinux dallohet për nivelin e granularitetit që ofron mbi të gjitha objektet e sistemit.

Nga DAC në MAC: pse modeli klasik nuk është më i mjaftueshëm

Në një sistem tradicional Unix, modeli Domain-Object menaxhohet duke përdorur DAC: çdo skedar ose burim ka një pronar dhe leje, dhe çdo proces që funksionon si ai përdorues mund të bëjë çfarë të dëshirojë me ato burime . Kjo do të thotë që nëse një daemon funksionon si root, çdo gabim i shfrytëzueshëm mund të hapë derën për të kontrolluar gjysmën e sistemit me kontekstin e tij root.

Shembuj tipikë përfshijnë bazat e të dhënave, skedarët e të dhënave të të cilave duhet të manipulohen vetëm përmes DBMS-së, por që në të vërtetë janë të lexueshme dhe të modifikueshme nga proceset me UID rrënjë ; ose daemonë kritikë që funksionojnë me privilegje të tepërta. Një gabim programimi, një mbingarkesë buffer-i ose një validim i dobët i të dhënave hyrëse mund ta shndërrojnë shërbimin në një autostradë për të gjithë sistemin.

SELinux shton një shtresë të Kontrollit të Qasjes së Detyrueshme (MAC) sipër DAC. "I detyrueshëm" do të thotë që kontrolli i qasjes përcaktohet në mënyrë qendrore nga administratori përmes politikave, dhe as përdoruesit dhe as proceset nuk mund t'i zbutin këto rregulla vetë. Sistemi operativ i zbaton këto politika duke vlerësuar çdo operacion përkatës të bërthamës përpara se ta lejojë atë.

Bërthama, duke përdorur grepa LSM, pyet SELinux-in në çdo thirrje të ndjeshme të sistemit (hapja e skedarëve, krijimi i socket-eve, montimi i sistemeve të skedarëve, komunikimi nëpërmjet IPC-së, etj.). Në çdo pikë vendimmarrjeje, SELinux vlerëson operacionin bazuar në politikën e ngarkuar dhe kontekstin e sigurisë së subjektit dhe objektit . Nëse politika nuk jep leje në mënyrë të qartë, veprimi mohohet, pavarësisht nëse procesi është root apo jo.

Mënyrat e funksionimit: zbatuese, lejuese dhe të çaktivizuara

SELinux mund të funksionojë në tre gjendje operative të diferencuara qartë, të cilat janë të rëndësishme për t'u kuptuar për të shmangur çmendjen në prodhim:

• zbatimin eSELinux është aktivizuar dhe e zbaton plotësisht politikën. Të gjitha veprimet që nuk lejohen nga rregullat bllokohen dhe regjistrohen.
• LejueseSELinux është aktiv, ngarkon politikën dhe etiketon sistemin e skedarëve, por nuk bllokon Ai regjistron vetëm transaksionet sikur të ishin refuzuar. Kjo është ideale për korrigjimin e gabimeve dhe rregullimin e politikave.
• I paaftëSELinux është çaktivizuar. Nuk zbatohen politika dhe nuk kryhet asnjë etiketim. Sistemi mbështetet në modelin klasik DAC.

Për ndryshime të shpejta dhe të përkohshme midis modaliteteve zbatuese dhe lejuese, përdoret komanda `setenforce` , ku modaliteti specifikohet si 0 (lejues) ose 1 (zbatues). Është e rëndësishme të dini se ky ndryshim është i paqëndrueshëm: pas rinisjes së radhës, modaliteti do të kthehet në atë të përcaktuar në konfigurim.

Nëse keni nevojë për një ndryshim të përhershëm, duhet ta modifikoni skedarin. /etc/selinux/config (ose /etc/sysconfig/selinux në disa shpërndarje) dhe rregulloni vlerën e direktivës SELINUX=disabled|permissive|enforcingNdryshimet do të zbatohen në nisjen tjetër dhe, në shumë raste, do të përfshijnë riemërtimin e sistemit të skedarëve.

Për të kontrolluar modalitetin aktiv, mund të përdorni komanda si getenforce ose sestatus . E para thjesht kthen Enforcing, Lejuese ose Disabled; e dyta ofron një përmbledhje më të plotë të statusit të SELinux, politikave të ngarkuara dhe moduleve aktive.

Kontekstet e sigurisë dhe sistemi i etiketimit

Zemra e SELinux është sistemi i tij i etiketave ose konteksteve të sigurisë . Çdo skedar, proces, port rrjeti, soket, pajisje, etj., ka një kontekst të shoqëruar që përshkruan se si mund të përdoret. Ky kontekst përbëhet nga disa fusha që së bashku formojnë pamjen e SELinux për atë objekt.

Formati i përgjithshëm i një konteksti është user_u:role_r:type_t:level , me disa nuanca në varësi të politikës (veçanërisht nëse përdoret MLS/MCS). Çdo fushë ka një qëllim specifik: përdoruesin SELinux, rolin, llojin (i quajtur edhe domen kur i referohemi proceseve) dhe nivelin ose kategorinë e ndjeshmërisë.

Në praktikë, elementi më kritik është lloji (fusha e tretë), meqenëse shumica dërrmuese e rregullave të politikave formulohen si marrëdhënie midis llojeve . Për shembull, lejimi i proceseve të tipit httpd_t për të hyrë në skedarët e etiketuar httpd_sys_content_t, ose lejimi i një domeni specifik për të komunikuar me socket-et e etiketuara http_port_t.

Këto kontekste ruhen si atributet e zgjeruara të sistemit të skedarëvePrandaj, është thelbësore të përdoren sisteme skedarësh që mbështesin xattrs (si ext4, XFS, etj.). Në rastin e proceseve, konteksti aktual dhe kontekstet e tjera të lidhura ekspozohen përmes pseudo-sistemit të skedarëve. /proc/<pid>/attr/ në skedarë të tillë si current, exec, fscreate, prev, sockcreate ose keycreate.

Shembuj tipikë të konteksteve në një sistem me politika të synuara do të ishin:

• system_u:object_r:httpd_sys_content_t:s0 për përmbajtjen e uebit të shërbyer nga Apache ose Nginx.
• system_u:object_r:home_user_t:s0 për drejtoritë kryesore të përdoruesve.
• system_u:system_r:httpd_t:s0 për domenin e ekzekutimit të vetë serverit web.

Zbërthimi i komponentëve të kontekstit SELinux

Kur hasni një kontekst si unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 , mund të duket si hieroglife, por çdo pjesë korrespondon me një koncept specifik brenda SELinux dhe politikës së tij të referencës.

El Përdorues i SELinux (sipas konventës me prapashtesë) _uKjo nuk është e njëjta gjë si përdoruesi i Unix në /etc/passwd. SELinux mirëmban bazën e të dhënave të vet të përdoruesve dhe i lidh ata me përdoruesit e Linux. Një përdorues i SELinux mund të grupojë disa përdorues të Unix, sepse ideja është që shtresa MAC të jetë e pavarur nga DAC.

El Roli i SELinux (me prapashtesë _rKjo përcakton rolet që mund të marrë një përdorues ose domen. Nëse përdoret në mënyrë strikte, quhet RBAC i plotë. Shumica e objekteve të skedarëve përdorin rolin object_r, ndërsa role si system_r, user_r, staff_r ose sysadm_r zbatohen në procese në varësi të kontekstit të sigurisë që duhet të marrin përsipër.

El Lloji ose domeni SELinux (prapashtesë _tNë praktikë, lloji është elementi thelbësor. Lloji përshkruan klasën e objektit ose domenin e ekzekutimit të një procesi. Politika specifikon se cilat ndërveprime lejohen midis llojeve: cilat domene mund të lexojnë, shkruajnë, ekzekutojnë ose komunikojnë me cilat lloje të tjera objektesh.

Nivelet dhe kategoritë përdoren kur aktivizohen politikat e sigurisë shumënivelëshe (MLS) ose shumëkategorishe (MCS). Ndjeshmëritë janë hierarkike (p.sh., s0, s1, etj.), ndërsa kategoritë jo (c0, c1, c2, ...). Në mjedise shumë kritike - për shembull, organizata të caktuara qeveritare - ato përdoren për të siguruar që të dhënat mund të lexohen vetëm poshtë dhe të shkruhen në të njëjtin nivel ose lart , dhe për të izoluar të dhënat sipas ndarjeve shumë specifike.

Politikat e SELinux: të synuara, të rrepta, MLS/MCS dhe modularitet

Siguria e zbatuar nga SELinux përcaktohet nga politika e ngarkuar . Një politikë është thjesht një grup i madh rregullash që përshkruajnë se cilat domene mund të bëjnë çfarë mbi cilat lloje, si dhe elementë të tjerë (tranzicione, rregulla etiketimi, etj.). Shpërndarjet zakonisht paketojnë politika standarde, kështu që nuk keni pse të shkruani gjithçka nga e para.

Politika më e zakonshme quhet target . Në këtë modalitet, vetëm procese specifike - kryesisht shërbime rrjeti dhe daemonë me rrezik të lartë si Apache, Nginx, DNS, proxy, SNMP, syslog, etj. - ekzekutohen brenda domeneve të kufizuara. Të gjitha proceset e tjera të përdoruesit ekzekutohen në domene "të pakufizuara", ku zbatohet në thelb siguria standarde e Linux-it, së bashku me regjistrimin e veprimeve të caktuara.

Ekziston edhe politika strikte , në të cilën praktikisht të gjitha proceset kufizohen sipas një politike specifike. Është shumë më e sigurt, por mund të jetë gjithashtu shumë më e vështirë për t'u mirëmbajtur nëse modeli nuk kuptohet mirë, sepse çdo mospërputhje në etiketim ose rregulla mund të prishë rrjedhat standarde të punës.

Për mjedise me siguri të lartë, ekzistojnë politika MLS/MCS (Siguri Shumënivelëshe/Shumëkategorish) që shfrytëzojnë ndjeshmëritë dhe kategoritë për të imponuar kontrolle edhe më të hollësishme. Këto janë tipike për mjedise ushtarake ose administrative shumë të ngurta dhe rrallë përdoren jashtë konteksteve specifike për shkak të kompleksitetit të tyre të lartë operacional.

Politikat moderne shpërndahen në një mënyrë modulare . Në vend të një skedari të vetëm monolit politikash, përdoren module të ndara për shërbime specifike, duke thjeshtuar shumë menaxhimin dhe përditësimet. Këto module menaxhohen me mjete si semodule dhe semanage module , të cilat ju lejojnë të instaloni, hiqni, aktivizoni ose çaktivizoni pjesë të politikës pa e rikompiluar të gjithë politikën çdo herë.

Si vendos SELinux: subjektet, objektet, klasat dhe lejet

Kur një proces (subjekti) përpiqet të hyjë në një burim (objektin), SELinux në mënyrë konceptuale ngre pyetjen: "A mund të kryejë një domen i tipit X operacionin Y në një objekt të tipit Z që i përket klasës C?" . Përgjigja kërkohet më pas në politikë përmes rregullave të përcaktuara.

Në politikat e Zbatimit të Tipit (TE), të cilat përdoren nga shumica e shpërndarjeve dhe Android, çdo objekt i përket një klase (file, dir, fifo_file, tcp_socket, process, etj.) dhe politika përcakton se cilat leje janë të mundshme për secilën klasë: read, write, execute, bind, connect, getattr, open dhe një long etj.

Rregullat TE shprehen shumë drejtpërdrejt. Një shembull bazë do të ishte:

lejo httpd_t http_port_t:tcp_socket name_bind;

Me këtë rregull, politika tregon se proceset në domenin httpd_t mund të kryejnë operacionin name_bind në socket-et TCP të etiketuara si http_port_t. Kjo qasje përqendrohet në llojet dhe klasat e objekteve, jo në shtigje specifike , gjë që parandalon surprizat gjatë zhvendosjes së skedarëve ose ndryshimit të strukturave të direktorive.

Në Android, për shembull, atributet SELinux përdoren për të grupuar llojet nën etiketa më të përgjithshme si `appdomain` , në mënyrë që një rregull i vetëm të mund të zbatohet në shumë domene (`untrusted_app`, `isolated_app`, etj.) pa përsëritur përkufizimet. Makrot si `rw_file_perms` përdoren gjithashtu për të grupuar disa leje të zakonshme të skedarëve dhe për të zvogëluar gabimet e shkaktuara nga mbikëqyrjet.

Statuset e brendshme, AVC dhe regjistri i mohimeve

Kur ndodh një kërkesë për akses, SELinux së pari konsultohet me Access Vector Cache (AVC) , një memorje të përkohshme që ruan vendimet e fundit të aksesit për të përshpejtuar procesin. Nëse vendimi është tashmë në memorje të përkohshme, ai përdoret direkt; përndryshe, pyetet firewall (pjesa e brendshme e SELinux në kernel), i cili vlerëson operacionin bazuar në politikën dhe kontekstin e subjektit dhe objektit.

Nëse nuk ka ndonjë rregull që lejon në mënyrë të qartë veprimin e kërkuar, vendimi i parazgjedhur është të mohohet . Kjo filozofi "moho automatikisht" është një nga shtyllat e SELinux dhe ajo që i jep atij qëndrueshmërinë kundër gabimeve të konfigurimit lejues.

Kur ndodh një mohim në modalitetin e zbatimit, kerneli regjistron një mesazh të tipit avc: e refuzuar në regjistrat e sistemit. Në varësi të shpërndarjes, mund të shfaqet në /var/log/audit/audit.logNë /var/log/messages ose të kapen nga demoni auditedd. Këto mesazhe përfshijnë kontekstin e procesit (scontext), kontekstin e objektit (tcontext), klasën, operacionin e kërkuar dhe të dhëna të tjera shumë të dobishme për debugging.

Në modalitetin lejues, operacioni lejohet, por ngjarja avc: denied gjenerohet ende , e shënuar me permissive=1. Kjo është flori i pastër për ndërtimin dhe rregullimin e politikave, sepse ju lejon të shihni se çfarë do ta prishte sistemin nëse zbatimi do të zbatohej pa ndërprerë funksionimin normal.

Integrimi i SELinux në shpërndarje dhe Android

Në ekosistemin e serverëve dhe desktopëve Linux, SELinux aktivizohet si parazgjedhje në Fedora, RHEL, CentOS dhe derivatet e tyreDebian dhe Ubuntu ofrojnë mbështetje të plotë në bërthamat dhe paketat e tyre, megjithëse aktivizimi është zakonisht opsional dhe kërkon instalimin e paketave të tilla si selinux-basics, selinux-policy-default dhe auditedd, të ndjekura nga rietiketimi global me fixfiles relabel.

Android fillimisht e përfshiu SELinux në versionin 4.3 në modalitetin lejues, kaloi në përdorim të pjesshëm në versionin 4.4 (vetëm për domenet kritike si installd, netd, vold dhe zygote) dhe është integruar plotësisht që nga Android 5.0 . Politika e Android përqendrohet në izolimin e aplikacioneve, shërbimeve të sistemit dhe proceseve të ndjeshme duke përdorur lloje dhe atribute, duke synuar minimizimin e ndikimit të një kompromisi në cilindo prej këtyre komponentëve.

Android përdor koncepte si lloji untrusted_app për proceset e zakonshme të aplikacioneve, atributet e domenit të aplikacioneve për të grupuar domenet e aplikacioneve dhe kategoritë MLS/MCS për të izoluar të dhënat midis aplikacioneve dhe midis përdoruesve fizikë. E gjithë kjo funksionon së bashku për të parandaluar që një aplikacion i kompromentuar të dalë nga sandbox-i i tij, edhe nëse merr leje shumë të gjera përdoruesish.

E rëndësishme: Android e thjeshton modelin SELinux duke injoruar përdoruesit, rolet dhe ndjeshmëritë e avancuara. Ekziston vetëm një përdorues SELinux (u), dy role bazë (r për subjektet dhe object_r për objektet) dhe ndjeshmëria është gjithmonë s0. Kategoritë janë ato që bëjnë diferencën për izolimin e të dhënave.

Krahasimi me AppArmor dhe LSM të tjera

Në shumë diskutime, krahasimi midis SELinux dhe AppArmor lind në mënyrë të pashmangshme , pasi të dy janë module sigurie Linux dhe ofrojnë MAC. Megjithatë, qasjet e tyre janë mjaft të ndryshme, dhe ia vlen ta kuptoni këtë përpara se të zgjidhni njërën ose tjetrën për mjedisin tuaj.

SELinux përcakton një politikë të përqendruar në objekte dhe llojet e tyre: çdo objekti në sistem (skedarë, procese, socket-e, porta, pajisje, IPC, etj.) i caktohet një etiketë. Vendimet për akses merren bazuar në kontekstet e subjektit dhe objektit, pa u varur nga shtegu i saktë i skedarit. Kjo e bën sistemin më të qëndrueshëm përballë ndryshimeve në strukturën e direktorive ose pamjeve alternative të sistemit të skedarëve (chroot, kontejnerë, montime bind, etj.).

AppArmor, nga ana tjetër, zbaton një politikë të përqendruar te detyrat dhe të bazuar në shteg. Ai përcakton profilet për secilin program, duke specifikuar se cilat shtigje skedarësh, porta etj., mund të hyjë dhe me çfarë lejesh. Është më intuitiv për t'u konfiguruar dhe në përgjithësi më miqësor për përdoruesit për administratorët që nuk duan të bëhen ekspertë në SELinux, por kontrolli i tij është disi më pak i detajuar dhe më i varur nga struktura e sistemit të skedarëve.

Të dy ndajnë parimin e mohimit si parazgjedhje, por e zbatojnë ndryshe: AppArmor mohon si parazgjedhje vetëm detyrat që mbulon me profile, ndërsa SELinux, kur është në modalitet të rreptë, e zgjeron atë në të gjithë sistemin dhe të gjitha objektet e etiketuara. Si rezultat, SELinux zakonisht ofron një nivel më të thellë kufizimi , me koston e një politike më të gjerë dhe komplekse.

Mjete praktike për menaxhimin e SELinux

Puna me SELinux mbështetet në një sërë mjetesh të linjës së komandës që thjeshtojnë menaxhimin e modaliteteve, etiketimit, vlerave booleane dhe moduleve të politikave. Ndërsa kjo mund të duket si një arsenal i madh në fillim, disa shërbime mbulojnë shumicën e detyrave të përditshme.

Për të parë kontekstin e sigurisë së skedarëve dhe proceseve, mund të përdorni opsionin -Z në komandat e zakonshme si ls, ps ose id. Për shembull, ls -Z Përveç lejeve DAC, do të tregojë kontekstin SELinux të secilit skedar, duke ju lejuar të kontrolloni shpejt nëse etiketimi është siç pritet.

Komanda `chcon` ("ndrysho kontekstin") ju lejon të modifikoni manualisht të gjithë kontekstin e një skedari ose vetëm pjesë specifike (rol, lloj, diapazon) duke përdorur opsione të tilla si `-r`, `-to` dhe `-l`. Është e dobishme për korrigjime të njëhershme, por është e rëndësishme të mbani mend se ndryshimet tuaja mund të humbasin nëse etiketimi riaplikohet sipas politikës duke përdorur mjete si `restorecon` ose `fixfiles`.

Mjeti semanage është thika zvicerane e menaxhimit të politikave në kohën e ekzekutimit. Me nënkomanda të ndryshme, ju mund të menaxhoni kontekstet e skedarëve të përhershëm (fcontext), përputhjet e hyrjes midis përdoruesve të Linux dhe SELinux (hyrje), përdoruesit e SELinux dhe rolet e tyre (përdorues), portet e etiketuara (port), vlerat booleane dhe madje edhe modulet e politikave. E gjithë kjo pa pasur nevojë të rikompiloni të gjithë politikën nga burimi.

Për të kontrolluar dhe ndryshuar gjendjen e vlerave booleane - çelësa të vegjël që aktivizojnë ose çaktivizojnë blloqe rregullash brenda politikës - përdoren getsebool dhe setsebool , përveç vetë vlerave booleane setsebool . Një vlerë booleane tipike është httpd_enable_homedirs, e cila, kur është aktive, i lejon serverit web të hyjë në drejtoritë kryesore të përdoruesve (e dobishme për ~user/public_html/).

Së fundmi, komandat si fixfiles ju lejojnë të detyroni një rietiketim të plotë të sistemit të skedarëve sipas rregullave të përcaktuara, dhe semodule kujdeset për instalimin, listimin, aktivizimin ose çaktivizimin e moduleve të politikave (.pp) të paketuara dhe të shpërndara nga politika referuese ose nga administratori.

Krijimi dhe përshtatja e politikave të personalizuara

Kur një aplikacion nuk ka modulin e vet SELinux ose keni nevojë për kufizime më specifike, është koha të filloni punën dhe të krijoni politika të personalizuara . Mund të duket e ndërlikuar, por rrjedha e punës është mjaft e përcaktuar mirë nëse ndiqni me kujdes hapa të caktuar.

Hapi i parë është të siguroheni që objektet përkatëse (ekzekutues, drejtori të dhënash, socket-e, etj.) janë etiketuar me llojet e duhura. Kjo mund të arrihet duke përcaktuar rregullat e kontekstit të skedarëve me ` semanage fcontext` dhe duke i zbatuar ato me `restorecon`, duke përdorur shprehje të rregullta për të përfshirë të gjitha pemët e drejtorive.

Sistemi më pas zakonisht vihet në modalitetin lejues për atë makinë (ose, në disa raste, për një domen specifik) dhe aplikacioni lejohet të funksionojë normalisht ndërsa SELinux regjistron të gjitha deklaratat `avc: denied` që do të kishin ndodhur. Këto regjistra, zakonisht të analizuara me mjete si audit2allow , përdoren për të nxjerrë rregullat kandidate.

Politikat e referencës zakonisht strukturohen në tre skedarë për çdo aplikacion: një skedar .te që përmban rregullat TE (allow, type, domain_type, etj.), një skedar .fc që përmban rregullat e kontekstit të skedarit dhe një skedar .if që përmban ndërfaqe publike që modulet e tjera mund t'i ripërdorin. E gjithë kjo kompilohet në module .pp duke përdorur make dhe ngarkohet me semodule.

Është shumë e rëndësishme të mos i besosh verbërisht gjithçkaje që sugjeron audit2allow: ai tenton të jetë më tolerant sesa është rreptësisht i nevojshëm . Idealisht, duhet të rishikosh manualisht rregullat e sugjeruara, të krijosh lloje të reja aty ku është e përshtatshme për të ndarë të dhënat e ndjeshme nga të dhënat e parëndësishme dhe, kur një operacion i refuzuar nuk është kritik, të marrësh në konsideratë përdorimin e rregullave dontaudit për të ndaluar regjistrimin e zhurmës pa dhënë leje.

Në mjedise të tilla si SUSE Linux Micro ose Android, ofrohen mjete shtesë (për shembull, Udica për të gjeneruar politika kontejnerësh nga përshkrimet JSON) që automatizojnë një pjesë të procesit duke e përshtatur shpejt politikën në kontejnerë specifikë pa pasur nevojë të mësoni të gjithë gjuhën e politikave nga e para.

I gjithë ky ekosistem kontekstesh, politikash modulare, vlerash booleane dhe mjetesh menaxhimi e bën SELinux-in një platformë sigurie jashtëzakonisht të fuqishme dhe fleksibile . Me disa investime fillestare në të nxënë, ai lejon kufizime shumë të sakta të asaj që mund të bëjë secili shërbim ose aplikacion, duke forcuar në mënyrë drastike sipërfaqen e sulmit të sistemit kundër shfrytëzimeve, programeve keqdashëse dhe gabimeve njerëzore.