A autenticación PAM funciona a man pero falla como servizo de OpenVPN

A autenticación mediante PAM pode ter éxito cando executa o cliente a man e fallar con AUTH_FAILED en canto systemd inicia o mesmo perfil. O contrasinal non cambia entre esas execucións; o que cambia é o conxunto de restricións arredor do proceso que lle pregunta a PAM. PAM responde mediante un axudante cuxa capacidade de cambiar as súas propias credenciais é exactamente o que elimina unha unidade endurecida. Atope ese axudante e o límite que necesita antes de tocar unha lista de capacidades.

unix_chkpwd é o binario que responde á pregunta de PAM

Coa autenticación local por contrasinal, pam_unix raramente le o propio ficheiro hash. Executa unix_chkpwd, que as distribucións instalan como setuid root ou setgid shadow para que un contrasinal poida comprobarse en nome dun proceso que non ten nada que facer lendo /etc/shadow. Quite a capacidade de adquirir esa identidade e o axudante non poderá completar a comprobación, así que o módulo devolve un simple fallo de autenticación.

O fallo entón parece un problema de credenciais en todos os rexistros que o cliente pode ver. Esa é a trampa: o cliente informa do que PAM lle dixo, e PAM só informa de que a pila dixo non. Executar o axudante a man como root tampouco demostra nada, porque exercita unha ruta de privilexios que o servizo nunca usa. Lea a unidade que systemd cargou realmente e despois o rexistro do sistema para o intento que fixo. Esas dúas vistas separan un problema de sandbox dun problema de contrasinal incorrecto.

Lea a unidade antes de ler o rexistro de contrasinais

Unha unidade empaquetada pode levar un drop-in que vostede non escribiu, e a configuración efectiva é o resultado combinado. Imprima a unidade tal como a ve systemd, xunto cos axustes de sandbox que deciden se o axudante pode elevarse. A inspección de só lectura é suficiente nesta etapa.

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

O primeiro comando mostra de onde veñen a unidade e os seus drop-ins, o cal importa porque unha anulación engadida hai meses sobrevive á memoria de por que existe. O segundo imprime os valores de sandbox dos que dependen as dúas seccións seguintes.

Compare o que ve cun host funcional da mesma distribución e versión. Unha diferenza en User, CapabilityBoundingSet ou NoNewPrivileges é unha pista concreta; unha diferenza en comentarios de prosa non o é. Anote os valores antes de cambiar nada, porque unha comparación posterior contra un obxectivo móbil non demostra nada. Se o servizo se executa cunha conta sen privilexios e un conxunto bounding baleiro, o axudante case non ten con que traballar.

Transformación de credenciais, acceso a ficheiros e política son tres límites

Comece polo que ocorre durante exec. Un binario setuid ou un ficheiro con capacidades de ficheiro desencadea unha transformación de credenciais, así que a identidade resultante non é unha continuación do chamador. O conxunto bounding limita o que pode adquirir ese binario, e NoNewPrivileges bloquea directamente as adquisicións de setuid, setgid e capacidades de ficheiro. Calquera das tres pode deter o axudante deixando intactas as demais funcións do servizo.

A continuación, separe a elusión discrecional ampla do acceso de lectura estreito. CAP_DAC_OVERRIDE salta as comprobacións discrecionais case en todas partes, mentres que CAP_DAC_READ_SEARCH cobre a lectura e o percorrido de directorios cos seus propios poderes adicionais. Son ferramentas distintas con radios de impacto distintos, e ningunha é unha forma de escribir deixa que PAM lea o ficheiro shadow.

Por último, pregunte se a política obrigatoria permite a acción. Unha capacidade de Linux non anula SELinux, e posuír unha non demostra nada sobre unha regra de type enforcement. Trate unha denegación de acceso a ficheiro e unha denegación de capacidade como probas distintas, porque nomean correccións distintas e a miúdo propietarios distintos. Lea cada campo do rexistro en lugar da soa palabra denied. Que executable realizou a acción, en que dominio se executou, que tipo de obxectivo tocou, que clase de obxecto estaba implicada e que permiso denegou a política: cada un estreita a resposta dun xeito diferente.

Extraia a denegación do rexistro de auditoría

Nun host en modo de aplicación, o rastro de auditoría é o único lugar que rexistra unha denegación. Consulte os eventos recentes e léaos contra a marca de tempo do inicio de sesión fallido, non contra a hora en que comezou a investigar.

ausearch -m AVC,USER_AVC -ts recent

Un resultado baleiro non é proba de inocencia. Significa que ou a auditoría non recolle, ou que a súa xanela perdeu o intento, e ambas posibilidades deben descartarse antes de descartar a política.

A guía de solución de problemas de SELinux de Red Hat sitúa as comprobacións de etiquetas e configuración antes de xerar regras de allow, que tamén é a orde correcta para este problema. Un axudante mal etiquetado e un oco de política producen denegacións similares pero necesitan reparacións distintas. Xerar unha regra de allow para un erro de etiquetaxe oculta a falla e deixa que a seguinte actualización do paquete a reintroduza. Confirme a etiqueta do axudante instalado antes de escribir calquera política.

Demostre o cambio cun inicio de sesión aceptado e outro rexeitado

Cambie só o límite que demostrou e despois probe ambos resultados. Unha conta que debería autenticarse debe ter éxito, e unha conta cun contrasinal incorrecto debe seguir fallando. Un cambio que fai que todos os intentos teñan éxito eliminou a autenticación en lugar de reparala.

Realice un intento de conexión real e lea o diario inmediatamente despois. A liña que demostra a corrección é a entrada pam_unix(openvpn:auth) dese intento: debería indicar autenticación correcta, e ningún rexistro AVC debería levar o mesmo segundo.

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

Un túnel funcional tamén necesita unha reconexión, porque os cambios de sandbox rompen a segunda conexión máis a miúdo que a primeira. Comprobe o socket establecido tras a reconexión e confirme que a mesma unidade segue servíndoo.