Root i ein terminal, avvist under SELinux: kvifor hooken feilar

Du køyrer up-skriptet som root, det blir fullført, og det same skriptet feilar når tenesta kallar det. Ingenting ved filrettane er endra, så det naturlege neste steget er å løysa dei opp igjen, noko som ikkje rettar noko. På ein SELinux-vert er den avgjerande faktoren ofte ikkje kven prosessen er, men kva domene han køyrer i, og root inne i eit avgrensa domene er framleis avgrensa.

Same kommando, to ulike tryggleiksdomene

Typehandheving vurderer kjeldedomenet, måletiketten og den førespurde operasjonen saman. Økta di i terminalen køyrer i eit uavgrensa eller administrativt domene, og daemonen køyrer i domenet som er tildelt eininga. Identiske kommandoar gir derfor ulike avgjerder, og skilnaden er tilsikta og ikkje ein feil i policyen.

Derfor er samanlikninga av dei to køyringane berre nyttig om du samanliknar kontekstane deira. Køyr den same kommandoen frå skalet og frå hooken, og skalversjonen beviser at binærfila finst og at argumenta er riktige; ho beviser ingenting om tenesta har lov til å køyre han. Køyr han begge vegar og samanlikn domena, ikkje berre utgangskodane. Nettopp den samanlikninga gjer ei vag løyveklage om til eit konkret spørsmål om eitt domene og ein etikett.

Den klassiske forma for denne feilen er ein hjelpar som kallar eit eksternt verktøy. Sjølve hooken kan vere tillaten, medan verktøyet han kallar, har ein etikett som tenestedomenet ikkje har lov til å køyre, eller skriv til ei mappe der etiketten forbyr det.

Les AVC-oppføringa ved sida av hook-feilen

Ei AVC-avvising namngir felta som avgjer saka: kjeldekonteksten til prosessen, målkonteksten til objektet, objektklassen og den spesifikke løyva som vart avvist. Les alle fire før du dannar ein teori, fordi ei avvising på execute og ei avvising på write har heilt ulike reparasjonar.

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

Kjeldekonteksten bør stemme med domenet tenesta faktisk køyrer i, og målkonteksten med etiketten til fila eller mappa operasjonen rørte. Om ein av dei ikkje stemmer med feilen du jagar, les du ei anna hending.

Noter policyversjonen og den nøyaktige stien til den køyrbare fila ved sida av oppføringa. Eit domenenamn som førekjem i policyen til éin distribusjon, er prov om den installasjonen, ikkje ei garanti for at ein annan bygg leverer dei same reglane. Det er denne konteksten som gjer at andre kan gjenta konklusjonen din på sin eigen vert. Utan han blir oppføringa lesen som ei anekdote og ikkje som prov.

Etikett, konfigurasjon eller policy: tre reparasjonar

Den første reparasjonen er ein etikett som ikkje passar med den installerte plasseringa til fila. Eit skript som er kopiert på plass med cp eller skrive av ein editor, kan bera ein standardetikett som tenestedomenet ikkje kan bruke, og attoppretting av den venta konteksten fiksar det utan å røre policyen i det heile.

Den andre er konfigurasjon. Distribusjonen tilbyr kanskje ein støtta måte å køyre operasjonen på, ei dokumentert mappe for hjelparen eller ein oppdatert policypakke som allereie tillèt det. Å endre oppsettet ditt til det støtta er billegare enn å skrive policy og overlever oppdateringar.

Den tredje er ein regel som verkeleg manglar, og han bør vere det siste middelet. Generer ein kandidat med revisjonsverktøya, les kva han faktisk tillèt, snevra han inn til operasjonen og domenet du observerte, og få nokon andre til å gjennomgå han før han kjem nær produksjon.

Kvifor ein gammal allow-modul ikkje er svaret

Søkjeresultata for denne feilen er fulle av ferdige modular, ofte for eit verktøy som hooken ikkje lenger kallar. Å installere éin gir løyve som kanskje ikkje har noko med avvisinga di å gjere, og han lèt den eigentlege uoverensstemminga stå medan han legg til eit permanent hol.

Han skjuler òg den neste feilen. Ein modul som tillèt ein brei klasse operasjonar, vil få denne feilen til å forsvinne og gjere den neste til noko mykje vanskelegare å tilskrive. Å fjerne modulen seinare er òg ei endring ingen vil planleggje, så snarvegen har ein tendens til å bli permanent.

Den disiplinerte samanlikninga er mellom avvisinga du kan lese og endringa du føreslår. Red Hats rettleiing for feilsøking av SELinux set etikett- og konfigurasjonskontrollar framfor generert policy nettopp av denne grunnen. Om det ikkje finst ei tilsvarande avvising i oppføringa, er SELinux truleg ikkje problemet ditt, og problem med sti, sandbox eller løyve er framleis opne.