Root i en terminal, avvist under SELinux: hvorfor hooken feiler

Du kjører up-skriptet som root, det fullføres, og det samme skriptet feiler når tjenesten kaller det. Ingenting ved filrettighetene er endret, så det naturlige neste steget er å løsne dem igjen, noe som ikke retter noe. På en SELinux-vert er den avgjørende faktoren ofte ikke hvem prosessen er, men hvilket domene den kjører i, og root inne i et begrenset domene er fortsatt begrenset.

Samme kommando, to forskjellige sikkerhetsdomener

Typehåndhevelse vurderer kildedomenet, måletiketten og den forespurte operasjonen samlet. Økten din i terminalen kjører i et ubegrenset eller administrativt domene, og daemonen kjører i domenet som er tildelt enheten. Identiske kommandoer gir derfor forskjellige avgjørelser, og forskjellen er tilsiktet og ikke en feil i policyen.

Derfor er sammenligningen av de to kjøringene bare nyttig hvis du sammenligner kontekstene deres. Kjør den samme kommandoen fra skallet og fra hooken, og skallversjonen beviser at binæren finnes og at argumentene er riktige; den beviser ingenting om hvorvidt tjenesten har lov til å kjøre den. Kjør den begge veier og sammenlign domenene, ikke bare utgangskodene. Nettopp den sammenligningen gjør en vag tillatelsesklage om til et konkret spørsmål om ett domene og én etikett.

Den klassiske formen for denne feilen er en hjelper som kaller et eksternt verktøy. Selve hooken kan være tillatt, mens verktøyet den kaller, har en etikett som tjenestedomenet ikke har lov til å kjøre, eller skriver til en mappe hvis etikett forbyr det.

Les AVC-oppføringen ved siden av hook-feilen

En AVC-avvisning navngir feltene som avgjør saken: kildekonteksten til prosessen, målkonteksten til objektet, objektklassen og den spesifikke tillatelsen som ble avvist. Les alle fire før du danner en teori, fordi en avvisning på execute og en avvisning på write har helt forskjellige reparasjoner.

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

Kildekonteksten bør samsvare med domenet tjenesten faktisk kjører i, og målkonteksten med etiketten til filen eller mappen operasjonen berørte. Hvis en av dem ikke stemmer med feilen du jager, leser du en annen hendelse.

Noter policyversjonen og den nøyaktige stien til den kjørbare filen ved siden av oppføringen. Et domenenavn som forekommer i policyen til én distribusjon, er bevis om den installasjonen, ikke en garanti for at en annen bygging leverer de samme reglene. Det er denne konteksten som gjør at andre kan gjenta konklusjonen din på sin egen vert. Uten den leses oppføringen som en anekdote og ikke som bevis.

Etikett, konfigurasjon eller policy: tre reparasjoner

Den første reparasjonen er en etikett som ikke passer med filens installerte plassering. Et skript som er kopiert på plass med cp eller skrevet av en editor, kan bære en standardetikett som tjenestedomenet ikke kan bruke, og gjenoppretting av den forventede konteksten fikser det uten å røre policyen i det hele tatt.

Den andre er konfigurasjon. Distribusjonen tilbyr kanskje en støttet måte å kjøre operasjonen på, en dokumentert mappe for hjelperen eller en oppdatert policypakke som allerede tillater det. Å endre oppsettet ditt til det støttede er billigere enn å skrive policy og overlever oppdateringer.

Den tredje er en regel som virkelig mangler, og den bør være det siste midlet. Generer en kandidat med revisjonsverktøyene, les hva den faktisk tillater, snevre den inn til operasjonen og domenet du observerte, og få noen andre til å gjennomgå den før den kommer nær produksjon.

Hvorfor en gammel allow-modul ikke er svaret

Søkeresultatene for denne feilen er fulle av ferdige moduler, ofte for et verktøy som hooken ikke lenger kaller. Å installere én gir tillatelser som kanskje ikke har noe med avvisningen din å gjøre, og den lar den egentlige uoverensstemmelsen bli stående mens den legger til et permanent hull.

Den skjuler også den neste feilen. En modul som tillater en bred klasse operasjoner, vil få denne feilen til å forsvinne og gjøre den neste til noe mye vanskeligere å tilskrive. Å fjerne modulen senere er også en endring ingen vil planlegge, så snarveien har en tendens til å bli permanent.

Den disiplinerte sammenligningen er mellom avvisningen du kan lese og endringen du foreslår. Red Hats veiledning for feilsøking av SELinux setter etikett- og konfigurasjonskontroller foran generert policy nettopp av denne grunn. Hvis det ikke finnes en tilsvarende avvisning i oppføringen, er SELinux sannsynligvis ikke problemet ditt, og problemer med sti, sandbox eller tillatelser er fortsatt åpne.