¿Es seguro exponer un punto final de socket de registro en un entorno chrooteado?

El artículo vinculado está bastante desactualizado y existe la posibilidad de registrar eventos sftp incluso sin /dev/log en un entorno preso en versiones recientes de openssh en RHEL (documentado en portal del cliente ).

De todos modos, es bastante seguro si configura derechos de acceso.

  

¿Cómo puede ser seguro proporcionar un socket directamente conectado al sistema de registro a los usuarios que estoy tratando de rastrear?

No estás regalando el zócalo. El usuario no está interactuando directamente con este socket, porque no tiene shell, pero el servidor sftp interactúa con él.

Si le preocupa que el usuario elimine el socket o algo, esto no es posible, si configura los derechos de acceso de la forma correcta (como en el socket de registro en /dev/ )

Empecemos por lo que sabemos:

• Tiene un proceso ejecutándose en un entorno aislado
• Desea que el proceso se comunique con el sistema de registro

Por lo tanto, se desprende que debe proporcionar alguna forma de enrutar la comunicación desde su proceso al daemon de registro. Hay dos formas de hacer esto: sockets Unix o sockets TCP.

Para la aplicación, los sockets Unix y los sockets TCP son aproximadamente idénticos. En ambos casos, se conecta al socket y comienza a enviar / recibir tráfico. Pero los sockets Unix tienen la ventaja de seguridad de que puedes usar permisos de archivos para controlar quién puede conectarse a ellos.

Entonces, se pregunta cómo podría posiblemente ser seguro para permitir que el proceso se conecte al sistema de registro ... pero si su proceso no puede ver el sistema de registro, ¿cómo podría hacerlo? ¿Espera que genere entradas de registro?

Para ser claros, un socket de Unix no le da a nadie el control total sobre el proceso que posee el socket. En su lugar, permite que alguien abra una conexión al proceso que posee el socket, exactamente como usar una conexión de red, pero sin la red.