Root në një terminal, i refuzuar nën SELinux: pse dështon hook
Një hook që funksionon në mënyrë të përsosur me dorë mund të refuzohet brenda shërbimit. Krahasoni domenin e procesit, etiketën e skedarit dhe lejen e refuzuar përpara se të modifikoni.
Ju e ekzekutoni skriptin up si root, ai përfundon, dhe i njëjti skript dështon kur shërbimi e thërret. Asgjë në lejet e skedarit nuk ka ndryshuar, kështu që hapi tjetër natyror është t'i lëshoni përsëri, gjë që nuk rregullon asgjë. Në një host SELinux faktori vendimtar shpesh nuk është kush është procesi, por në cilin domen ai ekzekutohet, dhe root brenda një domeni të kufizuar mbetet i kufizuar.
E njëjta komandë, dy domene të ndryshme sigurie
Zbatimi i llojeve vlerëson së bashku domenin burim, etiketën e synuar dhe operacionin e kërkuar. Sesioni juaj i terminalit ekzekutohet në një domen të pakufizuar ose administrativ, dhe daemoni ekzekutohet në domenin që i është caktuar njësisë së tij. Prandaj komandat identike japin vendime të ndryshme, dhe ndryshimi është i qëllimshëm dhe jo një defekt në politikë.
Kjo është arsyeja pse krahasimi i dy ekzekutimeve është i dobishëm vetëm nëse krahasoni kontekstet e tyre. Ekzekutoni të njëjtën komandë nga shell-i dhe nga hook, dhe versioni nga shell-i provon se binari ekziston dhe argumentet janë të sakta; nuk provon asgjë për atë nëse shërbimi ka leje ta ekzekutojë. Ekzekutojeni në të dyja mënyrat dhe krahasoni domenet, jo vetëm kodet e daljes. Është pikërisht ky krahasim që e kthen një ankesë të paqartë për leje në një pyetje të saktë për një domen dhe një etiketë.
Forma klasike e këtij defekti është një ndihmës që thërret një mjet të jashtëm. Vetë hook mund të jetë i lejuar, ndërsa mjeti që thërret mban një etiketë që domeni i shërbimit nuk mund ta ekzekutojë, ose shkruan në një drejtori etiketa e së cilës e ndalon këtë.
Lexoni regjistrin AVC pranë gabimit të hook
Një refuzim AVC emërton fushat që vendosin rastin: konteksti burim i procesit, konteksti i synuar i objektit, klasa e objektit dhe leja specifike që u refuzua. Lexoni të katërtat përpara se të formoni një teori, sepse refuzimi për ekzekutim dhe refuzimi për shkrim kanë rregullime plotësisht të ndryshme.
ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn
Konteksti burim duhet të përputhet me domenin në të cilin shërbimi ekzekutohet vërtet, dhe konteksti i synuar me etiketën e skedarit ose drejtorisë që preku operacioni. Nëse njëri prej tyre nuk përputhet me gabimin që po ndjek, po lexoni një ngjarje tjetër.
Shënoni pranë regjistrit versionin e politikës dhe shtegun e saktë të ekzekutuesit. Një emër domeni që shfaqet në politikën e një distribucioni është provë për atë instalim, jo garanci që një ndërtim tjetër sjell të njëjtat rregulla. Është pikërisht ky kontekst që i lejon dikujt tjetër të riprodhojë përfundimin tuaj në hostin e tij. Pa të, regjistri lexohet si anekdotë dhe jo si provë.
Etiketë, konfigurim ose politikë: tre rregullime
Rregullimi i parë është një etiketë që nuk përputhet me vendndodhjen e instaluar të skedarit. Një skript i kopjuar në vend me cp ose i shkruar nga një redaktues mund të mbajë një etiketë të parazgjedhur që domeni i shërbimit nuk mund ta përdorë, dhe rikthimi i kontekstit të pritur e rregullon këtë pa prekur fare politikën.
I dyti është konfigurimi. Distribucioni mund të ofrojë një mënyrë të mbështetur për të ekzekutuar operacionin, një drejtori të dokumentuar për ndihmësin ose një paketë politike të përditësuar që tashmë e lejon atë. Ndryshimi i paraqitjes tuaj në atë të mbështetur është më i lirë sesa shkrimi i politikës dhe i mbijeton përditësimeve.
I treti është një rregull vërtet që mungon, dhe duhet të jetë mjeti i fundit. Gjeneroni një kandidat me mjetet e auditimit, lexoni çfarë lejon në të vërtetë, kufizojeni në operacionin dhe domenin që keni vëzhguar, dhe kërkoni nga dikush tjetër ta shqyrtojë përpara se t'i afrohet prodhimit.
Pse një modul allow i vjetër nuk është përgjigjja
Rezultatet e kërkimit për këtë defekt janë plot me module të gatshme, shpesh për një mjet që hook nuk e thërret më. Instalimi i njërit jep leje që mund të mos kenë asnjë lidhje me refuzimin tuaj, dhe e lë mospërputhjen e vërtetë në vend ndërsa shton një vrimë të përhershme.
Ai fsheh edhe dështimin tjetër. Një modul që lejon një klasë të gjerë operacionesh do ta bëjë këtë gabim të zhduket dhe do ta kthejë atë tjetrin në diçka shumë më të vështirë për t'u atribuar. Heqja e modulit më vonë është gjithashtu një ndryshim që askush nuk dëshiron ta planifikojë, prandaj shkurtesa priret të bëhet e përhershme.
Krahasimi i disiplinuar është midis refuzimit që mund të lexoni dhe ndryshimit që propozoni. Udhëzuesi i Red Hat për zgjidhjen e problemeve të SELinux i vendos kontrollet e etiketimit dhe konfigurimit përpara politikës së gjeneruar pikërisht për këtë arsye. Nëse nuk ka refuzim përkatës në regjistër, SELinux me gjasë nuk është problemi juaj, dhe çështjet e shtegut, sandbox ose lejeve mbeten të hapura.