Root in een terminal, geweigerd onder SELinux: waarom de hook faalt

U voert het up-script uit als root, het rondt af, en hetzelfde script mislukt wanneer de service het aanroept. Aan de bestandsrechten is niets veranderd, dus de natuurlijke volgende stap is ze weer te versoepelen, wat niets oplost. Op een SELinux-host is de beslissende factor vaak niet wie het proces is, maar in welk domein het draait, en root binnen een beperkt domein blijft beperkt.

Hetzelfde commando, twee verschillende beveiligingsdomeinen

Type-afdwinging beoordeelt het brondomein, het doellabel en de gevraagde bewerking samen. Uw terminalsessie draait in een onbeperkt of administratief domein, en de daemon draait in het domein dat aan zijn unit is toegewezen. Identieke commando’s leveren daarom verschillende beslissingen op, en het verschil is opzettelijk en geen fout in het beleid.

Daarom is het vergelijken van de twee runs alleen nuttig als u hun contexten vergelijkt. Voer hetzelfde commando uit vanuit de shell en vanuit de hook, en de shell-versie bewijst dat het binaire bestand bestaat en de argumenten kloppen; ze bewijst niets over of de service het mag uitvoeren. Voer het op beide manieren uit en vergelijk de domeinen, niet alleen de exitcodes. Juist die vergelijking verandert een vage klacht over rechten in een concrete vraag over één domein en één label.

De klassieke vorm van deze fout is een helper die een extern hulpprogramma aanroept. De hook zelf mag zijn toegestaan, terwijl het hulpprogramma dat hij aanroept een label draagt dat het servicedomein niet mag uitvoeren, of schrijft naar een map waarvan het label dat verbiedt.

Lees de AVC-regel naast de hook-fout

Een AVC-weigering noemt de velden die de zaak beslissen: de broncontext van het proces, de doelcontext van het object, de objectklasse en de specifieke toestemming die werd geweigerd. Lees alle vier voordat u een theorie vormt, want een weigering op execute en een weigering op write vragen om heel verschillende reparaties.

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

De broncontext hoort te passen bij het domein waarin de service daadwerkelijk draait, en de doelcontext bij het label van het bestand of de map die de bewerking raakte. Als een van beide niet overeenkomt met de fout die u najaagt, leest u een andere gebeurtenis.

Noteer de beleidsversie en het exacte pad van het uitvoerbare bestand naast de regel. Een domeinnaam die in het beleid van één distributie voorkomt, is bewijs over die installatie, geen garantie dat een andere build dezelfde regels meelevert. Die context is wat iemand anders in staat stelt uw conclusie op zijn eigen host te reproduceren. Zonder die context leest de regel als een anekdote en niet als bewijs.

Label, configuratie of beleid: drie reparaties

De eerste reparatie is een label dat niet past bij de geïnstalleerde locatie van het bestand. Een script dat met cp op zijn plaats is gekopieerd of door een editor is geschreven, kan een standaardlabel dragen dat het servicedomein niet kan gebruiken, en het herstellen van de verwachte context lost dat op zonder het beleid aan te raken.

De tweede is configuratie. De distributie biedt misschien een ondersteunde manier om de bewerking uit te voeren, een gedocumenteerde map voor de helper, of een bijgewerkt beleidspakket dat het al toestaat. Uw indeling aanpassen aan de ondersteunde is goedkoper dan beleid schrijven en overleeft updates.

De derde is een echt ontbrekende regel, en dat zou het laatste redmiddel moeten zijn. Genereer een kandidaat met de audit-gereedschappen, lees wat die werkelijk toestaat, beperk hem tot de bewerking en het domein die u hebt waargenomen, en laat iemand anders hem beoordelen voordat hij in de buurt van productie komt.

Waarom een oude allow-module niet het antwoord is

Zoekresultaten voor deze fout staan vol kant-en-klare modules, vaak voor een hulpprogramma dat de hook niet meer aanroept. Er één installeren verleent toestemmingen die niets met uw weigering te maken hebben, en het laat de echte mismatch staan terwijl het een permanent gat toevoegt.

Het verbergt ook de volgende fout. Een module die een brede klasse van bewerkingen toestaat, laat deze fout verdwijnen en maakt de volgende veel moeilijker toe te schrijven. De module later verwijderen is ook een wijziging die niemand wil plannen, dus de kortere weg wordt meestal permanent.

De gedisciplineerde vergelijking is tussen de weigering die u kunt lezen en de wijziging die u voorstelt. De handleiding voor het oplossen van SELinux-problemen van Red Hat plaatst label- en configuratiecontroles vóór gegenereerd beleid precies om deze reden. Als er geen overeenkomstige weigering in de regel staat, is SELinux waarschijnlijk niet uw probleem, en problemen met pad, sandbox of toestemmingen zijn nog steeds open.