Root en un terminal, denegat sota SELinux: per què falla el hook

Executeu l’script up com a root, s’acaba, i el mateix script falla quan el servei l’invoca. No ha canviat res dels permisos del fitxer, així que el següent pas natural és relaxar-los de nou, cosa que no arregla res. En un amfitrió amb SELinux el factor decisiu sovint no és qui és el procés, sinó en quin domini s’executa, i root dins d’un domini confinat continua confinat.

La mateixa ordre, dos dominis de seguretat diferents

L’aplicació de tipus avalua el domini d’origen, l’etiqueta de destinació i l’operació sol·licitada alhora. La vostra sessió de terminal s’executa en un domini no confinat o administratiu, i el dimoni s’executa en el domini que tingui assignada la seva unitat. Per tant, ordres idèntiques produeixen decisions diferents, i la diferència és deliberada i no pas un error de la política.

Per això comparar les dues execucions només és útil si en compareu els contextos. Executeu la mateixa ordre des de l’intèrpret i des del hook; la versió de l’intèrpret demostra que el binari existeix i que els arguments són correctes, però no demostra res sobre si el servei té permís per executar-lo. Executeu-la de les dues maneres i compareu els dominis, no només els codis de sortida. Aquesta comparació és la que converteix una queixa vaga de permisos en una pregunta concreta sobre un domini i una etiqueta.

La forma clàssica d’aquesta fallada és un auxiliar que crida una eina externa. El hook mateix pot estar permès, mentre que l’eina que invoca porta una etiqueta que el domini del servei no pot executar, o escriu en un directori l’etiqueta del qual ho prohibeix.

Llegiu el registre AVC al costat de l’error del hook

Una denegació AVC anomena els camps que decideixen el cas: el context d’origen del procés, el context de destinació de l’objecte, la classe de l’objecte i el permís concret que s’ha denegat. Llegiu-los tots quatre abans de formar una teoria, perquè una denegació d’execució i una denegació d’escriptura tenen reparacions completament diferents.

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

El context d’origen hauria de coincidir amb el domini en què s’executa realment el servei, i el context de destinació amb l’etiqueta del fitxer o directori que ha tocat l’operació. Si cap dels dos no encaixa amb l’error que perseguiu, esteu llegint un altre esdeveniment.

Anoteu la versió de la política i el camí exacte de l’executable al costat del registre. Un nom de domini que apareix a la política d’una distribució és una evidència sobre aquella instal·lació, no una garantia que una altra compilació inclogui les mateixes regles. Aquest context és el que permet a una altra persona reproduir la vostra conclusió al seu propi amfitrió. Sense això, el registre es llegeix com una anècdota i no com una prova.

Etiqueta, configuració o política: tres reparacions

La primera reparació és una etiqueta que no coincideix amb la ubicació instal·lada del fitxer. Un script copiat al seu lloc amb cp o escrit per un editor pot portar una etiqueta per defecte que el domini del servei no pot utilitzar, i restaurar el context esperat ho arregla sense tocar la política.

La segona és la configuració. La distribució pot oferir una manera admesa d’executar l’operació, un directori documentat per a l’auxiliar o un paquet de política actualitzat que ja ho permet. Canviar la vostra disposició per l’admesa és més barat que escriure política i sobreviu a les actualitzacions.

La tercera és una regla realment absent, i hauria de ser l’últim recurs. Genereu un candidat amb les eines d’auditoria, llegiu què permet realment, limiteu-lo a l’operació i el domini que heu observat, i feu que algú altre el revisi abans que s’acosti a producció.

Per què un mòdul allow antic no és la resposta

Els resultats de cerca per a aquesta fallada són plens de mòduls prefabricats, sovint per a una eina que el hook ja no crida. Instal·lar-ne un concedeix permisos que poden no tenir res a veure amb la vostra denegació, i deixa la desalineació real al seu lloc alhora que afegeix un forat permanent.

També amaga la fallada següent. Un mòdul que permet una classe àmplia d’operacions farà desaparèixer aquest error i convertirà el següent en una cosa molt més difícil d’atribuir. Eliminar el mòdul més endavant també és un canvi que ningú no vol planificar, així que la drecera tendeix a esdevenir permanent.

La comparació disciplinada és entre la denegació que podeu llegir i el canvi que proposeu. La guia de resolució de problemes de SELinux de Red Hat posa les comprovacions d’etiquetatge i configuració davant de la política generada exactament per aquest motiu. Si no hi ha cap denegació corresponent al registre, probablement SELinux no és el vostre problema, i els problemes de camí, de sandbox o de permisos continuen oberts.