Electron: Se encontró el binario auxiliar SUID sandbox, pero no está configurado correctamente

Desafortunadamente, no hay forma de que podamos configurar esto correctamente automáticamente, porque establecer los permisos apropiados requiere privilegios de root y no queremos solicitar una contraseña de root durante npm install .

Idealmente, Arch configuraría su soporte de kernel sin privilegios CLONE_NEWUSER y Chromium (y Electron) podrían usar el espacio de nombres del espacio de pruebas en lugar de depender del antiguo entorno de pruebas setuid. Las aplicaciones que se distribuyen en Linux deberán incorporar esto en su proceso de instalación. Consulte https://github.com/electron-userland/electron-installer-debian/pull/184 y https://github.com/electron-userland/electron-installer-redhat/pull/112 por ejemplo.

Durante el desarrollo, probablemente deberíamos imprimir algo en npm install aunque con instrucciones si detectamos que la zona de pruebas del espacio de nombres no está disponible.

¡Oye, gracias por la respuesta súper rápida!

¿CLONE_NEWUSER sin privilegios proviene de CONFIG_USER_NS=y ? Si es así, esa debería ser la configuración actual.

Por favor, avíseme si hay algo que pueda hacer para ayudar, o si esta es la salida esperada en Arch, estoy feliz de cerrar; entiendo que se pueden esperar algunos problemas al ejecutar distribuciones de vanguardia y no me importa resolviendo esto en un PKGBUILD lugar de esperar que funcione perfectamente directamente desde npm. ¡Salud!

CONFIG_USER_NS=y habilita la función de espacios de nombres de usuario, pero todavía están restringidos a usuarios privilegiados de forma predeterminada. Esto sugiere sysctl kernel.unprivileged_userns_clone=1

¿Existe una posible solución mientras tanto hasta que cada distribución de Linux habilite esas características?

@kitingChris El setuid sandbox ES la solución. Solo necesita asegurarse de que al desarrollar / lanzar una aplicación electrónica, sus scripts de desarrollo / empaquetado establezcan los permisos del asistente de sandbox correctamente como @nornagon vinculado anteriormente.

¿Existe una posible solución mientras tanto hasta que cada distribución de Linux habilite esas características?

Ver el mensaje original:

Si chown y chmod el archivo, entonces funciona bien

También vea aquí https://github.com/electron/electron/issues/16631#issuecomment -476082063 Entonces, para que suid sandbox funcione, básicamente tiene que modificar el binario chrome-sandbox esta manera:

• sudo chown root chrome-sandbox
• chmod 4755 chrome-sandbox

Sin embargo, el problema es más grave si se ejecutan paquetes de appimage / snap, aún no he revelado una solución decente para estos casos. Funciona si appimage se ejecuta con --no-sandbox argument, pero esto es un truco.

@nornagon

porque establecer los permisos apropiados requiere privilegios de root y no queremos pedir una contraseña de root durante la instalación de npm.

La ejecución de chmod 4755 node_modules/electron/dist/chrome-sandbox no requiere permiso de root y eso debería ser suficiente para ejecutar dicho comando para empaquetar la aplicación en paquetes deb / pacman / etc, como cuando dichos paquetes se instalan todos los archivos, incluidos chrome-sandbox normalmente propiedad de root. Por lo tanto, sería genial que electron hiciera chmod 4755 node_modules/electron/dist/chrome-sandbox automáticamente durante el proceso de instalación, ya que entonces no habría necesidad de manejar este caso manualmente como se menciona aquí .

CONFIG_USER_NS = y habilita la función de espacios de nombres de usuario, pero todavía están restringidos a usuarios privilegiados de forma predeterminada. Esto sugiere sysctl kernel.unprivileged_userns_clone = 1

Confirmo que ejecutar sudo sysctl kernel.unprivileged_userns_clone=1 es otra solución alternativa, comentario relacionado.

@vladimiry Necesitaba primero chown y luego chmod. Al revés no funcionó.

@burningTyger tienes razón , acabo de cambiar el mensaje original.

@nornagon Si chmod 4755 out/Release/chrome-sandbox en CI, ¿se mantendrá ese permiso una vez que zip lo hagamos o tenemos que hacer este cambio en electron-download para arreglar el permiso en DL?

Lo mismo aquí es una mala nueva función para lo que necesita cambiar eso ... :(

@MarshallOfSound zip no admite permisos, pero en última instancia, el problema no es el permiso chmod, sino el propietario. El asistente setuid sandbox es suid _to root_, porque necesita realizar funciones que solo están disponibles para root. Si fuera posible establecer los permisos adecuados sin obtener primero los privilegios de root, sería una vulnerabilidad muy grave en Linux. Afortunadamente para Linux, y desafortunadamente para nosotros, ese no es el caso.

Aquí están las opciones como las veo:

1. No cambie nada en Electron. Recomiende que los desarrolladores habiliten CLONE_USERNS sin privilegios en su kernel para permitir que se ejecute el sandbox del espacio de nombres en lugar del sandbox setuid.
2. Arranque sin sandbox si no hay ningún método de sandbox disponible _solo al arrancar una aplicación no empaquetada_. Si Electron está iniciando una aplicación empaquetada, rehúse iniciar sin sandbox.
3. En todos los casos, si no hay un método de espacio aislado disponible, inicie sin espacio de prueba e imprima una advertencia.
4. Desactive la zona de pruebas de forma predeterminada en Linux.

Me inclino hacia (2). Facilitaría el desarrollo sin comprometer la seguridad de la aplicación implementada.

Todavía no estoy seguro de qué hacer con snap / flatpak, ya que no estoy familiarizado con su funcionamiento. Es posible que ya hayan hecho un sandbox de la aplicación lo suficiente como para que podamos deshabilitar el sandboxing por completo en esa situación, como hacemos cuando creamos la versión de Electron para Mac App Store.

Por ahora, me gusta más la primera opción.

1. Arranque sin sandbox si no hay ningún método de sandbox disponible solo al arrancar una aplicación no empaquetada. Si Electron está iniciando una aplicación empaquetada, rehúse iniciar sin sandbox.

Tal escenario sería de alguna manera engañoso. Es posible que se esté ejecutando con éxito una aplicación desempaquetada sin sandboxing, pero existe la posibilidad de que la aplicación empaquetada no funcione de la misma manera con sandboxing habilitado. Como, por ejemplo, el caso cuando accede al proceso principal desde el proceso de renderizado, no a través de la interfaz remote . O el caso de empaquetar la aplicación en paquetes AppImage / Snap / Flatpak.

1. En todos los casos, si no hay un método de espacio aislado disponible, inicie sin espacio de prueba e imprima una advertencia.

Por lo tanto, una aplicación empaquetada que se diseñó y desarrolló como sandbox puede ejecutarse sin sandbox si no hay sandbox disponible. Esto no me suena bien.

1. Desactive la zona de pruebas de forma predeterminada en Linux.

¿Qué significa exactamente? ¿Cuál sería la forma de habilitar el sandboxing en Linux en la forma en que la aplicación se inicia o falla si no hay sandboxing disponible (la situación actual, sandboxing forzado)?

También me gusta (1), pero para defender un poco (2), la API expuesta a la aplicación no cambiaría al deshabilitar el sandbox. Lo único que deshabilitaríamos es la zona de pruebas a nivel del sistema operativo. Todavía cargaríamos la aplicación de la misma manera, simplemente no estaría protegida por el sistema operativo.

Todavía cargaríamos la aplicación de la misma manera, simplemente no estaría protegida por el sistema operativo.

Entonces a mí también me suena bien. Gracias por la explicación.

No me gusta 2., porque la seguridad opcional generalmente lleva a que las personas deshabiliten la seguridad.

Al ponerme en el lugar del "usuario estúpido" ahora, preferiría que Electron funcionara de forma predeterminada. Si es una medida de seguridad muy importante, avíseme y déme una buena explicación de por qué necesito hacer un trabajo extra. Si no es tan importante, entonces no me des el mal sabor de "no funciona".

Debido a esto, me gusta 1. (con un abandono forzado, como ahora) o 4.

: x: chown root:root chrome-sandbox && chmod 4755 chrome-sandbox genera algunas banderas rojas para mí.

Para ser muy claro sobre lo que hace: establece el bit SUID en chrome-sandbox , lo que hace que _cualquier usuario_ pueda ejecutar el archivo _como root_. Esto significa que si hay alguna forma de usar chrome-sandbox maliciosamente, o si el contenido alguna vez se vuelve malicioso, cualquier usuario podría convertirse en root. chrome-sandbox sería un objetivo de ataque muy interesante.

Recomiendo encarecidamente no hacer esta solución en npm install , porque requeriría sudo (el usuario debe escribir una contraseña), es invasivo y es posible que no comprendamos las consecuencias de seguridad de hacerlo.

chown root: root chrome-sandbox && chmod 4755 chrome-sandbox genera algunas señales de alerta para mí.

Claro que lo hace. Pero puede habilitar el espacio aislado del espacio de nombres de usuario como alternativa sudo sysctl kernel.unprivileged_userns_clone=1 (habilitado de forma predeterminada en Ubuntu pero no en Arch).

Para ser muy claro sobre lo que hace: establece el bit SUID en chrome-sandbox , lo que hace que _cualquier usuario_ pueda ejecutar el archivo _ como root_. Esto significa que si hay alguna forma de usar chrome-sandbox maliciosamente, o si el contenido alguna vez se vuelve malicioso, cualquier usuario podría convertirse en root. chrome-sandbox sería un objetivo de ataque muy interesante.

Sí, pero también este binario es exactamente el mismo que viene con Chrome, por lo que si le preocupa esto, probablemente también debería desinstalar Chrome :)

