L’autenticació PAM funciona a mà però falla com a servei OpenVPN

L’autenticació mitjançant PAM pot tenir èxit quan executeu el client a mà i fallar amb AUTH_FAILED quan systemd inicia el mateix perfil. La contrasenya no canvia entre aquestes execucions; el que canvia és el conjunt de restriccions al voltant del procés que fa la pregunta a PAM. PAM respon a través d’un auxiliar la capacitat del qual de canviar les seves pròpies credencials és exactament el que elimina una unitat endurida. Trobeu aquest auxiliar i la frontera que necessita abans de tocar una llista de capacitats.

unix_chkpwd és el binari que respon la pregunta de PAM

Amb autenticació local per contrasenya, pam_unix poques vegades llegeix el fitxer hash. Executa unix_chkpwd, que les distribucions instal·len com a setuid root o setgid shadow perquè una contrasenya es pugui comprovar en nom d’un procés que no té cap feina llegint /etc/shadow. Traieu la capacitat d’obtenir aquesta identitat i l’auxiliar no podrà completar la comprovació, així que el mòdul retorna un simple error d’autenticació.

Aleshores l’error sembla un problema de credencials en tots els registres que el client pot veure. Aquest és el parany: el client informa del que PAM li ha dit, i PAM només informa que la pila ha dit que no. Executar l’auxiliar a mà com a root tampoc no demostra res, perquè prova un camí de privilegis que el servei no fa servir mai. Llegiu la unitat que systemd va carregar realment i després el registre del sistema per a l’intent que va fer. Aquestes dues visions separen un problema de sandbox d’un problema de contrasenya incorrecta.

Llegiu la unitat abans de llegir el registre de contrasenyes

Una unitat empaquetada pot portar un drop-in que no vau escriure, i la configuració efectiva és el resultat fusionat. Imprimiu la unitat tal com la veu systemd, juntament amb els paràmetres de sandbox que decideixen si l’auxiliar pot elevar-se. La inspecció només de lectura és suficient en aquesta etapa.

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -b

La primera ordre mostra d’on vénen la unitat i els seus drop-ins, cosa que importa perquè una anul·lació afegida fa mesos sobreviu a la memòria de per què existeix. La segona imprimeix els valors de sandbox dels quals depenen les dues seccions següents.

Compareu el que veieu amb un amfitrió funcional de la mateixa distribució i versió. Una diferència a User, CapabilityBoundingSet o NoNewPrivileges és una pista concreta; una diferència en comentaris de prosa no ho és. Anoteu els valors abans de canviar res, perquè una comparació posterior contra un objectiu mòbil no demostra res. Si el servei s’executa amb un compte sense privilegis i un conjunt bounding buit, l’auxiliar gairebé no té amb què treballar.

Transformació de credencials, accés a fitxers i política són tres fronteres

Comenceu pel que passa durant exec. Un binari setuid o un fitxer amb capacitats de fitxer desencadena una transformació de credencials, de manera que la identitat resultant no és una continuació del cridador. El conjunt bounding limita el que pot adquirir aquest binari, i NoNewPrivileges bloqueja directament les adquisicions de setuid, setgid i capacitats de fitxer. Qualsevol d’aquestes tres pot aturar l’auxiliar deixant intactes la resta de funcions del servei.

A continuació, separeu l’elusió discrecional àmplia de l’accés de lectura estret. CAP_DAC_OVERRIDE salta les comprovacions discrecionals gairebé a tot arreu, mentre que CAP_DAC_READ_SEARCH cobreix la lectura i el recorregut de directoris amb els seus poders addicionals. Són eines diferents amb radis d’impacte diferents, i cap de les dues no és una manera d’escriure «deixa que PAM llegeixi el fitxer shadow».

Finalment, pregunteu si la política obligatòria permet l’acció. Una capacitat de Linux no anul·la SELinux, i posseir-ne una no demostra res sobre una regla de type enforcement. Tracteu una denegació d’accés a fitxer i una denegació de capacitat com a proves diferents, perquè anomenen correccions diferents i sovint propietaris diferents. Llegiu cada camp del registre en lloc de la sola paraula denied. Quin executable va fer l’acció, en quin domini s’executava, quin tipus d’objectiu va tocar, quina classe d’objecte hi havia implicada i quin permís va denegar la política: cadascun estreny la resposta d’una manera diferent.

Extreu la denegació del registre d’auditoria

En un amfitrió en mode d’aplicació, el rastre d’auditoria és l’únic lloc que registra una denegació. Consulteu els esdeveniments recents i llegiu-los contra la marca de temps de l’inici de sessió fallit, no contra l’hora en què vau començar a investigar.

ausearch -m AVC,USER_AVC -ts recent

Un resultat buit no és prova d’innocència. Significa que o bé l’auditoria no recull, o bé la vostra finestra va perdre l’intent, i ambdues possibilitats s’han d’excloure abans de descartar la política.

La guia de resolució de problemes de SELinux de Red Hat posa les comprovacions d’etiquetes i configuració abans de generar regles d’allow, que també és l’ordre correcte per a aquest problema. Un auxiliar mal etiquetat i una llacuna de política produeixen denegacions similars però necessiten reparacions diferents. Generar una regla d’allow per a un error d’etiquetatge amaga la falla i deixa que la següent actualització del paquet la reintrodueixi. Confirmeu l’etiqueta de l’auxiliar instal·lat abans d’escriure cap política.

Demostreu el canvi amb un inici de sessió acceptat i un de rebutjat

Canvieu només la frontera que heu demostrat i després proveu els dos resultats. Un compte que s’hauria d’autenticar ha de tenir èxit, i un compte amb contrasenya incorrecta encara ha de fallar. Un canvi que fa que tots els intents tinguin èxit ha eliminat l’autenticació en lloc de reparar-la.

Feu un intent de connexió real i llegiu el diari immediatament després. La línia que demostra la correcció és l’entrada pam_unix(openvpn:auth) d’aquell intent: hauria de dir autenticació correcta, i cap registre AVC no hauria de portar el mateix segon.

journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpn

Un túnel funcional també necessita una reconnexió, perquè els canvis de sandbox trenquen la segona connexió més sovint que la primera. Comproveu el socket establert després de la reconnexió i confirmeu que la mateixa unitat encara el serveix.