Root i en terminal, nekad under SELinux: varför hooken misslyckas

Du kör up-skriptet som root, det slutförs, och samma skript misslyckas när tjänsten anropar det. Ingenting i filbehörigheterna har ändrats, så det naturliga nästa steget är att lätta på dem igen, vilket inte rättar något. På en SELinux-värd är den avgörande faktorn ofta inte vem processen är, utan i vilken domän den kör, och root inne i en begränsad domän är fortfarande begränsad.

Samma kommando, två olika säkerhetsdomäner

Typgenomdrivning bedömer källdomänen, måletiketten och den begärda åtgärden tillsammans. Din terminalsession körs i en obegränsad eller administrativ domän, och daemonen körs i den domän som tilldelats dess enhet. Identiska kommandon ger därför olika beslut, och skillnaden är avsiktlig och inte en bugg i policyn.

Därför är jämförelsen av de två körningarna bara användbar om du jämför deras sammanhang. Kör samma kommando från skalet och från hooken, och skalversionen bevisar att binärfilen finns och att argumenten stämmer; den bevisar ingenting om tjänsten får köra den. Kör den båda vägarna och jämför domänerna, inte bara utgångskoderna. Det är den jämförelsen som förvandlar ett vagt behörighetsklagomål till en konkret fråga om en domän och en etikett.

Den klassiska formen av det här felet är en hjälpare som anropar ett externt verktyg. Själva hooken kan vara tillåten, medan verktyget den anropar bär en etikett som tjänstedomänen inte får köra, eller skriver till en katalog vars etikett förbjuder det.

Läs AVC-posten bredvid hook-felet

En AVC-nekning namnger fälten som avgör ärendet: processens källkontext, objektets målkontext, objektklassen och den specifika behörighet som nekades. Läs alla fyra innan du bildar en teori, eftersom en nekning på execute och en nekning på write har helt olika åtgärder.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

Källkontexten bör stämma med den domän som tjänsten faktiskt kör i, och målkontexten med etiketten för filen eller katalogen som åtgärden rörde. Om någon av dem inte stämmer med felet du jagar läser du en annan händelse.

Notera policyversionen och den exakta sökvägen till den körbara filen bredvid posten. Ett domännamn som förekommer i en distributions policy är bevis om den installationen, inte en garanti för att en annan byggnad levererar samma regler. Det är den kontexten som gör att någon annan kan återupprepa din slutsats på sin egen värd. Utan den läses posten som en anekdot och inte som bevis.

Etikett, konfiguration eller policy: tre åtgärder

Den första åtgärden är en etikett som inte stämmer med filens installerade plats. Ett skript som kopierats på plats med cp eller skrivits av en editor kan bära en standardetikett som tjänstedomänen inte kan använda, och att återställa den förväntade kontexten rättar det utan att röra policyn.

Den andra är konfiguration. Distributionen erbjuder kanske ett stödd sätt att köra åtgärden, en dokumenterad katalog för hjälparen eller ett uppdaterat policypaket som redan tillåter det. Att ändra din layout till den stödda är billigare än att skriva policy och överlever uppdateringar.

Den tredje är en regel som verkligen saknas, och den bör vara den sista utvägen. Generera en kandidat med granskningsverktygen, läs vad den faktiskt tillåter, begränsa den till åtgärden och domänen du observerade, och låt någon annan granska den innan den närmar sig produktion.

Varför en gammal allow-modul inte är svaret

Sökresultaten för det här felet är fulla av färdiga moduler, ofta för ett verktyg som hooken inte längre anropar. Att installera en ger behörigheter som kanske inte har något med din nekning att göra, och den låter den verkliga obalansen stå kvar samtidigt som den lägger till ett permanent hål.

Den döljer också nästa fel. En modul som tillåter en bred klass av åtgärder får det här felet att försvinna och gör nästa till något mycket svårare att härleda. Att ta bort modulen senare är också en ändring ingen vill schemalägga, så genvägen tenderar att bli permanent.

Den disciplinerade jämförelsen är mellan den nekning du kan läsa och den ändring du föreslår. Red Hats vägledning för felsökning av SELinux sätter etikett- och konfigurationskontroller före genererad policy just av den anledningen. Om det inte finns en motsvarande nekning i posten är SELinux förmodligen inte ditt problem, och problem med sökväg, sandbox eller behörigheter är fortfarande öppna.