¿Hay alguna forma de ejecutar sin la caja de arena / ejecutar sin el "ayudante de la caja de arena"? Los primeros usuarios se quejaron 😅
Esperaba que esto desactivara la caja de arena, pero aún así aparece el error The SUID sandbox helper binary was found, but is not configured correctly .
Odiaría volver al electrón 4.x 🤨

Mensaje de error

Revisión y suid de Snapcraft

Intenté cargar un complemento con la bandera suid en chrome-sandbox pero el proceso de revisión de snapcraft prohíbe el uso de banderas suid.

The store was unable to accept this snap.
  - checksums do not match. Please ensure the snap is created with either 'snapcraft pack <DIR>' (using snapcraft >= 2.38) or 'mksquashfs <dir> <snap> -noappend -comp xz -all-root -no-xattrs -no-fragments'. If using electron-builder, please upgrade to latest stable (>= 20.14.7). See https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/17 for details.
  - found errors in file output: unusual mode 'rwsr-xr-x' for entry './chrome-sandbox'

@thomasnordquist para deshabilitar el --no-sandbox debe pasarse como un argumento de aplicación, es decir, app.commandLine.appendSwitch no será suficiente. Con respecto a un paquete Snap, es posible que desee intentar agregar un complemento como se describe aquí . No estoy seguro de si eso ayudará, ya que aún no lo he probado, sería genial si lo hicieras. Por ahora prefiero lanzar la aplicación que he estado construyendo en modo mixto : smile :

Si Snapcraft prohíbe las banderas suid, probablemente la única opción sea deshabilitar completamente el sandboxing de Electron en Snapcraft y confiar en el contenedor que usa Snapcraft. No estoy seguro de cuál es la mejor manera de hacerlo: ¿es posible especificar indicadores de línea de comandos adicionales al empaquetar a través de Snapcraft? Si es así, podríamos agregar la bandera --no-sandbox . De lo contrario, es posible que debamos agregar algún mecanismo de detección específico para detectar la ejecución en Snapcraft / Flatpak y deshabilitar el sandboxing en función de esa detección.

Alguna documentación relacionada con Snap https://docs.snapcraft.io/browser-support-interface

@ posix4e ¿ puede arrojar algo de luz sobre el problema de ejecutar el paquete Snap en la zona de

Para ser muy claro sobre lo que hace: establece el bit SUID en chrome-sandbox , lo que hace que _cualquier usuario_ pueda ejecutar el archivo _ como root_. Esto significa que si hay alguna forma de usar chrome-sandbox maliciosamente, o si el contenido alguna vez se vuelve malicioso, cualquier usuario podría convertirse en root. chrome-sandbox sería un objetivo de ataque muy interesante.

Sí, pero también este binario es exactamente el mismo que viene con Chrome, por lo que si le preocupa esto, probablemente también debería desinstalar Chrome :)

Estoy parcialmente preocupado por permitir que un binario de Chrome tenga root:root con SUID configurado, sí. Hay muy poco código sin errores. Aquí está el código fuente, para el registro: https://github.com/chromium/chromium/tree/master/sandbox/linux/suid

Pero estoy más preocupado si npm install :

1. Descargue un montón de software sobre la marcha.
2. Cree automáticamente uno de los archivos root:root y SUID.

Creo que esa sería la primera pila de software que conozco que automáticamente hace sudo chown root:root && sudo chmod 4755 en un archivo propiedad de un usuario no root.

Hacer una instalación de sudo chown root:root && sudo chmod 475 en npm debería estar fuera de discusión, npm debería ejecutarse como root para establecer los permisos. El modelo de gancho de npm permitiría que todos los paquetes instalados ejecuten sus ganchos también como root. Con posiblemente cientos de paquetes y dependencias anidadas, esto sería muy peligroso.

Hacer un sudo chown root: root && sudo chmod 475 en npm install debería estar fuera de discusión

Hasta donde yo entiendo, esto no se considera una opción.

Estoy de acuerdo en que hacer cualquier cosa que requiera privilegios de root durante la instalación de npm no es para empezar. Por eso no lo incluí como una de las opciones .

Por lo que vale, electron-installer-debian 1.2.0, electron-installer-redhat 1.1.0 y electron-installer-snap 3.2.0 se han lanzado con los cambios de la zona de pruebas SUID. Electron Forge v5 y v6 beta también deben actualizarse transitivamente (a través de actualizaciones de versión dentro del rango, use npm update o yarn upgrade apropiada).

Simplemente vinculando el código relacionado para mayor claridad.

Para ser claros, para Snaps había más que eso (es decir, agregar compatibilidad con el entorno de pruebas del navegador como se indicó anteriormente). Consulte los cambios del RP asociado para obtener más detalles.

Acabo de presionar esto, chown / chmod funciona, pero esa no es la única acción necesaria que se debe tomar si está ejecutando dentro de una imagen de Docker.

Si lo hace, recibirá otro error:

Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

La solución para eso es agregar --privileged al comando docker run . No creo que esta sea una buena solución, principalmente en CI.

@JCMais , parece que Electron está intentando utilizar incorrectamente el espacio de --disable-namespace-sandbox . Si inicia la ventana acoplable con --privileged (o --cap-add SYS_ADMIN , o un perfil seccomp personalizado que permite CLONE_NEWUSER), los espacios de nombres estarán disponibles dentro de la caja de arena y no hay necesidad de la caja de arena setuid o su ejecutable auxiliar .

Al igual que @thomasnordquist , terminé por ahora deshabilitando el sandboxing para los paquetes Snap / AppImage usando un script de precarga. Usted crea un script sh similar a una precarga llamado como binario original que luego se usa para cargar el binario electrónico original / renombrado con el argumento --no-sandbox . Es conveniente hacerlo en el script after-pack del constructor de electrones

@nornagon, ¿cómo debo pasar esta bandera al electrón? Intenté agregar --disable-namespace-sandbox pero me sigue dando un error:

:~$ electron --disable-namespace-sandbox
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

Puedo confirmar que esto me atacó en un instante y que todos nuestros usuarios de Linux están atascados en una versión anterior hasta que pueda remediar esto.

