¿Se pueden bloquear los sockets de dominio UNIX por ID de usuario?

5

Si creé una carpeta /tmp/me con permisos 700 , y comencé un proceso en me que inicia un socket de escucha en /tmp/me/socket .

  • Actualmente asumo que una conexión a ese socket se originó en un proceso que se está ejecutando en el mismo servidor (malicioso o no) y que no era una conexión de otro servidor (a menos que se realice a través de uno de los procesos).
  • ¿También puedo asumir que los únicos usuarios que pueden acceder a ese socket son me y root ?

Estoy preguntando por Solaris en particular.

Nota: soy consciente de que la configuración de permisos en el archivo socket en sí no es efectiva en varios sistemas operativos. Es por eso que elegí contener el archivo socket dentro de un directorio me .

    
pregunta George Bailey 21.02.2012 - 14:43
fuente

2 respuestas

6
  

Actualmente asumo que una conexión a ese socket se originó a partir de un proceso que se ejecuta en el mismo servidor

Correcto. Los sockets del sistema de archivos se deben leer mediante un proceso que tenga acceso al archivo.

  

¿También puedo asumir que los únicos usuarios que pueden acceder a ese socket son yo y root?

Sí. Como me es el único usuario con permisos, ellos son los únicos que pueden ingresar a esa carpeta y ver el socket. root , por supuesto, es root .

    
respondido por el Jeff Ferland 21.02.2012 - 15:36
fuente
2

Sí, puede hacer esto, pero puede que no sea el mejor diseño ya que, en algunos sistemas, como HP-UX , los permisos del archivo de socket se ignoran. Si bien los permisos del directorio principal se seguirán aplicando, estos pueden ser más difíciles de administrar que los permisos en el propio archivo de socket.

Los sockets de dominio Unix proporcionan otro medio para verificar la identidad del proceso remoto: SCM_CREDENTIALS , como se documenta en unix(7) . Esto es infalible ya que solo la raíz * puede pasar credenciales falsificadas. Desafortunadamente, esto no parece ser más estándar que poner permisos del sistema de archivos en el archivo de socket:

  

SCM_CREDENTIALS y el espacio de nombres abstracto se introdujeron con Linux 2.2 y no deben usarse en programas portátiles. (Algunos sistemas derivados de BSD también admiten el paso de credenciales, pero los detalles de la implementación son diferentes).

* En Linux, técnicamente, el proceso externo solo necesita tener la capacidad CAP_SETUID , pero esto es una capacidad equivalente a la raíz bajo cualquier configuración del sistema vagamente razonable de todos modos (en otras palabras, si un atacante tiene esa capacidad, efectivamente tiene la raíz). El proceso externo también puede proporcionarle cualquiera de sus ID de usuario / grupo reales, efectivas y guardadas , que Tampoco es una vulnerabilidad, por motivos similares (TL; DR: Se permite cualquier proceso para intercambiar estas credenciales cuando sea necesario. le gusta).

    
respondido por el Kevin 19.06.2016 - 23:10
fuente

Lea otras preguntas en las etiquetas