chroot falla a OpenVPN: regla d'AppArmor o capacitat?

El dimoni registra una fallada de chroot i el perfil ja sembla generós, així que la solució temptadora és ampliar una regla de camí i reiniciar. Normalment no canvia res, perquè chroot està protegit per un privilegi que el perfil mai no podia cedir. Decidir quina capa cal tocar requereix tres comprovacions, i són barates: què pot tenir el procés, què permet la política i què va treure el llançador abans que cap de les dues coses importés.

Dues portes separades, i només una pertany a AppArmor

chroot necessita CAP_SYS_CHROOT a l'espai de noms d'usuari on s'executa el procés. És un privilegi habitual de Linux, i el nucli el comprova abans que la crida faci res amb camins. Per separat, un perfil d'AppArmor en mode d'aplicació pot denegar la capacitat fins i tot quan el procés la té, perquè la política obligatòria es consulta a més de les credencials, no en lloc seu. La distinció importa a la pràctica: les dues capes viuen en fitxers diferents i normalment les mantenen persones diferents.

Aquestes dues portes fallen amb el mateix errno. Totes dues produeixen EPERM i totes dues apareixen com una queixa genèrica de permisos al registre del dimoni, i per això endevinar el contingut del perfil perd tant de temps. La regla de camí que anàveu a afegir controla l'accés a fitxers després que chroot hagi reeixit; no té cap relació amb si l'operació està permesa.

Una tercera porta se situa per damunt de les dues. Si el gestor de serveis o un embolcall van iniciar el procés sense la capacitat al seu conjunt de límits, cap canvi d'AppArmor no la pot tornar, i afegir capacitats al perfil només documenta una intenció que el nucli no honrarà.

Llegiu l'estat dels privilegis abans d'editar la política

Comenceu pel procés en execució, no per la configuració que creieu activa. El fitxer d'estat exposa cinc màscares de capacitat i el flag no-new-privileges, i responen preguntes diferents:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff és el conjunt que importa per a la crida: una capacitat present a CapBnd però absent de CapEff està permesa pel sostre i no es té actualment. CapAmb importa quan el binari no és privilegiat en el sentit habitual de setuid, perquè les capacitats ambientals són com un servei conserva un privilegi a través d'exec sense capacitats de fitxer. CapInh guarda bits que es podrien heretar a través d'exec, però només quan el conjunt heretable del fitxer executat ho permet, així que un bit allà no atorga res per si sol.

Després confirmeu quin perfil hi ha realment adherit. Un procés pot estar confinat per un nom de perfil que no esperàveu, sobretot quan una distribució envia la seva unitat i el seu perfil junts, i llegir /proc/PID/attr/current ho resol en una línia. Comparar el fitxer que heu editat amb el perfil que el nucli informa és la diferència entre arreglar la causa i editar un fitxer que ningú no carrega.

Afegiu la regla de capacitat només quan el registre d'auditoria ho digui

Els registres del nucli i d'auditoria anomenen la capa que denega. Busqueu una denegació que porti l'operació capable i el nom sys_chroot, juntament amb el perfil que la va produir. Si aquest registre existeix, el procés ja tenia la capacitat i AppArmor la va denegar, i el canvi dirigit és una regla de capacitat dins del perfil real:

capability sys_chroot,

Manteniu-la com un fragment al perfil que està realment adherit, i comproveu la paraula clau amb la referència de perfils apparmor.d en lloc de copiar una regla d'un tutorial no relacionat. Posar-la en un include compartit l'atorga a cada programa confinat que arrossegui aquell fitxer, i passar els perfils a mode de queixa amaga la propera denegació en lloc de resoldre aquesta. La regla del perfil elimina una denegació de política; no fabrica privilegi, així que un procés que mai no va tenir CAP_SYS_CHROOT al seu conjunt efectiu encara fallarà amb la regla posada.

Si el registre d'auditoria no mostra cap denegació d'AppArmor, deixeu d'editar el perfil. Esteu davant d'un problema de credencials, i la feina que queda és al fitxer d'unitat o al procés pare, no al llenguatge de política.

El gestor de serveis té el seu propi sostre

systemd fixa un conjunt de límits de capacitat per a cada servei, i per defecte aquest conjunt és estret. Tot el que s'exclou allà és inaccessible al procés digui el que digui el perfil, i per això les unitats endurides poden fallar en una operació que funcionava quan el dimoni s'iniciava a mà. Les directives rellevants són fàcils de llegir a la unitat i fàcils de passar per alt quan l'aplicació informa de l'error. Els drop-in que envia un paquet de distribució són la font habitual d'un sostre que ningú no recorda haver configurat.

Pujar el sostre i atorgar la capacitat són dos canvis, no un. Una entrada al conjunt de límits diu que el procés pot tenir la capacitat; no l'afegeix al conjunt efectiu, i NoNewPrivs pot impedir que una elevació posterior reeixi fins i tot quan tota la resta encaixa. Afegiu només el que l'operació necessita, manteniu la resta de l'enduriment intacta i resistiu l'escletxa d'atorgar totes les capacitats per fer passar una crida.

L'ordre també importa aquí. Canvieu primer el sostre de la unitat, verifiqueu que CapEff ja conté el bit, i només després decidiu si AppArmor encara denega. Fer els dos canvis alhora us deixa tornant a endevinar si la fallada persisteix.

Quan la denegació desaparegui, comproveu la presó mateixa

Un chroot reeixit mou l'arrel, així que cada camí que el dimoni toqui després es resol dins de l'arbre nou. Una configuració absent, un node de dispositiu que falta o un directori de certificats que no es va copiar ara apareixeran com un error de fitxer, i aquest error és un problema de disposició, no de capacitat. Llegiu l'esdeveniment següent en lloc d'afegir un altre permís ampli. El moviment també canvia què significa un camí relatiu, i per això les guies d'enduriment insisteixen en camins absoluts a la configuració del dimoni.

També ajuda recordar què no fa chroot. És una frontera de camins, no una caixa de sorra: un procés que conserva el privilegi pot escapar-ne, i per això la capacitat normalment es deixa anar després de la crida i per això el confinament ha de romandre al voltant del dimoni. Mantenir el perfil d'AppArmor, el conjunt de límits de capacitat i les restriccions del sistema de fitxers alhora és el sentit de l'exercici, no una resta a eliminar quan el servei arrenca.

La regla de decisió és curta. Si el registre d'auditoria anomena AppArmor, afegiu una regla de capacitat al perfil adherit. Si el conjunt efectiu és buit, arregleu el sostre de la unitat i l'ordre de deixar anar el privilegi. Si el perfil no és el que heu editat, deixeu d'editar i trobeu el real.