Estoy TOTALMENTE en busca de una forma de mejorar la seguridad, pero esto se envió sin una marca de función para desactivarlo.

También me gustaría argumentar que esto no debería haberse enviado sin una función para deshabilitarlo a través del código. Creo que tal vez esto fue accidental porque --no-sandbox no funciona a menos que se proporcione manualmente desde la línea de comando.

Si hay algún problema con la forma en que electron-installer-snap implementó el soporte de la caja de arena, hágamelo saber en su rastreador de problemas.

Si hay algún problema con la forma en que electron-installer-snap ha implementado el soporte de sandbox, hágamelo saber en su rastreador de problemas.

También me gustaría escuchar que alguien confirme que el cambio es suficiente para abordar el problema con los paquetes Snap. Por lo tanto, se agradecen tanto las retroalimentaciones positivas como las negativas. Ver información relacionada.

@vladimiry Seguí adelante y probé eso y no funcionó.

Necesito una solución que no se resuelva con los parches del sistema operativo, sysctl o reinicios. Necesito algo que simplemente funcione ahora. --no-sandbox sería preferible.

Sería mucho más útil para mí si alguien pudiera proporcionar una aplicación mínima de Electron que pudiera usar para reproducir el Snap empaquetado que no funciona. Usé una bifurcación de electron-quick-start para construir un Snap en CircleCI y lo instalé en mi computadora portátil (Debian Stretch) para verificar que mis cambios al menos construyeron una aplicación de Electron en funcionamiento.

"No funcionó" no me ayuda a identificar lo que puedo hacer en electron-installer-snap para que se empaquete correctamente para otros.

@burtonator , gracias por probar el material. Hasta donde yo sé, empaquetado en el script bash / sh tipo cargador de compilación Snap / AppImage que inicia el binario / electrón original con el argumento --no-sandbox cmd es la única solución alternativa verificada por ahora.

@malept antes de probar las cosas, es necesario deshabilitar la función del sistema operativo del espacio de nombres de usuario ejecutando sudo sysctl kernel.unprivileged_userns_clone=0 .

@vladimiry sí, mi computadora portátil ya tiene esa configuración de usuario.

Si alguien está buscando una solución para esto, consulte la solución de @thomasnordquist o mi adaptación de la misma, funcionan desactivando la caja de arena en Linux.

@fabiospampinato su adaptación desactiva la caja de arena para todos los tipos de paquetes de Linux, pero al menos los paquetes DEB y Pacman funcionan bien con la caja de arena SUID (probablemente todos los paquetes que no son contenedores), solo es necesario establecer el bit de permiso SUID en chrome-sandbox binario. Pero no establezca el bit de permiso SUID para el paquete Snap, ya que Snap Store rechaza este tipo de paquetes. Así que configuré el bit SUID para todos los paquetes de Linux, excepto los paquetes Snap / AppImage que obtienen el código relacionado con el sandboxing deshabilitado.

CONFIG_USER_NS = y habilita la función de espacios de nombres de usuario, pero todavía están restringidos a usuarios privilegiados de forma predeterminada. Esto sugiere sysctl kernel.unprivileged_userns_clone = 1

Confirmo que ejecutar sudo sysctl kernel.unprivileged_userns_clone=1 es otra solución alternativa, comentario relacionado.

¡Gracias amigo, trabajando para mí! @vladimiry

¿Saben si funciona ahora con 5.0.2?

@ p3x-robot No se menciona este problema en el registro de cambios. Solo verifiqué para estar seguro y el error todavía está ahí para mí.

@rybaczewa gracias por la respuesta, sigo en v4 también, ya que es un gran problema, no puedo esperar hasta que v5 esté funcionando, ciao

No puedo esperar hasta que v5 esté funcionando

v5 está funcionando

Para ser claro para la gente en este hilo @ p3x-robot @rybaczewa, este problema se deja abierto para fines informativos /

Si ve este mensaje de registro, debe ejecutar sudo sysctl kernel.unprivileged_userns_clone=1 o darle al binario chrome_sandbox los permisos correctos como se indica en el mensaje de error.

@vladimiry @MarshallOfSound ¿ sudo sysctl kernel.unprivileged_userns_clone=1 ni dar el chrome_sandbox v5.0.x. Solo puedo instalar con v4.xx

¿Crees que un usuario querrá usar sudo ? Pensarán que este programa es malo y desinstalarán la aplicación.
Las versiones v5 o v6 o v7 no funcionan correctamente, por lo tanto, esto es un error :

El soporte de @ p3x-robot snap como se indica arriba depende de cómo se haga el ajuste. electron-installer-snap tiene soporte para esto listo para usar y, como se mencionó anteriormente, si ese módulo tiene problemas / no funciona, plantee un problema en ese módulo.

Consulte el repositorio de electron-installer-snap para obtener más detalles o los documentos de snapcraft en la zona de

Para reiterar, mi entendimiento actual aquí es que no hay ningún error que corregir, la caja de arena de Electron está funcionando como se esperaba. Lo que se está discutiendo aquí son los problemas que enfrentan las personas al empaquetar el binario chrome_sandbox

esto es extraño, porque ya agregué sandbox:

app.enableSandbox()
app.commandLine.appendSwitch('no-sandbox')

producción:

patrikx3<strong i="9">@bitang</strong>:~/Projects/patrikx3/redis-ui-workspace/redis-ui$ /snap/bin/p3x-redis-ui 
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
realpath: '': No such file or directory
[12999:0525/085646.618618:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /snap/p3x-redis-ui/5/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)
patrikx3<strong i="10">@bitang</strong>:~/Projects/patrikx3/redis-ui-workspace/redis-ui$ 

Intento esto como: app.enableSandbox() , pero obtengo:

Uncaught ReferenceError: require is not defined
    at onload.js:1

Si elimino la línea, funciona.

@MarshallOfSound estoy usando electron-builder

para todos ustedes, si quieren que funcione, creé un ayudante:
https://github.com/patrikx3/redis-ui/blob/master/src/build/after-pack.js
si está usando electron-builder , lo agrega así:

para todos ustedes, si quieren que funcione, creé un ayudante:

Tal solución ya se ha mencionado muchas veces en la discusión de este tema, es por eso que escribí antes que electron v5 está funcionando.

@vladimiry gracias, me perdí esta solución, acabo de agregar una solución nativa de javascript en lugar de mecanografiado ...

el único problema es que cuando hago este truco después del paquete, no está usando en el panel el ícono de electron, pero genera un segundo ícono, ¿cómo se puede resolver eso? Creo que es la bandera de no-sandbox lo que lo hace. ¿alguien?

solo sucede con --no-sandbox :

@fabiospampinato su adaptación desactiva la caja de arena para todos los tipos de paquetes de Linux, pero al menos los paquetes DEB y Pacman funcionan bien con la caja de arena SUID (probablemente todos los paquetes que no son contenedores), solo es necesario establecer el bit de permiso SUID en chrome-sandbox binario. Pero no establezca el bit de permiso SUID para el paquete Snap, ya que Snap Store rechaza este tipo de paquetes. Así que configuré el bit SUID para todos los paquetes de Linux, excepto los paquetes Snap / AppImage que obtienen el código relacionado con el sandboxing deshabilitado.

¿Saben cómo puedo mantener un icono en lugar de dos?

https://github.com/electron-userland/electron-builder/issues/3872

https://github.com/patrikx3/onenote/issues/65

@ p3x-robot hay una manera de agregar --no-sandbox argumento a la aplicación de contenedor de Snap empaquetada sin introducir un script bash / sh similar al precargador:

• Primero desempaqueta el complemento ejecutando unsquashfs your-snap-file.snap .
• Edite ./squashfs-root/command.sh agregando los argumentos necesarios allí.
• Vuelva a empaquetar la carpeta ./squashfs-root en el paquete instantáneo ejecutando el comando snapcraft pack ./squashfs-root .

