Permisos

Los permisos se pueden usar para controlar a qué recursos del sistema tiene acceso el proceso de Node.js o qué acciones puede realizar el proceso con esos recursos.

• Los permisos basados en procesos controlan el acceso del proceso de Node.js a los recursos. El recurso puede permitirse o denegarse por completo, o las acciones relacionadas con él pueden controlarse. Por ejemplo, se pueden permitir las lecturas del sistema de archivos y denegar las escrituras. Esta función no protege contra código malicioso. Según la Política de Seguridad de Node.js, Node.js confía en cualquier código que se le pida ejecutar.

El modelo de permisos implementa un enfoque de "cinturón de seguridad", que evita que el código de confianza cambie archivos o use recursos cuyo acceso no se haya concedido explícitamente de forma no intencionada. No proporciona garantías de seguridad en presencia de código malicioso. El código malicioso puede omitir el modelo de permisos y ejecutar código arbitrario sin las restricciones impuestas por el modelo de permisos.

Si encuentra una posible vulnerabilidad de seguridad, consulte nuestra Política de Seguridad.

Permisos basados en procesos

Modelo de permisos

[Estable: 2 - Estable]

Estable: 2 Estabilidad: 2 - Estable.

El Modelo de Permisos de Node.js es un mecanismo para restringir el acceso a recursos específicos durante la ejecución. La API existe detrás de una bandera --permission que, cuando está habilitada, restringirá el acceso a todos los permisos disponibles.

Los permisos disponibles están documentados por la bandera --permission.

Al iniciar Node.js con --permission, la capacidad de acceder al sistema de archivos a través del módulo fs, generar procesos, usar node:worker_threads, usar complementos nativos, usar WASI y habilitar el inspector de tiempo de ejecución estará restringida.

$ node --permission index.js

Error: El acceso a esta API ha sido restringido
    at node:internal/main/run_main_module:23:47 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'FileSystemRead',
  resource: '/home/user/index.js'
}

Permitir el acceso a la generación de un proceso y la creación de hilos de trabajo se puede realizar utilizando --allow-child-process y --allow-worker respectivamente.

Para permitir complementos nativos cuando se usa el modelo de permisos, use la bandera --allow-addons. Para WASI, use la bandera --allow-wasi.

API de Tiempo de Ejecución

Al habilitar el Modelo de Permisos mediante el indicador --permission, se añade una nueva propiedad permission al objeto process. Esta propiedad contiene una función:

permission.has(scope[, reference])

Llamada a la API para verificar los permisos en tiempo de ejecución (permission.has())

process.permission.has('fs.write') // true
process.permission.has('fs.write', '/home/rafaelgss/protected-folder') // true

process.permission.has('fs.read') // true
process.permission.has('fs.read', '/home/rafaelgss/protected-folder') // false

Permisos del Sistema de Archivos

El Modelo de Permisos, de forma predeterminada, restringe el acceso al sistema de archivos a través del módulo node:fs. No garantiza que los usuarios no puedan acceder al sistema de archivos a través de otros medios, como a través del módulo node:sqlite.

Para permitir el acceso al sistema de archivos, utilice los indicadores --allow-fs-read y --allow-fs-write:

$ node --permission --allow-fs-read=* --allow-fs-write=* index.js
¡Hola mundo!

Los argumentos válidos para ambos indicadores son:

• * - Para permitir todas las operaciones FileSystemRead o FileSystemWrite, respectivamente.
• Rutas delimitadas por comas (,) para permitir solo las operaciones FileSystemRead o FileSystemWrite correspondientes, respectivamente.

Ejemplo:

• --allow-fs-read=* - Permitirá todas las operaciones FileSystemRead.
• --allow-fs-write=* - Permitirá todas las operaciones FileSystemWrite.
• --allow-fs-write=/tmp/ - Permitirá el acceso FileSystemWrite a la carpeta /tmp/.
• --allow-fs-read=/tmp/ --allow-fs-read=/home/.gitignore - Permite el acceso FileSystemRead a la carpeta /tmp/ y a la ruta /home/.gitignore.

También se admiten comodines:

• --allow-fs-read=/home/test* permitirá el acceso de lectura a todo lo que coincida con el comodín. Ej: /home/test/file1 o /home/test2

Después de pasar un carácter comodín (*), todos los caracteres posteriores se ignorarán. Por ejemplo: /home/*.js funcionará de forma similar a /home/*.

Cuando se inicializa el modelo de permisos, automáticamente agregará un comodín (_) si existe el directorio especificado. Por ejemplo, si /home/test/files existe, se tratará como /home/test/files/_. Sin embargo, si el directorio no existe, no se agregará el comodín y el acceso se limitará a /home/test/files. Si desea permitir el acceso a una carpeta que aún no existe, asegúrese de incluir explícitamente el comodín: /my-path/folder-do-not-exist/\*.

Restricciones del modelo de permisos

Existen restricciones que debes conocer antes de utilizar este sistema:

• El modelo no se hereda a un proceso hijo de nodo ni a un hilo de trabajador.

• Al utilizar el Modelo de Permisos, las siguientes características estarán restringidas:

  • Módulos nativos
  • Proceso hijo
  • Hilos de trabajador
  • Protocolo Inspector
  • Acceso al sistema de archivos
  • WASI

• El Modelo de Permisos se inicializa después de que se configura el entorno de Node.js. Sin embargo, ciertas banderas como --env-file o --openssl-config están diseñadas para leer archivos antes de la inicialización del entorno. Como resultado, dichas banderas no están sujetas a las reglas del Modelo de Permisos. Lo mismo se aplica a las banderas de V8 que se pueden establecer en tiempo de ejecución a través de v8.setFlagsFromString.

• Los motores OpenSSL no se pueden solicitar en tiempo de ejecución cuando el Modelo de Permisos está habilitado, lo que afecta a los módulos crypto, https y tls integrados.

• Las Extensiones Cargables en Tiempo de Ejecución no se pueden cargar cuando el Modelo de Permisos está habilitado, lo que afecta al módulo sqlite.

• El uso de descriptores de archivos existentes a través del módulo node:fs omite el Modelo de Permisos.

Limitaciones y problemas conocidos

• Los enlaces simbólicos se seguirán incluso a ubicaciones fuera del conjunto de rutas a las que se ha concedido acceso. Los enlaces simbólicos relativos pueden permitir el acceso a archivos y directorios arbitrarios. Al iniciar aplicaciones con el modelo de permisos habilitado, debe asegurarse de que ninguna ruta a la que se haya concedido acceso contenga enlaces simbólicos relativos.