Despois da baixada de privilexios: que ficheiros de OpenVPN seguen funcionando?
Os descritores abertos antes da baixada seguen funcionando; as rutas reabertas despois non. Decida cal dos tres ficheiros de execución debe reabrir a súa configuración.
Un tempo de actividade longo só demostra que o arranque tivo éxito cos privilexios que o daemon tiña nese momento. Os fallos que importan aquí chegan despois: un cliente novo conéctase, substitúese unha lista de revocación, un script auxiliar necesita escribir un ficheiro. Cada un deles é unha apertura nova feita pola conta sen privilexios, coa súa propia pregunta de permisos e a súa propia mensaxe de erro. Tres decisións separan unha configuración que segue funcionando dunha que falla no seguinte evento.
Separe o que se cargou cedo do que se abre máis tarde
Un descritor é unha manexo sobre unha descrición de ficheiro aberta, e o modo de acceso fixouse ao crear esa descrición. Cambiar o usuario do proceso despois non pecha o manexo, por iso un ficheiro de clave lido como root segue funcionando tras a baixada. O modo tampouco cambia: un manexo aberto para lectura non se volve escribible, e un manexo escribible non se revoga só porque a conta perdeu os seus dereitos sobre a ruta. Estes dous feitos explican a maior parte do comportamento sorprendente destes informes.
A outra metade é memoria. Un daemon pode analizar un certificado, conservar o material analizado e pechar o ficheiro; o que queda en uso son datos, non un ficheiro aberto. Por iso o tráfico continuo non demostra nin que haxa un descritor aberto nin que o nome da ruta sexa alcanzable. Só demostra que o material necesario para a sesión actual se obtivo antes.
Unha apertura posterior é outra transacción. Execútase coas credenciais actuais, o contexto de seguridade actual e a vista de montaxe actual, así que unha ruta lexible no arranque pode ser rexeitada na seguinte conexión. A rotación engade unha trampa: escribir un ficheiro novo sobre o mesmo nome de ruta deixa un descritor existente ligado ao obxecto antigo, así que unha recarga pode parecer exitosa mentres o daemon aínda usa o contido anterior. Compare o inode que mantén o proceso co do disco antes de crer que a rotación tivo efecto.
Nomee as tres lecturas de execución e cando se dispara cada unha
Tres recursos ábrense normalmente moito despois da inicialización, e fallan en momentos distintos. Un ficheiro de configuración propio dun cliente lese cando ese cliente se conecta, así que pode romper para un usuario mentres os demais continúan. Os datos de revocación consulados durante a autenticación da parella e outra vez cando se substitúe o ficheiro. Un directorio temporal só se toca cando un script ou un complemento escribe algo.
Ningún dos tres pertence á ruta de arranque, por iso un servidor san durante semanas pode fallar na seguinte conexión. A categoría tamén nomea o dono da corrección: os dous primeiros son permisos de lectura sobre a configuración baixo a conta do daemon, e o terceiro é unha localización escribible cun propósito estreito.
| Path reopened later | What triggers the open | First sign when it fails |
|---|---|---|
| Client configuration file | A connection for that client identity | One client rejected while others connect |
| Revocation data | Peer authentication, including after replacement | Revoked and valid peers both refused |
| Script or plugin temporary directory | A helper needs to create a file | The helper exits with a path error |
persist-key responde a unha pregunta máis estreita do que a maioría supón. Mantén o ficheiro de clave aberto durante os reinicios documentados de SIGUSR1 e ping-restart, e non fai nada polos ficheiros CCD, os datos de revocación, os executables auxiliares nin un reinicio completo do proceso. Estes seguen as súas propias rutas de apertura, baixo a conta que estea en marcha nese momento.
Confirme a conta e a vista que realmente ten
Pregunte ao daemon en execución que conta usa en vez de confiar no ficheiro de unidade, e despois compare a resposta co que a unidade establece. Unha discrepancia é o primeiro a resolver, porque cada comprobación de permisos posterior execútase como quen é realmente o proceso. Despois percorra a ruta compoñente a compoñente; o atravesamento avalíase en cada nivel, así que un ficheiro lexible dentro dun directorio non atravesable segue sen ser lexible. O modo final do ficheiro é a última pregunta, non a primeira.
Os espazos de nomes e as caixas de area de servizo engaden fronteiras que a propiedade e os bits de modo non describen. Unha ruta visible na súa shell pode faltar ou ser de só lectura dentro dun chroot, un espazo de nomes de montaxe ou unha unidade que agocha os directorios persoais. Os módulos de seguridade engaden outra capa, así que un ficheiro que parece lexible pode ser denegado ao abrirse.
ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/aliceUnha lectura correcta na shell do administrador non proba ningunha desas condicións combinadas. Execute a comprobación coa conta do daemon, co mesmo espazo de nomes e a mesma caixa de area, ou acepte que o resultado describe a súa shell e non o servidor. O terceiro comando é a versión barata desa proba: imprime o modo de cada compoñente e falla no primeiro que a conta do daemon non pode atravesar.
Conceda a escritura de execución nun directorio propio
A lectura é só a metade do inventario. Un script auxiliar pode necesitar crear un ficheiro de estado, un complemento pode necesitar escribir estado xunto á súa configuración, e esas escrituras non quedan cubertas por facer escribible a árbore de configuración. Dea ao directorio concreto o permiso de escritura que a súa función necesita, cun dono e un modo que poida explicar. Prefira o acceso de só lectura para todo o que só se le.
Manteña os permisos da clave privada separados dos ficheiros de política. Unha clave que debe relerse tras un reinicio ten un requisito distinto do dun ficheiro de cliente lido en cada conexión, e un só modo permisivo para ambos concede máis acceso do que pide o problema. Unha conta de daemon dedicada con propiedade estreita é máis doada de auditar que un grupo amplo. Cando a clave debe sobrevivir aos reinicios, persist-key elimina a relectura en lugar de ampliar o directorio.
Decida a partir do evento que pode reproducir
Un túnel activo demostra un só camiño polo código. O evento que necesita o ficheiro é a única proba que cobre a apertura que lle importa, xa sexa unha conexión de cliente nova, un ficheiro de revocación substituído, un reinicio suave permitido ou un reinicio planificado. Escolla o evento, execúteo e quede co primeiro erro en lugar do último.
Para un reinicio suave, un sinal e o rexistro da unidade mostran se a clave se leu de novo. Envíe o sinal e despois lea as últimas liñas que escribiu a unidade:
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pagerNon conclúa que un daemon comprometido xa non pode modificar ficheiros só porque se baixaron os privilexios. O que aínda pode depende das credenciais restantes, das súas capacidades, dos directorios onde pode escribir e de calquera descritor escribible que aínda manteña. A redución de privilexios estreita a autoridade, e o inventario das aperturas de execución mostra ata onde. Escriba esa fronteira xunto á configuración para que a seguinte persoa non teña que redescubrila.