No lo intenté, pero creo que la acción de reempaquetado similar también se puede aplicar al paquete AppImage, es decir, una cuestión de ejecutar diferentes comandos de desempaquetar / empaquetar.

Supongo que las acciones de reempaquetado descritas se pueden activar en el gancho del constructor de electrones afterAllArtifactBuild .

@vladimiry muchas gracias, por el que es interesante para afterAllArtifactBuild, intentaré cambiar el command.sh sin desempacar, pero es para mañana, ¡gracias de nuevo!

el uno es interesante para afterAllArtifactBuild

@ p3x-robot afterAllArtifactBuild hook en realidad no se está activando como esperaba, pero es bastante fácil activar el Snap o cualquier otro tipo de paquete mediante programación. Vea aquí el ejemplo de código. snapFile es el archivo de resultados aquí, por lo que puede descomprimirlo / unsquashfs luego, aplicar los cambios necesarios y empaquetar / snapcraft pack . En el código de ejemplo, empaqueto los diccionarios Hunspell en la carpeta ./usr/share/hunspell Snap.

@vladimiry solo uso Electron v4, ya que está funcionando. Creo que alguien arreglará esto.

@ p3x-robot Sigo pensando que tienes que admitir que no hay nada que arreglar.

@vladimiry no hay nada que arreglar, seguro. :)

¿Alguien sabe si Electron v5.0.2 funciona con el problema de la caja de arena?

Es igual que la versión 5.0.0: smile:

Espero que esto no esté fuera de tema, pero para AppImages en Debian (9) aparece el error:

The setuid sandbox is not running as root. 

Corríjame si me equivoco, pero entiendo (principalmente por esta discusión) que esto se debe a la función de espacios de nombres de usuario deshabilitada que está deshabilitada de forma predeterminada en Debian.

Entonces, con respecto a esta sugerencia:

1. No cambie nada en Electron. Recomiende que los desarrolladores habiliten CLONE_USERNS sin privilegios en su kernel para permitir que se ejecute el sandbox del espacio de nombres en lugar del sandbox setuid.

Me gustaría mostrar un mensaje a los usuarios diciendo que solo funciona cuando la función de espacios de nombres de usuario está habilitada (con tal vez una pista sobre cómo hacerlo) y sugerir usar el paquete .deb como alternativa.

¿Cómo podría implementar un mensaje de este tipo antes de que se muestre el error? ¿Hay alguna manera de anteponer un script personalizado a la AppRun de AppImage sin desempacar y volver a empaquetar?

¿Hay alguna manera de anteponer un script personalizado a la AppRun de AppImage sin desempacar y volver a empaquetar?

@gcascio había mensajes en el hilo sobre el uso de un script sh similar al cargador que puede ser inyectado por el script afterpack .

Gracias por su respuesta. Pero creo que el AppRun generado no está disponible cuando se llama afterpack o me equivoco, al menos no puedo encontrarlo en appOutDir ?

Creo que el AppRun generado no está disponible cuando se llama al paquete posterior

Estaba escribiendo sobre el uso de un script sh tipo cargador, pero no sobre parchear el script AppRun. Si desea parchear el script AppRun, parece que no hay forma de hacerlo sin volver a empaquetarlo.

Está bien, lo he entendido mal. Podría ir con el reembalaje y luego gracias.

Podría ir con el reembalaje y luego gracias.

@gcascio en el caso de que necesites una plantilla .

es el mismo error "Se encontró el binario auxiliar SUID sandbox" pero en el archivo snap después de la instalación
como puedo arreglar esto

@vladimiry Estoy trabajando en un Docker IDE en línea llamado http://gitpod.io que ejecuta un contenedor Debian. No puedo solucionar el problema de Chrome-Sandbox porque no tengo acceso a sudo. El tono general aquí es que se trata de un problema de Chrome y no de Electron, pero si Electron pudiera resolver el problema, ¿no sería bueno?

Desde este sitio https://www.gitpod.io/blog/gitpodify/ he visto una solución para usar Puppeteer en el contenedor.

const browser = await puppeteer.launch({args: ['--no-sandbox', '--disable-setuid-sandbox']});

¿Podría Electron probar un código como ese si se produce el error de la caja de arena, antes de finalizar el proceso? ¿O es esto algo que podría invocar con un archivo bash?

¿Podría Electron probar un código como ese si se produce el error de la caja de arena, antes de finalizar el proceso? ¿O es esto algo que podría invocar con un archivo bash?

Sí, se supone que pasar el argumento --no-sandbox al binario de la aplicación electrónica en general soluciona el problema.

Dependiendo del paquete de instalación, puede establecer el bit de permiso SUID (4755) en chrome-sandbox binario (para paquetes como deb, pacman, etc.) o codificar el argumento --no-sandbox en el script loader sh / bash (para paquetes como Snap y AppImage). Esto es lo que hago actualmente, por lo que no hay necesidad de hacer nada por los usuarios de la aplicación (no se requiere acceso a sudo).

La reciente versión del generador de electrones ya viene con codificación rígida del argumento --no-sandbox pero solo para el paquete Snap.

Gracias @vladimiry electron --no-sandbox parece haber superado el problema. También revisaré SNAP.

hay constructores de electrones más nuevos, pero la AppImage todavía no está arreglada, ¿correcto?

¿Electrón 6 está arreglando el error de la caja de arena? Todavía estoy en la v4 ya que no puedo solucionar esto, ni la 5 ni la 6.

Esta es la situación:

• Electron v5 habilitó el sandboxing de modo mixto (es decir, algunos procesos están en sandbox y otros no) en Linux. Esto no cambia si sus procesos de renderizado están en espacio aislado de forma predeterminada, pero sí significa que el proceso de GPU ahora está en espacio aislado.
• La caja de arena de Chromium en Linux usa una función del sistema operativo llamada CLONE_NEWUSER . Algunos kernels están construidos con esta característica restringida a usuarios privilegiados por precaución. Puede leer más sobre esto aquí [lwn, 2016].
• Cuando CLONE_NEWUSER no está disponible, Chromium recurre al uso de un mecanismo de espacio aislado diferente que requiere un binario auxiliar que está configurado como root. Si este binario no está presente o no tiene los permisos adecuados ( 4755 _y es propiedad de root_), la caja de arena no podrá arrancar.
• La configuración de los permisos binarios auxiliares debe realizarla un usuario privilegiado (es decir, root). No establecemos estos permisos en npm install , porque no queremos solicitar acceso de root durante npm install .
• Los paquetes de lanzamiento de Electron v5 incluyen el binario auxiliar, pero depende de las diversas herramientas de empaquetado y distribución garantizar que obtenga los permisos y la propiedad correctos.

Hay dos soluciones alternativas:

1. Habilite el acceso sin privilegios a CLONE_NEWUSER en su kernel. Algunos núcleos admiten cambiar esto con sysctl kernel.unprivileged_userns_clone=1 .
2. Desactive la zona de pruebas por completo iniciando con --no-sandbox . Lamentablemente, agregar este argumento de JS es insuficiente, ya que el proceso de la GPU se inicia antes de que se ejecute el proceso principal JS.

No admitiremos la desactivación automática de la zona de pruebas en Electron cuando se detecten estas condiciones. Debe asegurarse de que sus paquetes distribuidos establezcan los permisos adecuados. La mayoría de las herramientas (al menos electron-builder, electron-installer-snap, electron-installer-debian y electron-installer-redhat) admiten esto automáticamente y no requieren configuración por parte del desarrollador. Si está utilizando una herramienta diferente que no es compatible con esto, plantee un problema en esa herramienta y enlace a este comentario.

Estoy cerrando este problema porque, como se mencionó en el párrafo anterior, no cambiaremos el requisito de que Electron en producción requiera acceso a una caja de arena en funcionamiento a menos que se indique explícitamente lo contrario. Sin embargo, para facilitar el desarrollo, abrí # 19550 para rastrear la opción de degradar automáticamente al modo no aislado cuando Electron se instala a través de npm install , en lugar de a través de un paquete distribuido.

@ p3x-robot puede encontrar un ejemplo mínimo para la solución 2. mencionada por @nornagon aquí, que está inspirada en @vladimiry

@gcascio, pero puedo eliminar el truco, ¿verdad? a medida que se resuelve el chasquido en el generador de electrones, ¿puede confirmarlo?

@gcascio funciona, muchas gracias! ¡funciona!

@gcascio no workie, genera 2 iconos, así que volví a electron v4.2.8 ... :(

@ p3x-robot gracias por los comentarios. En caso de que esté interesado, he creado un problema y lo invadiré tan pronto como tenga tiempo.

@nornagon, por lo que ni siquiera podemos ejecutar Electron 6 en Debian y no hay forma de que le demos permisos de root a un proceso de Chrome. Las soluciones alternativas proporcionadas no son suficientes desde la perspectiva del usuario.

Hay dos soluciones alternativas:
Habilite el acceso sin privilegios a CLONE_NEWUSER en su kernel. Algunos núcleos admiten cambiar esto con sysctl kernel.unprivileged_userns_clone = 1.

No hay forma de que jugar con la computadora del cliente sea la forma de hacerlo.

Desactive la zona de pruebas por completo iniciando con --no-sandbox. Lamentablemente, agregar este argumento de JS es insuficiente, ya que el proceso de la GPU se inicia antes de que se ejecute el proceso principal JS.

¿Qué tal agregar una bandera --sandbox y desactivar la función de zona de pruebas de forma predeterminada? Esto tiene la ventaja de no molestar al 99% de las personas que usan Electron.

Las soluciones alternativas proporcionadas no son suficientes desde la perspectiva del usuario.

El uso de un script / programa similar a un cargador que agregará --no-sandbox arg también se puede considerar como una solución alternativa, por lo que no se necesitan acciones por parte del usuario final. Además, dicho cargador podría probar user namespace support primero y agregar --no-sandbox solo si es necesario.

@pronebird, que proporciona la raíz setuid binaria de chrome-sandbox, es mucho menos peligroso que ejecutar Electron sin una caja de arena. Considere: _ usted es_ el que envía los binarios de Electron, por lo que puede estar seguro de que está enviando un código confiable (por ejemplo, al firmarlo). Sin embargo, si se puede convencer a su aplicación de que cargue código que no es de confianza (posiblemente intencionalmente, por ejemplo, navegando a una URL en la web), entonces la aplicación ejecutará felizmente ese código con el permiso del usuario, sin ningún tipo de espacio aislado. Me preocuparía mucho más la defensa contra ataques centrados en ejecutar JS que no son de confianza en un proceso sin zona de pruebas en su aplicación que los ataques que implican la explotación de un error en el mismo sistema de zona de pruebas que utiliza Chrome. (Y esperaría que este último se solucione _ muy rápido_ si se descubren). Si desea auditar el código del binario chrome-sandbox usted mismo, puede comenzar aquí: https: //chromium.googlesource. com / chromium / src / + / refs / heads / master / sandbox / linux / suid / sandbox.c # 424

Si está comprometido a ejecutar sin una caja de arena de Electron, le recomiendo encarecidamente usar la caja de arena de alguna otra manera, por ejemplo, snapcraft o flatpak, empaquetadores para los que creo que incluyen scripts de inicio que deshabilitan la caja de arena de Electron dentro del contenedor.

@nornagon

dar la raíz setuid binaria de chrome-sandbox es mucho menos peligroso que ejecutar Electron sin una caja de arena. Considere: usted es quien envía los binarios de Electron, por lo que puede estar seguro de que está enviando un código confiable (por ejemplo, al firmarlo). Sin embargo, si se puede convencer a su aplicación de que cargue código que no es de confianza (posiblemente intencionalmente, por ejemplo, navegando a una URL en la web), entonces la aplicación ejecutará felizmente ese código con el permiso del usuario, sin ningún tipo de espacio aislado. Me preocuparía mucho más la defensa contra ataques centrados en ejecutar JS que no son de confianza en un proceso sin zona de pruebas en su aplicación que los ataques que implican la explotación de un error en el mismo sistema de zona de pruebas que utiliza Chrome. (Y esperaría que este último se solucione muy rápidamente si se descubren).

Claro, pero ejecutar una caja de arena tiene poco sentido si tiene una aplicación que nunca carga ningún contenido remoto. Creo que ese tiene que ser el caso de Electron: para crear aplicaciones de escritorio usando la pila web, cargando tal vez JSON desde la web, pero no como solo mostrar páginas web como si no tuviéramos Safari para eso. Ya pasamos los tiempos en que la gente solía envolver sitios web en espacios telefónicos, ¿no es así?

Creo que la sobrecarga es demasiado. Hoy agregué un script de arranque en nuestra aplicación y eliminé el binario chrome-sandbox de la distribución, que eran otros 5 megas. Desafortunadamente, electron-builder no admite nada de esto, por lo que tuvimos que agregar un gancho y hacerlo nosotros mismos.

Si desea auditar el código del binario chrome-sandbox usted mismo, puede comenzar aquí: https://chromium.googlesource.com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox. c # 424

Gracias. Realmente depende de un modelo de amenaza, y no hay forma de que ejecutemos nada de Google con permisos de root.

Puede ser completamente seguro, pero también sería muy difícil verificar que todas las fuentes estén intactas, ya que las compilaciones de electrones se envían a través de npm. Tendríamos que configurar un servidor de compilación personalizado para Electron y auditar las fuentes nosotros mismos. Sería un esfuerzo tremendo y prefiero evitarlo.

@pronebird No voy a involucrarme demasiado en la discusión de la caja de arena, pero mi postura aquí es que deberíamos tener la caja de arena habilitada por defecto como lo hacemos actualmente.

Puede ser completamente seguro, pero también sería muy difícil verificar que todas las fuentes estén intactas, ya que las compilaciones de electrones se envían a través de npm.

Esto es fundamentalmente incorrecto, las construcciones de electrones no se envían a través de npm. El paquete electron en npm es en realidad aproximadamente 2 archivos y ~ 40 líneas de JS. Las compilaciones reales de Electron se entregan a través de S3 y tienen sumas de verificación también en S3 para que la gente pueda validar que la compilación que están descargando es en realidad la compilación que envió Electron.

@MarshallOfSound

Esto es fundamentalmente incorrecto, las construcciones de electrones no se envían a través de npm. El paquete de electrones en npm es en realidad alrededor de 2 archivos y ~ 40 líneas de JS. Las compilaciones reales de Electron se entregan a través de S3 y tienen sumas de verificación también en S3 para que la gente pueda validar que la compilación que están descargando es en realidad la compilación que envió Electron.

Lo que quise decir es que las compilaciones se descargan durante la etapa npm install . No quise decir que estén alojados físicamente en npm. Que estén alojados en S3. Demuestre que estoy equivocado, pero apuesto a que las sumas de verificación están alojadas en el mismo S3, lo que reduce el grado de seguridad de dicho sistema, es solo una pierna. Pero ese no es el punto. Imagine el escenario en el que se manipulan sus compilaciones y se actualizan las sumas de comprobación en consecuencia. Ahora tenemos un problema. Eso es simplemente un control de riesgos y daños de mi parte. Sin raíz = menor riesgo de que suceda algo realmente malo.

El binario de chrome-sandbox de

Sin duda, puede optar por desactivar la zona de pruebas para su caso de uso. Es desafortunado que la arquitectura de Chromium haga que tenga que pasar --no-sandbox en la línea de comandos directamente en lugar de llamar a app.commandLine.appendSwitch ; Idealmente, sería posible deshabilitar la caja de arena sin necesidad de un script de envoltura. Es de esperar que con # 20049 mejore la preocupación de eliminar el binario, ya que 200 KB extra es mucho más razonable para vivir que 5 MB.

¿Existe una opción para usar un sistema binario? Tengo reservas sobre dar un bit de raíz suid a cualquier cosa en mi carpeta node_modules /. Gracias.

@gardner , podría pasar --no-sandbox arg, que es una solución fácil cuando está en modo de desarrollo.

VSCode recientemente cambió a Electron 6 y ahora estamos recibiendo informes de que VSCode ya no se inicia a menos que se proporcione la opción --no-sandbox . ¿Cuál es el camino a seguir aquí? Refs: https://github.com/microsoft/vscode/issues/81056

snap funciona ahora fuera de la caja, para appimage, hay un código escrito:
https://github.com/electron-userland/electron-builder/issues/3872#issuecomment -517875676

el resto no lo sé, solo lanzo NPM, AppImage y SNAP ...

Básicamente, debe volver a empaquetar cada tipo de elemento para agregar un argumento ( --no-sandbox ) al script de inicio.

no hay solución en Electron 6, supongo, o tiene que escribirlo en función de sus paquetes o esperar una solución o una degradación ...

Para una mejor experiencia de desarrollador. Podemos configurar un comando como se muestra a continuación dentro de la herramienta electron cli.

sudo chown root pathToChromeSandboxDynamicallyGenearted && sudo chmod 4755 pathToChromeSandboxDynamicallyGenearted

Un comando como electron --ConfigSandbox.
El usuario estará al tanto y la caja de arena se puede configurar fácilmente.
E incluso cuando se ejecuta por primera vez. Podemos preguntarles si quieren tomar las medidas necesarias. yo n. Y luego todo lo que necesitan hacer es ingresar la contraseña. De esa forma se hará de un vistazo. Y conducirá a una gran experiencia de usuario y ganará con el tiempo. Porque confiarás en el proveedor o en la comunidad. Y hazlo. En lugar de buscar en toda la red. Y eso es aún más valioso para los más principiantes. Y es bueno en todos los casos.

Este problema se ha cerrado, pero todavía lo tengo con electron 7.0.0. ¿Hay algún compromiso que haya resultado en una solución?

¿Por qué se ha cerrado el problema? Parece que no hay una solución disponible, ya que aún persiste incluso en v7.0.0

Porque se trata de empaquetar tu aplicación, pero no de Electron.

Ah bien. Pero, ¿cómo puedo solucionar esto? ¿Hay alguna forma en la que el usuario final no tenga que hacer ningún trabajo adicional?

¿Hay alguna forma en la que el usuario final no tenga que hacer ningún trabajo adicional?

Sí, hay una manera, se ha discutido antes.

sudo sysctl kernel.unprivileged_userns_clone = 1

Hay un problema con los usuarios de WSL (hay muchos que usan WSL) y WSL 1 no usa un kernal de Linux real ... tendríamos que esperar el lanzamiento de WSL2.

Para referencia sobre esta limitación: https://askubuntu.com/questions/1145525/how-to-create-proc-sys-kernel-unprivileged-userns-clone-file

CONFIG_USER_NS = y habilita la función de espacios de nombres de usuario, pero todavía están restringidos a usuarios privilegiados de forma predeterminada. Esto sugiere sysctl kernel.unprivileged_userns_clone = 1

Confirmo que ejecutar sudo sysctl kernel.unprivileged_userns_clone=1 es otra solución alternativa, comentario relacionado.

Sí, uso manjaro e i3wm, tomé el mismo error pero con esto está funcionando.

¿Me estoy perdiendo algo o ya no es posible simplemente descargar y ejecutar una aplicación de Electron sin acceso de root? Lo siento, no me había dado cuenta de que esto era específico de Debian y que el núcleo de la línea principal ni siquiera admite la desactivación de espacios de nombres sin privilegios.

Disculpe mi osadía, pero esto es absolutamente una locura. Electron expone la API de Node.js incluso en procesos de renderizado. Usar / habilitar la caja de arena de Chromium en una aplicación de Electron es completamente inútil y, como todos pueden ver en los informes de errores de GitHub que apuntan a este problema, también es altamente contraproducente. Desactívelo si es posible.

Electron expone la API de Node.js incluso en procesos de renderizado.

nodeIntegration opción

Lo siento, no me había dado cuenta de que esto era específico de Debian y que el núcleo de la línea principal ni siquiera admite la desactivación de espacios de nombres sin privilegios.

Entonces, al ejecutar Debian, parece que tengo suerte de tener acceso de root en mi máquina. Pero, ¿tengo razón en que esta función evitará que los usuarios ejecuten aplicaciones electrónicas (como AppImage o no) sin

a) tener sudo , o
b) ¿poder convencer a alguien que tiene sudo para habilitar espacios de nombres sin privilegios?

@ black-puppydog bueno, si están construyendo la aplicación desde la fuente, podrían editar el script de inicio para pasar el argumento --no-sandbox a electron. Debería ser posible modificar una AppImage con el mismo efecto (desempaquetando y reempaquetando), pero no lo he probado yo mismo. Tampoco es imposible que algunos creadores de AppImage incluyan esa marca en sus compilaciones, en cuyo caso esas imágenes específicas simplemente funcionarían.

De lo contrario, creo que tienes razón. Tenga en cuenta que el kernel de la línea principal siempre tiene habilitados los espacios de nombres sin privilegios y no proporciona ninguna forma de deshabilitarlos. De ahí por qué esto es solo un problema en Debian.

@ black-puppydog Como recuerdo, el instalador le pide una contraseña de root cuando instala Debian en su máquina por primera vez. Pero sí, en Debian (o cualquier otro sistema que use el parche del kernel de Debian), necesita tener acceso de root (a través de sudo o de otra manera), o ejecutar aplicaciones Electron con --no-sandbox .

@ndorf En la línea principal de Linux, los espacios de nombres de usuario se pueden deshabilitar al no compilar en la función, pero no se pueden habilitar / deshabilitar en tiempo de ejecución o restringir solo a procesos con privilegios. Debian parchea sus kernels de modo que los espacios de nombres de usuario están restringidos a procesos privilegiados de forma predeterminada, pero se pueden habilitar para todos los procesos con una configuración por debajo de /proc/sys .

La razón por la que Debian lo restringe es que los espacios de nombres de usuarios sin privilegios son un riesgo de seguridad serio con un largo historial de vulnerabilidades. Los espacios de nombres de usuarios sin privilegios permiten que los procesos sin privilegios accedan a una gran cantidad de funciones del kernel (UID 0, capacidades, montar un sistema de archivos, crear un inodo de dispositivo, etc.) que estuvo restringido a los procesos con privilegios solo durante mucho tiempo. Cualquier código del núcleo basan en la suposición de que los procesos sin privilegios nunca serán capaces de hacer estas cosas es vulnerable ahora que los procesos sin privilegios de repente son capaces de hacer estas cosas.

¿Existe una posible solución mientras tanto hasta que cada distribución de Linux habilite esas características?

Ver el mensaje original:

Si chown y chmod el archivo, entonces funciona bien

También vea aquí # 16631 (comentario) Entonces, para que suid sandbox funcione, básicamente tiene que ajustar el binario chrome-sandbox esta manera:

* `sudo chown root chrome-sandbox`

* `chmod 4755 chrome-sandbox`

Sin embargo, el problema es más grave si se ejecutan paquetes de appimage / snap, aún no he revelado una solución decente para estos casos. Funciona si appimage se ejecuta con --no-sandbox argument, pero esto es un truco.

Esto funciona si estoy ejecutando la aplicación desde el directorio sin empaquetar. ¿Cómo empaqueto este directorio después de cambiar los permisos de chrome-sandbox ?

@ shrinidhi111 4755 se puede conservar cuando se empaqueta, al menos en el caso de paquetes pacman / deb. Los paquetes también se pueden modificar en el nivel de distribución específica, por ejemplo . En cuanto al propietario de la raíz, normalmente cuando el paquete se instala desde el repositorio en Linux, los archivos relacionados obtienen el propietario de la raíz. En el caso de la compilación de AppImage, la vuelvo a empaquetar y codifico --no-sandbox arg en el script interno de AppRun, ya que el generador de electrones no hace eso todavía. El paquete Snap está formado por un generador de electrones con --no-sandbox arg codificado (corrección relacionada agregada hace ~ 6 meses).

@ shrinidhi111 4755 se puede conservar cuando está empaquetado, al menos en el caso de los paquetes pacman / dev. Los paquetes también se pueden modificar en el nivel de distribución específica, por ejemplo . En cuanto al propietario de la raíz, normalmente cuando el paquete se instala desde el repositorio en Linux, los archivos relacionados obtienen el propietario de la raíz. En el caso de la compilación de AppImage, la vuelvo a empaquetar y codifico --no-sandbox arg en el script interno de AppRun, ya que el generador de electrones no hace eso todavía. El paquete Snap está formado por un generador de electrones con --no-sandbox arg codificado (corrección relacionada agregada hace ~ 6 meses).

Crear un archivo instantáneo fue una idea excelente y me ahorró mucho trabajo. ¡Gracias de nuevo!

¿Cómo es esto aún sin resolver?

en snap está arreglado, tengo mi propia compilación que funciona con appimage. porque el resto está sin resolver.

Este hilo es increíblemente largo y todavía se encuentra el error. ¿Hay un resumen de la situación en alguna parte? Quizás ese resumen podría estar vinculado al error.

Parece que https://github.com/electron/electron/issues/17972#issuecomment -495767027 y similares proponen que es suficiente que los electrones funcionen de manera fácil y segura solo en sistemas con acceso root. Tal vez sería bueno si el sistema detectara la configuración de permisos incorrecta y ofreciera advertencias a los desarrolladores, para reducir los usuarios con este problema, pero tal vez ese sea un problema separado. También parece que sería bueno si hubiera una ruta para que los usuarios sin acceso de root usen electron fácilmente, con un conocimiento prominente de que los recursos que no son de confianza son más peligrosos de lo habitual.

ruta para usuarios sin acceso de root para usar electron fácilmente

--no-sandbox argumento CLI.

Vladimiry, estaba pensando, por ejemplo, en usuarios finales sin mucha experiencia en terminales, o ejecutando aplicaciones que envuelven electron

Estaba pensando, por ejemplo, en usuarios finales sin mucha experiencia en terminales o en ejecutar aplicaciones que envuelven electron

Inserte ese --no-sandbox en el acceso directo de la aplicación. Cualquier paquete de Linux aquí funcionará bien independientemente del kernel.unprivileged_userns_clone del sistema

Eso es cierto si soy un desarrollador y hago una advertencia adecuada para mis usuarios finales. ¿No se enterarán muchos desarrolladores de este problema debido a que la zona de pruebas del espacio de nombres funciona para ellos? También es preocupante que las soluciones existentes estén implementadas sin comunicar a las personas involucradas que los recursos que no son de confianza son más peligrosos.

Esta solución solo funciona cuando obtiene este error debido a WSL

Me encontré con este problema al intentar usar electron en WSL (WSL2 en mi caso).
Incluso usando un servidor X11, electron no pudo ejecutarse sobre X11.

Tuve que construir electron para Windows, incluso si lo ejecuto dentro de WSL. Después de eso, todo funciona como salvo.
La forma más sencilla de hacerlo:

• Desinstalar electron npm uninstall electron
• Cambiar la plataforma de configuración npm export npm_config_platform=win32
• Instalar electron npm install electron
• Desmarque la variable de entorno unset npm_config_platform

Esto sugiere sysctl kernel.unprivileged_userns_clone=1

Veo este problema con WSL (Windows 10), Ubuntu 18.04 instalado en WSL.
sudo sysctl kernel.unprivileged_userns_clone=1 no funciona.

sudo sysctl kernel.unprivileged_userns_clone=1
sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory

Usar chown y chmod tampoco es una opción.

@MarshallOfSound zip no admite permisos, pero en última instancia, el problema no es el permiso chmod, sino el propietario. El asistente setuid sandbox es suid _to root_, porque necesita realizar funciones que solo están disponibles para root. Si fuera posible establecer los permisos adecuados sin obtener primero los privilegios de root, sería una vulnerabilidad muy grave en Linux. Afortunadamente para Linux, y desafortunadamente para nosotros, ese no es el caso.

zip _does_ admite permisos en sistemas basados ​​en Unix (o al menos en las variantes de Linux que he probado). Ver https://serverfault.com/a/585889/17620

Los bits de permiso se almacenan en el sufijo de encabezado de archivo del directorio central del zip. El campo externalFileAttributes del sufijo se puede utilizar para almacenar los bits de permisos para cada entrada de archivo / directorio.

cc @MarshallOfSound

Tengo el mismo problema !

[gxz<strong i="6">@localhost</strong> build]$ ./Electron-0.1.1.AppImage 
[23154:0521/155029.728314:FATAL:setuid_sandbox_host.cc(157)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount-E0wZecV/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap(吐核)
[gxz<strong i="7">@localhost</strong> build]$ sudo ./Electron-0.1.1.AppImage 
[sudo] gxz 的密码：
[23191:0521/155048.067790:FATAL:electron_main_delegate.cc(211)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
Trace/breakpoint trap
[gxz<strong i="8">@localhost</strong> build]$ 

ejecutar como usuario normal, tiene error: FATAL:setuid_sandbox_host.cc(157)] 。run como root, tiene error: FATAL:electron_main_delegate.cc(211)]

pero cuando instalo yum snap después, ejecutar como usuario root o normal está bien。

sudo chown root chrome-sandbox
sudo chmod 4755 chrome-sandbox

Esto funciona bien.

@cuixiping funciona: +1:

hice

$ find . -name chrome-sandbox
./node_modules/electron/dist/chrome-sandbox

$ sudo chown root ./node_modules/electron/dist/chrome-sandbox

$ sudo chmod 4755 ./node_modules/electron/dist/chrome-sandbox

Tuve el mismo problema cuando ejecuté electron en Deepin y resolví el problema con este código
electron . --no-sandbox

espero que eso te ayude

no funciona

@fabiospampinato su adaptación desactiva la caja de arena para todos los tipos de paquetes de Linux, pero al menos los paquetes DEB y Pacman funcionan bien con la caja de arena SUID (probablemente todos los paquetes que no son contenedores), solo es necesario establecer el bit de permiso SUID en chrome-sandbox binario. Pero no establezca el bit de permiso SUID para el paquete Snap, ya que Snap Store rechaza este tipo de paquetes. Así que configuré el bit SUID para todos los paquetes de Linux, excepto los paquetes Snap / AppImage que obtienen el código relacionado con el sandboxing deshabilitado.

Hola @vladimiry
No pude acceder al enlace que ha adjuntado aquí. Puedes ayudar con eso?
Además, ¿pudiste descubrir cómo hacer --no-sandbox en el script after-pack del generador de electrones?

Gracias

@ tushar-compro, aquí está https://github.com/vladimiry/ElectronMail/tree/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack. Básicamente configuré 4755 bits en el script after-pack para algunos tipos de paquetes y aún reempaquetando los paquetes appimage + snap. En realidad, el generador de electrones ya ha incrustado --no-sandbox arg en snap pero aún no en appimage https://github.com/electron-userland/electron-builder/pull/4496. Compre el camino, en estos días el constructor de electrones ya establece 4755 bits https://github.com/electron-userland/electron-builder/blob/fc85a42a26df863b5bade4b769182b299ff24e0a/packages/app-builder-lib/templates/linux/after-install.tpl # L7. Así que la versión reciente del generador de electrones debería simplificar las cosas para la mayoría de los desarrolladores.

@vladimiry
Estoy en lo cierto al entender que ha establecido el bit 4755 para objetivos DISTINTOS DE appimage y snap.
https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack/index.ts#L17

Pero el problema ocurre al usar el instalador .appimage en la distribución debian.

¿Me estoy perdiendo de algo?

Pero el problema ocurre al usar el instalador .appimage en la distribución debian.

Como dije, la imagen de la aplicación aún requiere un tratamiento especial. Lo vuelvo a empaquetar e incrusto el --no-sandbox en el script ./AppRun . Busque la palabra clave DISABLE_SANDBOX_ARGS_LINE aquí https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

Pero el problema ocurre al usar el instalador .appimage en la distribución debian.

Como dije, la imagen de la aplicación aún requiere un tratamiento especial. Lo vuelvo a empaquetar e incrusto el --no-sandbox en el script ./AppRun . Busque la palabra clave DISABLE_SANDBOX_ARGS_LINE aquí https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

el último generador de electrones se encarga del argumento no sanbox automáticamente tanto en snap como en appimage.

@vladimiry
Entonces, tengo razón al entender que la configuración de 4755 bits que ha realizado es para instaladores distintos de appimage y snap. Y para appimage ha configurado no-sandbox. ¿Puedes confirmarlo?

@ p3x-robot
si. tienes parcialmente razón.

1. El último generador de electrones establece no sandbox para snap pero NO para appimage. Sin embargo, han configurado 4755 bits para appimage.
2. En mi proyecto estoy usando electron-versión 20.xx Actualizarlo a 22.xx será un esfuerzo en sí mismo. Solo trato de evitar eso si es posible. La actualización a la v22 será el último recurso.

el último generador de electrones se encarga del argumento no sanbox automáticamente tanto en snap como en appimage.

Todavía no se pudo ubicar en su código el fragmento específico de la imagen de la aplicación similar a este solicitado para las instantáneas (https://github.com/electron-userland/electron-builder/pull/4496 aún abierto). De todos modos, en mi caso, todavía es necesario volver a empaquetar, ya que puse allí argumentos adicionales, además de los relacionados con sanbox.

Entonces, tengo razón al entender que la configuración de 4755 bits que ha realizado es para instaladores distintos de appimage y snap. Y para appimage ha configurado no-sandbox. ¿Puedes confirmarlo?

Correcto. Pero el constructor de electrones moderno establece 4755 internamente. Sin embargo, verifico que no esté configurado para snap / appimage, ya que eso sería un error. Por ejemplo, snap no comenzará con 4755 bits configurados en electron binary si recuerdo las cosas correctamente.

@vladimiry
Solo necesito configurar no-sandbox ya que mis imágenes de aplicación no funcionan en Debian.

Creo que no necesitaré volver a empaquetar en este caso. Pero no pude encontrar la documentación correcta del generador de electrones para hacer eso. ¿O crees que también necesitaré volver a empaquetar?

¿Puede indicarme la documentación correcta que pueda ayudarme a hacerlo?

Además, entiendo que tengo las dos opciones, ya sea configurando 4755 bit o configurando no sandbox.
¿Cuál crees que es mejor?

Además, entiendo que tengo las dos opciones, ya sea configurando 4755 bit o configurando no sandbox.

Si recuerdo las cosas correctamente, la configuración 4755 de appimage no resolverá el problema. Necesitas (uno de):

• inicie su archivo de imagen de aplicación con --no-sandbox línea de comando arg
• tener --no-sandbox incrustado en el script ./AppRun ubicado en su archivo de imagen de aplicación (por lo que es necesario volver a empaquetarlo).

¿Puede indicarme la documentación correcta que pueda ayudarme a hacerlo?

Dudo que encuentre información detallada sobre el problema en cualquier documentación. No tengo conocimiento de ningún documento relevante.

Además, entiendo que tengo las dos opciones, ya sea configurando 4755 bit o configurando no sandbox.

Si recuerdo las cosas correctamente, la configuración 4755 de appimage no resolverá el problema. Necesitas (uno de):

• iniciarlo con --no-sandbox línea de comando arg
• tener --no-sandbox incrustado en el script ./AppRun ubicado en su archivo appiamge (por lo que es necesario volver a empaquetarlo).

¿Puede indicarme la documentación correcta que pueda ayudarme a hacerlo?

Dudo que encuentre información detallada sobre el problema en cualquier documentación. No tengo conocimiento de ningún documento relevante.

El último generador de electrones incorpora el --no-sandbox en el ./AppRun , que solía volver a empaquetar, pero ahora es inútil, solo uso el generador de electrones nativo.

@vladimiry
si. configurar 4755 solo no funcionará. Con 4755 necesitamos cambiar el propietario de chrome-sandbox a root.
De todos modos, muchas gracias por tu ayuda. Intentaré referir tu código y configurar el no-sandbox entonces.

@ p3x-robot
¿Puede compartir algún enlace (repositorio de generador de electrones) donde podamos ver el código haciendo esto?

https://github.com/patrikx3/onenote

@vladimiry
si. configurar 4755 solo no funcionará. Con 4755 necesitamos cambiar el propietario de chrome-sandbox a root.
De todos modos, muchas gracias por tu ayuda. Intentaré referir tu código y configurar el no-sandbox entonces.

@ p3x-robot
¿Puede compartir algún enlace (repositorio de generador de electrones) donde podamos ver el código haciendo esto?

https://github.com/patrikx3/onenote

El último generador de electrones incorpora --no-sandbox en ./AppRun, solía volver a empaquetar, pero ahora es inútil, solo uso el generador de electrones nativo.

Lo probé usando la versión reciente del generador de electrones y no incorpora el --no-sandbox en el script ./AppRun sh. Si inicia la imagen de la aplicación, falla con el error conocido [759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found -like. Tal vez tengas habilitada la bandera kernel.unprivileged_userns_clone en tu sistema. Si es así, intente deshabilitarlo como sudo sysctl kernel.unprivileged_userns_clone=0 y vuelva a iniciar el archivo de imagen de la aplicación.

El último generador de electrones incorpora --no-sandbox en ./AppRun, solía volver a empaquetar, pero ahora es inútil, solo uso el generador de electrones nativo.

Lo probé usando la versión reciente del generador de electrones y no incorpora el --no-sandbox en el script ./AppRun sh. Si inicia la imagen de la aplicación, falla con el error conocido [759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found -like. Tal vez tengas habilitada la bandera kernel.unprivileged_userns_clone en tu sistema. Si es así, intente deshabilitarlo como sudo sysctl kernel.unprivileged_userns_clone=0 y vuelva a iniciar el archivo de imagen de la aplicación.

extraño, hay instalaciones instantáneas de 10k con el último generador de electrones. y definitivamente el constructor de electrones muestra que agrega esa bandera ...

hay 10k snap

Estamos hablando de appimage, no de snap. Snap, por supuesto, tiene el arg incrustado como mencioné anteriormente, aquí https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197 -L202.

hay 10k snap

Estamos hablando de appimage, no de snap. Snap, por supuesto, tiene el arg incrustado como mencioné anteriormente, aquí https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197 -L202.

tienes razón. Estaba pensando que por alguna razón se hizo en appimage, incluso eliminé el código para el re-empaquetado y agregué no-sandbox, pero lo intenté nuevamente y veo que falta, así que agregué mi reversión de mi compilación, no obras. lo siento, en mi corifeus-builder, puedes ver lo que estoy haciendo: https://github.com/patrikx3/corifeus-builder/blob/master/src/utils/appimage/after-all-artifact-build.js

Hola @nornagon, considerando lo común que es este problema, ¿se puede actualizar el tutorial oficial de inicio rápido de electron para incluir la solución para que los novatos tengan una experiencia positiva?

Editar: Gracias al estímulo de la comunidad, he abierto un FR # 26478

@gabefair Parece una propuesta razonable. ¿Estaría interesado en abrir un PR?