Electron: O binário do auxiliar sandbox SUID foi encontrado, mas não está configurado corretamente

Infelizmente, não há como configurar isso corretamente de forma automática, porque definir as permissões apropriadas requer privilégios de root e não queremos pedir uma senha de root durante npm install .

Idealmente, o Arch configuraria seu suporte ao kernel CLONE_NEWUSER sem privilégios e o Chromium (e Electron) poderia usar a sandbox do namespace em vez de depender da antiga sandbox setuid. Os aplicativos distribuídos no Linux precisarão incorporar isso em seu processo de instalação. Veja https://github.com/electron-userland/electron-installer-debian/pull/184 e https://github.com/electron-userland/electron-installer-redhat/pull/112 por exemplo.

Durante o desenvolvimento, provavelmente devemos imprimir algo em npm install embora com instruções, se detectarmos que a caixa de proteção do namespace não está disponível.

Ei, obrigado pela resposta super rápida!

CLONE_NEWUSER sem privilégios vem de CONFIG_USER_NS=y ? Em caso afirmativo, essa deve ser a configuração atual.

Por favor, deixe-me saber se há algo que eu possa fazer para ajudar, ou se esta é uma saída esperada no Arch, fico feliz em encerrar - eu entendo que há algum mal-estar a ser esperado ao executar distros de última geração e não me importo resolvendo isso em um PKGBUILD vez de esperar que funcione perfeitamente direto do npm. Felicidades!

CONFIG_USER_NS=y ativa o recurso de namespaces de usuário, mas eles ainda estão restritos a usuários privilegiados por padrão. Isso sugere sysctl kernel.unprivileged_userns_clone=1

Existe uma solução possível enquanto isso, até que cada distribuição Linux habilite esses recursos?

@kitingChris A sandbox setuid É a solução alternativa. Você só precisa garantir que, ao desenvolver / lançar um aplicativo eletrônico, seus scripts de desenvolvimento / empacotamento definam as permissões do helper sandbox corretamente como @nornagon no

Existe uma solução possível enquanto isso, até que cada distribuição Linux habilite esses recursos?

Veja a mensagem original:

Se eu chown e chmod o arquivo, ele funciona bem

Veja também aqui https://github.com/electron/electron/issues/16631#issuecomment -476082063 Então, para fazer suid sandbox funcionar, você basicamente precisa ajustar o binário chrome-sandbox desta forma:

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

O problema é mais grave, embora, ao executar pacotes appimage / snap, eu ainda não tenha revelado uma solução alternativa decente para esses casos. Ele está funcionando se o appimage for executado com --no-sandbox arguemnt, mas isso é um hack.

@nornagon

porque definir as permissões apropriadas requer privilégios de root e não queremos pedir uma senha de root durante a instalação do npm.

Executar chmod 4755 node_modules/electron/dist/chrome-sandbox não requer permissão de root e isso deve ser o suficiente para executar tal comando para empacotar o aplicativo para pacotes deb / pacman / etc, como quando tais pacotes são instalados todos os arquivos incluindo chrome-sandbox normalmente propriedade da raiz. Portanto, seria ótimo que o elétron fizesse chmod 4755 node_modules/electron/dist/chrome-sandbox automaticamente durante o processo de instalação, pois não haveria necessidade de lidar com este caso manualmente, como mencionado aqui .

CONFIG_USER_NS = y ativa o recurso de namespaces de usuário, mas eles ainda estão restritos a usuários privilegiados por padrão. Isso sugere sysctl kernel.unprivileged_userns_clone = 1

Confirmo que a execução de sudo sysctl kernel.unprivileged_userns_clone=1 é outra solução alternativa, comentário relacionado.

@vladimiry Eu precisava primeiro fazer o chown e depois o chmod. O contrário não funcionou.

@burningTyger você está certo , acabei de alterar a mensagem original.

@nornagon Se chmod 4755 out/Release/chrome-sandbox em CI, essa permissão será mantida assim que zip aumentar ou teremos que fazer essa alteração em electron-download para corrigir a permissão em DL?

mesmo aqui é uma função nova ruim para o que precisa mudar isso ... :(

@MarshallOfSound zip não oferece suporte a permissões, mas, em última análise, o problema não é a permissão chmod, mas sim o proprietário. O auxiliar de sandbox setuid é suid _to root_, porque ele precisa executar funções que estão disponíveis apenas para root. Se fosse possível definir as permissões apropriadas sem primeiro obter privilégios de root, isso seria uma vulnerabilidade muito séria no Linux. Felizmente para o Linux, e infelizmente para nós, esse não é o caso.

Aqui estão as opções conforme as vejo:

1. Não mude nada no elétron. Recomende que os desenvolvedores habilitem CLONE_USERNS sem privilégios em seu kernel para permitir que a sandbox do namespace seja executada em vez da sandbox setuid.
2. Inicialize sem sandbox se nenhum método de sandbox estiver disponível _somente ao inicializar um aplicativo não empacotado_. Se o Electron estiver inicializando um aplicativo empacotado, recuse-se a inicializar sem sandbox.
3. Em todos os casos, se nenhum método de sandbox estiver disponível, inicialize sem sandbox e imprima um aviso.
4. Desative o sandbox por padrão no Linux.

Estou inclinado para (2). Isso facilitaria o desenvolvimento sem comprometer a segurança do aplicativo implantado.

Ainda não tenho certeza do que fazer com o snap / flatpak, pois não estou familiarizado com seu funcionamento. É possível que eles já tenham feito uma sandbox do aplicativo o suficiente para que possamos desabilitá-la completamente nessa situação, como fazemos ao construir a versão do Electron para a Mac App Store.

Por enquanto, gosto mais da primeira opção.

1. Inicialize sem sandbox se nenhum método de sandbox estiver disponível apenas ao inicializar um aplicativo não empacotado. Se o Electron estiver inicializando um aplicativo empacotado, recuse-se a inicializar sem sandbox.

Esse cenário seria de alguma forma enganoso. Pode-se executar com êxito o aplicativo descompactado sem sandboxing, mas há uma chance de que o aplicativo empacotado não funcione da mesma maneira com sandboxing habilitado. Como, por exemplo, o caso em que você acessa o processo principal a partir do processo renderizador e não por meio da interface remote . Ou o caso de empacotar o aplicativo em pacotes AppImage / Snap / Flatpak.

1. Em todos os casos, se nenhum método de sandbox estiver disponível, inicialize sem sandbox e imprima um aviso.

Portanto, um aplicativo empacotado que foi projetado e desenvolvido como sandbox pode ser executado sem sandbox se não houver sandbox disponível. Isso não parece bom para mim.

1. Desative o sandbox por padrão no Linux.

O que isso significa exatamente? Qual seria a maneira de habilitar o sandbox no Linux na forma como o aplicativo inicia ou falha se não houver sandbox disponível (a situação atual, sandbox forçado).

Eu também gosto de (1), mas para defender (2) um pouco, a API exposta ao aplicativo não mudaria ao desabilitar a sandbox. A única coisa que desabilitaríamos é a sandbox no nível do sistema operacional. Nós ainda carregaríamos o aplicativo da mesma maneira, apenas não seria protegido pelo sistema operacional.

Nós ainda carregaríamos o aplicativo da mesma maneira, apenas não seria protegido pelo sistema operacional.

Então também parece bom para mim. Obrigada pelo esclarecimento.

Eu não gosto de 2., porque a segurança opcional geralmente leva as pessoas a desativá-la.

Entrando no lugar do "usuário estúpido" agora, eu prefiro ver o Electron funcionar por padrão. Se for uma medida de segurança muito importante, avise-me e explique por que preciso fazer um trabalho extra. Se não for tão importante, então não me venha com o gosto ruim de "não funciona".

Por causa disso, gosto de 1. (com uma parada forçada, como agora) ou 4.

: x: chown root:root chrome-sandbox && chmod 4755 chrome-sandbox levanta algumas bandeiras vermelhas para mim.

Só para ficar bem claro o que ele faz: ele define o bit SUID em chrome-sandbox , o que torna _qualquer usuário_ capaz de executar o arquivo _como root_. Isso significa que se houver alguma maneira de usar chrome-sandbox maliciosamente, ou se o conteúdo se tornar malicioso, qualquer usuário pode se tornar root. chrome-sandbox seria um alvo muito interessante para o ataque.

Eu recomendo fortemente não fazer esta solução alternativa em npm install , porque exigiria sudo (o usuário precisa escrever a senha), é invasivo e podemos não entender as consequências de segurança de fazê-lo.

chown root: root chrome-sandbox && chmod 4755 chrome-sandbox levanta algumas bandeiras vermelhas para mim.

Claro que sim. Mas você pode habilitar o sandbox do namespace do usuário como uma alternativa sudo sysctl kernel.unprivileged_userns_clone=1 (habilitado por padrão no Ubuntu, mas não no Arch).

Só para ficar bem claro o que ele faz: ele define o bit SUID em chrome-sandbox , o que torna _qualquer usuário_ capaz de executar o arquivo _como root_. Isso significa que se houver alguma maneira de usar chrome-sandbox maliciosamente, ou se o conteúdo se tornar malicioso, qualquer usuário pode se tornar root. chrome-sandbox seria um alvo muito interessante para o ataque.

Sim, mas também este binário é exatamente o mesmo que vem com o Chrome, então se você está preocupado com isso, você provavelmente também deve desinstalar o Chrome :)

Existe uma maneira de executar sem o sandbox / executar sem o "helper sandbox"? Os primeiros usuários reclamaram 😅
Eu esperava que isso desabilitasse a sandbox, mas ainda recebo o erro The SUID sandbox helper binary was found, but is not configured correctly .
Eu odiaria voltar para o elétron 4.x 🤨

Mensagem de erro

Snapcraft Review e suid

Tentei fazer o upload de um snap com sinalizador suid em chrome-sandbox mas o processo de revisão do snapcraft proíbe o uso de sinalizadores 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 desabilitar o --no-sandbox precisa ser passado como um argumento de aplicativo, ou seja, app.commandLine.appendSwitch não será suficiente. Com relação a um pacote Snap, você pode querer tentar adicionar um plug como descrito aqui . Não tenho certeza se isso vai ajudar, pois ainda não experimentei, seria ótimo se você o fizesse. Por enquanto, prefiro lançar o aplicativo que estou construindo no modo misto : smile :

Se o Snapcraft proíbe os sinalizadores de suid, então provavelmente a única opção é desabilitar o sandboxing do Electron inteiramente no Snapcraft e contar com o contêiner que o Snapcraft usa. Não tenho certeza de qual é a melhor maneira de fazer isso - é possível especificar sinalizadores de linha de comando adicionais ao empacotar por meio do Snapcraft? Nesse caso, poderíamos adicionar a sinalização --no-sandbox . Caso contrário, podemos precisar adicionar algum mecanismo de detecção específico para detectar a execução no Snapcraft / Flatpak e desativar o sandbox com base nessa detecção.

Alguma documentação relacionada ao Snap https://docs.snapcraft.io/browser-support-interface

@ posix4e você pode lançar alguma luz sobre a questão de executar o pacote Snap em sandbox nos modos User Namespace e SUID sandbox / fallback? Parece que você tem uma experiência relevante de ajustes de configuração de snap do Brave Browser. CC @flexiondotorg.

Só para ficar bem claro o que ele faz: ele define o bit SUID em chrome-sandbox , o que torna _qualquer usuário_ capaz de executar o arquivo _como root_. Isso significa que se houver alguma maneira de usar chrome-sandbox maliciosamente, ou se o conteúdo se tornar malicioso, qualquer usuário pode se tornar root. chrome-sandbox seria um alvo muito interessante para o ataque.

Sim, mas também este binário é exatamente o mesmo que vem com o Chrome, então se você está preocupado com isso, você provavelmente também deve desinstalar o Chrome :)

Estou parcialmente preocupado em permitir que um binário do Chrome tenha root:root com SUID definido, sim. Muito pouco código está sem bugs. Aqui está o código-fonte, para registro: https://github.com/chromium/chromium/tree/master/sandbox/linux/suid

Mas estou mais preocupado se npm install :

1. Baixe um monte de software em tempo real.
2. Faça automaticamente um dos arquivos root:root e SUID.

Acho que essa seria a primeira pilha de software que conheço que faz um sudo chown root:root && sudo chmod 4755 automaticamente em um arquivo pertencente a um usuário não root.

Fazer sudo chown root:root && sudo chmod 475 na instalação do npm deve estar fora de questão, o npm precisa ser executado como root para definir as permissões. O modelo de gancho do npm permitiria que todos os pacotes instalados executassem seus ganchos como root também. Com possivelmente centenas de pacotes e dependências aninhadas, isso seria muito perigoso.

Fazer um sudo chown root: root && sudo chmod 475 na instalação do npm deve estar fora de questão

Isso não é considerado uma opção, tanto quanto eu entendo.

Eu concordo que fazer qualquer coisa que exija privilégios de root durante a instalação do npm não é inicial. É por isso que não a listei como uma das opções .

Pelo que vale a pena, electron-installer-debian 1.2.0, electron-installer-redhat 1.1.0 e electron-installer-snap 3.2.0 foram lançados com as alterações da sandbox SUID. Electron Forge v5 e v6 beta devem ser atualizados transitivamente também (por meio de atualizações de versão dentro do intervalo, use npm update ou yarn upgrade apropriadamente).

Apenas vinculando o código relacionado para maior clareza.

Só para ficar claro, para os Snaps havia mais do que isso (ou seja, adicionar suporte a sandbox do navegador, conforme observado acima). Consulte as alterações do PR associado para obter detalhes.

Acabei de clicar aqui, chown / chmod funciona, mas essa não é a única ação necessária se você estiver executando dentro de uma imagem Docker.

Se você simplesmente fizer isso, receberá outro erro:

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

A solução para isso é adicionar --privileged ao comando docker run . Não acho que seja uma boa solução, principalmente na CI.

@JCMais , parece que o Electron está tentando usar incorretamente a caixa de areia do namespace dentro do docker, embora deva estar tentando usar a caixa de areia suid. Não sei por que isso seria, mas você pode forçar a sandbox suid com --disable-namespace-sandbox . Se você iniciar o docker com --privileged (ou --cap-add SYS_ADMIN , ou um perfil seccomp personalizado que permite CLONE_NEWUSER), os namespaces estarão disponíveis dentro da sandbox e não há necessidade da sandbox setuid ou de seu executável auxiliar .

Como @thomasnordquist , acabei desabilitando o sandbox para pacotes Snap / AppImage usando o script de pré-carregamento. Você cria um script sh semelhante à pré-carga nomeado como binário original que então é usado para carregar binário eletrônico renomeado / original com o argumento --no-sandbox . É conveniente fazer no script after-pack do construtor de elétrons

@nornagon como exatamente devo passar esta bandeira para o elétron? Tentei apenas adicionar --disable-namespace-sandbox mas continua apresentando um erro:

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

Posso confirmar que isso me destruiu rapidamente e que todos os nossos usuários Linux estão presos em uma versão antiga até que eu possa remediar isso.

Estou TOTALMENTE procurando uma maneira de melhorar a segurança, mas isso foi enviado sem um sinalizador de recurso para desativá-lo.

Eu também gostaria de argumentar que isso não deveria ter sido enviado sem um recurso para desativá-lo por meio de código. Eu acho que talvez isso tenha sido acidental porque --no-sandbox não funciona a menos que seja fornecido manualmente na linha de comando.

Se houver algo errado com a forma como electron-installer-snap implementou o suporte para sandbox, por favor, me avise no rastreador de problemas.

Se houver algo errado com o modo como o electron-installer-snap implementou o suporte sandbox, por favor, me avise no rastreador de problemas.

Também gostaria de ouvir alguém confirmar que a mudança é suficiente para resolver o problema com os pacotes Snap. Assim, tanto os feedbacks positivos quanto os negativos são bem-vindos. Veja informações relacionadas.

@vladimiry Eu fui em frente e testei e não funcionou.

Preciso de uma solução que não resolva em torno de patches de SO, sysctl ou reinicializações. Preciso de algo que funcione agora. --no-sandbox seria o preferido.

Seria muito mais útil para mim se alguém pudesse fornecer um aplicativo Electron mínimo que eu pudesse usar para reproduzir o Snap empacotado que não funciona. Eu usei um fork de electron-quick-start para construir um Snap no CircleCI e instalei-o em meu laptop (Debian Stretch) para verificar se minhas alterações pelo menos criaram um aplicativo Electron em funcionamento.

"Não funcionou" não me ajuda a identificar o que posso fazer em electron-installer-snap para que ele empacote corretamente para os outros.

@burtonator , obrigado por testar o material. Até onde eu sei, empacotado no script bash / sh semelhante ao carregador de compilação Snap / AppImage que inicia o binário / elétron original com o argumento --no-sandbox cmd é a única solução alternativa verificada por enquanto.

@malept antes de testar o material, é necessário desabilitar o recurso do sistema operacional do namespace do usuário executando sudo sysctl kernel.unprivileged_userns_clone=0 .

@vladimiry sim, meu laptop já tem aquela configuração de userns.

Se alguém está procurando uma solução para isso, dê uma solução de @thomasnordquist ou na minha adaptação dela, eles trabalham desabilitando a sandbox no Linux.

@fabiospampinato sua adaptação desabilita o sandbox para todos os tipos de pacotes Linux, mas pelo menos os pacotes DEB e Pacman funcionam bem com o sandbox SUID (provavelmente todos os pacotes não semelhantes a contêineres), há apenas a necessidade de definir o bit de permissão SUID para chrome-sandbox binário. Mas não defina o bit de permissão SUID para o pacote Snap, pois o Snap Store rejeita esses tipos de pacotes. Portanto, eu defino o bit SUID para todos os pacotes Linux que esperam pacotes Snap / AppImage que têm sandboxing desabilitado, código relacionado .

CONFIG_USER_NS = y ativa o recurso de namespaces de usuário, mas eles ainda estão restritos a usuários privilegiados por padrão. Isso sugere sysctl kernel.unprivileged_userns_clone = 1

Confirmo que a execução de sudo sysctl kernel.unprivileged_userns_clone=1 é outra solução alternativa, comentário relacionado.

Obrigado cara, trabalhando para mim! @vladimiry

vocês sabem se funciona agora com 5.0.2?

@ p3x-robot Nenhuma menção a este problema no changelog. Apenas verifiquei para ter certeza de que o erro ainda está lá para mim.

@rybaczewa obrigado pela resposta, continuo com a v4 também, pois é um grande problema, mal posso esperar até que a v5 esteja funcionando, tchau

não posso esperar até que a v5 esteja funcionando

v5 está funcionando

Para deixar claro para o pessoal deste tópico, @ p3x-robot @rybaczewa, esse problema foi deixado em aberto para fins informativos /

Se você está vendo esta mensagem de log, você precisa executar sudo sysctl kernel.unprivileged_userns_clone=1 ou dar ao binário chrome_sandbox as permissões corretas conforme descrito na mensagem de erro.

@vladimiry @MarshallOfSound, por que você está dizendo que isso foi corrigido? No Snap, não consigo instalar meus aplicativos P3X Redis e P3X Onenote nem sudo sysctl kernel.unprivileged_userns_clone=1 ou fornecer chrome_sandbox v5.0.x. Só consigo instalar com v4.xx

Você acha que um usuário vai querer usar sudo ? Eles vão pensar que este programa é ruim e vão desinstalar o aplicativo.
As versões v5 ou v6 ou v7 não estão funcionando direito, portanto, este é um bug :

@ p3x-robot snap suporte conforme indicado acima depende de como você faz o snap. electron-installer-snap tem suporte para isso fora da caixa e, conforme mencionado acima, se esse módulo tiver problemas / não estiver funcionando, indique um problema nesse módulo.

Consulte o electron-installer-snap repo para obter detalhes ou os documentos do sandbox de navegador

Para reiterar, meu entendimento atual aqui é que não há nenhum bug a ser corrigido, a sandbox do Electron está operando conforme o esperado. O que está sendo discutido aqui são problemas que as pessoas estão enfrentando ao empacotar o binário chrome_sandbox

isso é estranho, porque eu já adicionei o sandbox:

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

saída:

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$ 

Eu tento isso como: app.enableSandbox() , mas recebo:

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

Se eu remover a linha, funciona.

@MarshallOfSound estou usando electron-builder

para todos vocês, se quiserem fazer funcionar, criei um ajudante:
https://github.com/patrikx3/redis-ui/blob/master/src/build/after-pack.js
se você estiver usando electron-builder , adicione-o assim:

para todos vocês, se quiserem fazer funcionar, criei um ajudante:

Tal solução já foi muitas vezes mencionada nesta discussão do assunto, por isso escrevi antes que o elétron v5 está funcionando.

@vladimiry obrigado, perdi esta solução, acabei de adicionar uma solução nativa de javascript em vez de typescript ...

o único problema é que quando eu faço esse after pack hack, ele não está usando no painel o ícone do electron, mas gera um segundo ícone, como isso pode ser resolvido? Acho que é a sinalização sem sandbox que faz isso. qualquer um?

isso só está acontecendo com --no-sandbox :

@fabiospampinato sua adaptação desabilita o sandbox para todos os tipos de pacotes Linux, mas pelo menos os pacotes DEB e Pacman funcionam bem com o sandbox SUID (provavelmente todos os pacotes não semelhantes a contêineres), há apenas a necessidade de definir o bit de permissão SUID para chrome-sandbox binário. Mas não defina o bit de permissão SUID para o pacote Snap, pois o Snap Store rejeita esses tipos de pacotes. Portanto, eu defino o bit SUID para todos os pacotes Linux que esperam pacotes Snap / AppImage que têm sandboxing desabilitado, código relacionado .

vocês sabem como posso manter um ícone em vez de dois?

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

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

@ p3x-robot existe uma maneira de adicionar o argumento --no-sandbox ao aplicativo de contêiner do Snap empacotado sem introduzir um script bash / sh semelhante ao pré-carregador:

• Descompacte o snap primeiro executando unsquashfs your-snap-file.snap .
• Edite ./squashfs-root/command.sh adicionando aqui os argumentos necessários.
• Empacote a pasta ./squashfs-root volta ao pacote de snap executando o comando snapcraft pack ./squashfs-root .

Não tentei, mas acho que a ação de reembalagem semelhante pode ser aplicada ao pacote AppImage também, ou seja, uma questão de executar diferentes comandos de desempacotar / empacotar.

Acho que as ações de reempacotamento descritas podem ser acionadas no gancho de afterAllArtifactBuild construtor de elétrons.

@vladimiry obrigada, muito, pelo que é interessante para o afterAllArtifactBuild, tentarei alterar o command.sh sem descompactar, mas é para amanhã, obrigado novamente!

o que é interessante para o afterAllArtifactBuild

@ p3x-robot afterAllArtifactBuild hook na verdade não está sendo acionado como eu esperava, mas é muito fácil acionar o Snap ou qualquer outro tipo de pacote de construção programaticamente. Veja aqui o exemplo de código. snapFile é o arquivo resultante aqui, então você pode descompactá-lo / unsquashfs então, aplicar as mudanças necessárias e empacotar de volta / snapcraft pack . No código de exemplo, coloco os dicionários Hunspell na pasta ./usr/share/hunspell do Snap.

@vladimiry acabei de usar o Electron v4, pois está funcionando. Acho que alguém vai consertar isso.

@ p3x-robot Ainda tendo a pensar que você tem que admitir que não há nada para consertar.

@vladimiry não há nada para consertar, claro. :)

alguém sabe se Electron v5.0.2 trabalhando com o problema do sandbox?

É, igual a v.5.0.0: smile:

Espero que isso não esteja fora do tópico, mas para AppImages no Debian (9), recebo o erro:

The setuid sandbox is not running as root. 

Corrija-me se eu estiver errado, mas eu entendo (principalmente a partir desta discussão) que isso é causado pelo recurso de namespaces de usuário desabilitado, que é desabilitado por padrão no Debian.

Então, em relação a esta sugestão:

1. Não mude nada no elétron. Recomende que os desenvolvedores habilitem CLONE_USERNS sem privilégios em seu kernel para permitir que a sandbox do namespace seja executada em vez da sandbox setuid.

Gostaria de exibir uma mensagem aos usuários dizendo que só funciona quando o recurso de namespaces do usuário está habilitado (talvez com uma dica de como fazer isso) e sugiro o uso do pacote .deb como alternativa.

Como poderia implementar tal mensagem antes que o erro fosse mostrado? Existe uma maneira de anexar um script personalizado ao AppRun do AppImage sem descompactar e reembalar?

Existe uma maneira de anexar um script personalizado ao AppRun do AppImage sem descompactar e reembalar?

@gcascio havia mensagens no tópico sobre o uso de um script sh semelhante ao carregador que pode ser injetado pelo script afterpack .

Obrigado pela sua resposta. Mas acho que o AppRun gerado não está disponível quando afterpack é chamado ou estou errado, pelo menos não consigo encontrá-lo em appOutDir ?

Eu acho que o AppRun gerado não está disponível quando o afterpack é chamado

Eu estava escrevendo sobre o uso de um script sh semelhante ao carregador, mas não sobre o patch de script AppRun. Se você deseja corrigir o script AppRun, parece não haver maneira de fazer isso sem recompactar.

Ok certo, entendi mal. Talvez eu vá com a reembalagem, então, obrigado.

Talvez eu vá com a reembalagem, então, obrigado.

@gcascio caso precise de um template .

ia mesmo erro "O binário do auxiliar sandbox SUID foi encontrado", mas no arquivo instantâneo após a instalação
como posso consertar isso

@vladimiry Estou trabalhando em um IDE Docker online chamado http://gitpod.io executando um contêiner Debian. Não consigo corrigir o problema do cromo-sandbox, pois não tenho acesso ao sudo. O tom geral aqui é que se trata de um problema do Chrome e não do Electron, mas se o Electron pudesse resolver o problema, isso seria uma coisa boa?

Neste site https://www.gitpod.io/blog/gitpodify/ eu vi uma solução para usar o Puppeteer no contêiner.

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

A Electron poderia tentar algum código como esse se o erro da sandbox ocorrer, antes de encerrar o processo? Ou isso é algo que eu poderia invocar com um arquivo bash?

A Electron poderia tentar algum código como esse se o erro da sandbox ocorrer, antes de encerrar o processo? Ou isso é algo que eu poderia invocar com um arquivo bash?

Sim, passar o argumento --no-sandbox para o binário do aplicativo de elétrons em geral deve contornar o problema.

Dependendo do pacote de instalação, você pode definir o bit de permissão SUID (4755) para chrome-sandbox binário (para pacotes como deb, pacman, etc) ou codificar o argumento --no-sandbox para o script sh / bash do carregador (para pacotes como Snap e AppImage). Isso é o que eu faço atualmente e, portanto, não há necessidade de fazer nada para os usuários do aplicativo (nenhum acesso sudo necessário).

O lançamento recente --no-sandbox mas apenas para o pacote Snap.

Obrigado @vladimiry electron --no-sandbox parece ter superado o problema. Também verificarei o SNAP.

existem criadores de elétrons mais novos, mas o AppImage ainda não foi corrigido, correto?

O elétron 6 está corrigindo o erro da sandbox? Ainda estou na v4 porque não consigo consertar isso, nem 5 ou 6.

Esta é a situação:

• Electron v5 habilitou sandbox de modo misto (ou seja, alguns processos sendo sandbox e outros não) no Linux. Isso não muda se seus processos de renderização estão em sandbox por padrão, mas significa que o processo de GPU agora está em sandbox.
• A sandbox do Chromium no Linux usa um recurso do sistema operacional chamado CLONE_NEWUSER . Alguns kernels são construídos com esse recurso restrito a usuários privilegiados por precaução. Você pode ler mais sobre isso aqui [lwn, 2016].
• Quando CLONE_NEWUSER não está disponível, o Chromium volta a usar um mecanismo de sandbox diferente que requer um binário auxiliar configurado para fazer o root. Se este binário não estiver presente ou não tiver as permissões corretas ( 4755 _e pertencente a root_), o sandbox falhará ao inicializar.
• A configuração das permissões binárias do auxiliar deve ser feita por um usuário privilegiado (ou seja, root). Não definimos essas permissões em npm install , porque não queremos solicitar acesso root durante npm install .
• Os pacotes de lançamento do Electron v5 incluem o binário auxiliar, mas cabe às várias ferramentas de empacotamento e distribuição garantir que ele obtenha as permissões e propriedade corretas.

Existem duas soluções alternativas:

1. Habilite o acesso sem privilégios a CLONE_NEWUSER em seu kernel. Alguns kernels suportam mudar isso com sysctl kernel.unprivileged_userns_clone=1 .
2. Desative totalmente o sandbox, iniciando com --no-sandbox . Adicionar este argumento de JS infelizmente é insuficiente, já que o processo de GPU é iniciado antes que o processo principal JS seja executado.

Não ofereceremos suporte à desativação automática da sandbox no Electron quando essas condições forem detectadas. Você deve garantir que seus pacotes distribuídos definam as permissões apropriadas. A maioria das ferramentas (pelo menos electron-builder, electron-installer-snap, electron-installer-debian e electron-installer-redhat) suportam isto automaticamente e não requerem configuração do desenvolvedor. Se você estiver usando uma ferramenta diferente que não seja compatível com isso, levante um problema nessa ferramenta e crie um link para este comentário.

Estou encerrando este problema porque, conforme mencionado no parágrafo anterior, não mudaremos o requisito de que o Electron em produção requer acesso a uma sandbox em funcionamento, a menos que seja explicitamente instruído de outra forma. No entanto, para facilitar o desenvolvimento, abri o # 19550 para rastrear a opção de degradar automaticamente para o modo sem sandbox quando o Electron é instalado por meio de npm install , em vez de por meio de um pacote distribuído.

@ p3x-robot você pode encontrar um exemplo mínimo para a solução alternativa 2. mencionado por @nornagon aqui, que é inspirado por @vladimiry

@gcascio mas posso remover o hack instantâneo, certo? como o snap é calculado no criador de elétrons, você pode confirmar?

@gcascio funciona, muito obrigado! funciona!

@gcascio no workie, ele gera 2 ícones, então eu reverti para o elétron v4.2.8 ... :(

@ p3x-robot obrigado pelo feedback. Caso você esteja interessado, criei um problema e irei invadir assim que tiver tempo.

@nornagon, então não podemos nem mesmo rodar Electron 6 no Debian e não vamos dar a um processo chrome perms de root. As soluções alternativas fornecidas não são suficientes da perspectiva do usuário.

Existem duas soluções alternativas:
Habilite o acesso sem privilégios a CLONE_NEWUSER em seu kernel. Alguns kernels suportam mudar isso com sysctl kernel.unprivileged_userns_clone = 1.

Não há absolutamente nenhuma maneira de bagunçar o computador do cliente.

Desative totalmente o sandbox iniciando com --no-sandbox. Adicionar este argumento de JS infelizmente é insuficiente, já que o processo de GPU é iniciado antes que o processo principal JS seja executado.

Que tal adicionar um sinalizador --sandbox e desligar o recurso sandbox por padrão? Isso tem a vantagem de não enganar 99% das pessoas que usam o Electron.

As soluções alternativas fornecidas não são suficientes da perspectiva do usuário.

Usar um script / programa semelhante a um carregador que adicionará --no-sandbox arg também pode ser considerado uma solução alternativa, portanto, nenhuma ação do usuário final é necessária. Além disso, esse carregador poderia testar o suporte user namespace primeiro e adicionar --no-sandbox apenas se necessário.

@pronebird fornecer root setuid binário para chrome-sandbox é muito menos perigoso do que executar Electron sem sandbox. Considere: _você é_ quem está enviando os binários do Electron, para ter certeza de que está enviando um código confiável (por exemplo, assinando-o). No entanto, se seu aplicativo puder ser convencido a carregar um código não confiável (possivelmente intencionalmente, por exemplo, navegando para um URL na web), o aplicativo executará alegremente esse código com a permissão do usuário, sem qualquer tipo de sandbox. Eu ficaria muito mais preocupado com a defesa contra ataques focados na execução de JS não confiável em um processo sem sandbox em seu aplicativo do que com ataques envolvendo a exploração de um bug no mesmo sistema de sandbox que o Chrome usa. (E eu espero que o último seja corrigido _muito rapidamente_ se eles forem descobertos.) Se você quiser auditar o código do binário chrome-sandbox , pode começar aqui: https: //chromium.googlesource. com / chromium / src / + / refs / heads / master / sandbox / linux / suid / sandbox.c # 424

Se você está empenhado em executar sem um sandbox do Electron, recomendo enfaticamente o sandbox de alguma outra forma, por exemplo, snapcraft ou flatpak, empacotadores para os quais acredito incluir scripts de iniciador que desabilitam o sandbox do Electron dentro do contêiner.

@nornagon

fornecer root setuid binário para chrome-sandbox é muito menos perigoso do que executar o Electron sem sandbox. Considere: você é quem está enviando os binários do Electron, então pode ter certeza de que está enviando um código confiável (por exemplo, assinando-o). No entanto, se seu aplicativo puder ser convencido a carregar um código não confiável (possivelmente intencionalmente, por exemplo, navegando para um URL na web), o aplicativo executará alegremente esse código com a permissão do usuário, sem qualquer tipo de sandbox. Eu ficaria muito mais preocupado com a defesa contra ataques focados na execução de JS não confiável em um processo sem sandbox em seu aplicativo do que com ataques envolvendo a exploração de um bug no mesmo sistema de sandbox que o Chrome usa. (E eu espero que o último seja corrigido muito rapidamente se forem descobertos.)

Claro, mas executar uma sandbox não faz muito sentido se você tiver um aplicativo que nunca carrega conteúdo remoto. Eu acredito que deve ser o caso do Electron - para construir aplicativos de desktop usando pilha da web, carregar talvez JSON da web, mas não apenas mostrar páginas da web como se não tivéssemos o Safari para isso. Já passamos dos tempos em que as pessoas costumavam envolver os sites na lacuna do telefone, não é?

Eu acho que a sobrecarga é demais. Eu adicionei um script de bootstrap hoje em nosso aplicativo e removi o binário chrome-sandbox da distribuição, que tinha outros 5 megas. Infelizmente electron-builder não suporta nada disso, então tivemos que adicionar um gancho e fazer isso nós mesmos.

Se você deseja auditar o código do binário chrome-sandbox, pode começar aqui: https://chromium.googlesource.com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox. c # 424

Obrigado. Realmente depende de um modelo de ameaça, e não há como executar qualquer coisa do Google com permissões de root.

Pode ser totalmente seguro, mas também seria muito difícil verificar se todas as fontes estão intactas, uma vez que os conjuntos de elétrons são enviados via npm. Teríamos que configurar um servidor de compilação personalizado para Electron e auditar as fontes nós mesmos. Seria um esforço tremendo e prefiro evitá-lo.

@pronebird Não vou me envolver muito na discussão da sandbox, mas minha posição aqui é que devemos ter a sandbox habilitada por padrão, como fazemos atualmente.

Pode ser totalmente seguro, mas também seria muito difícil verificar se todas as fontes estão intactas, uma vez que as compilações de elétrons são enviadas via npm

Isso é fundamentalmente incorreto, pois as compilações de elétrons não são enviadas via npm. O pacote electron no npm tem na verdade cerca de 2 arquivos e cerca de 40 linhas de JS. As compilações do Electron reais são entregues via S3 e têm somas de verificação também no S3, para que as pessoas possam validar se a compilação que estão baixando é na verdade o Electron enviado.

@MarshallOfSound

Isso é fundamentalmente incorreto, pois as compilações de elétrons não são enviadas via npm. O pacote de elétrons no npm é na verdade cerca de 2 arquivos e cerca de 40 linhas de JS. As compilações do Electron reais são entregues via S3 e têm somas de verificação também no S3, para que as pessoas possam validar se a compilação que estão baixando é na verdade o Electron enviado.

O que eu quis dizer é que as compilações são baixadas durante o estágio npm install . Não quis dizer que eles estão fisicamente hospedados no npm. Que seja, eles estão hospedados no S3. Prove que estou errado, mas aposto que as somas de verificação estão hospedadas no mesmo S3, o que diminui o grau de segurança desse sistema, é apenas uma perna. Mas esse não é o ponto. Imagine o cenário em que seus builds estão sendo adulterados e as somas de verificação atualizadas de acordo. Agora nós temos um problema. Isso é simplesmente um controle de riscos e danos da minha parte. Sem raiz = menores riscos de algo realmente ruim acontecer.

O binário do @pronebird chrome-sandbox definitivamente não deve ter 5 MB, isso é um bug. Inaugurado o número 20049 para corrigi-lo, obrigado por apontá-lo.

Você certamente pode escolher desativar o sandbox para seu caso de uso. É uma pena que a arquitetura do Chromium faça com que você tenha que passar --no-sandbox na linha de comando diretamente em vez de chamar app.commandLine.appendSwitch ; idealmente, desabilitar o sandbox seria possível sem a necessidade de um script de invólucro. Esperançosamente, com o # 20049 a preocupação de remover o binário será melhorada, uma vez que 200 KB extras é muito mais razoável de se viver do que 5 MB.

Existe uma opção para usar um binário do sistema? Tenho reservas sobre dar um bit de raiz suid para qualquer coisa em meu node_modules / pasta. Obrigado.

@gardner, você poderia passar --no-sandbox arg, que é uma solução alternativa fácil quando você está no modo de desenvolvimento.

O VSCode mudou recentemente para o Electron 6 e agora estamos recebendo relatórios de que o VSCode não inicia mais, a menos que a opção --no-sandbox seja fornecida. Qual é o caminho a seguir aqui? Refs: https://github.com/microsoft/vscode/issues/81056

O snap funciona imediatamente, para appimage, há um código escrito:
https://github.com/electron-userland/electron-builder/issues/3872#issuecomment -517875676

o resto eu não sei, eu só libero NPM, AppImage e SNAP ...

basicamente, você tem que empacotar novamente cada tipo de item para adicionar um argumento ( --no-sandbox ) ao script do iniciador.

não há solução no Electron 6, eu acho, ou você tem que escrevê-lo com base em seus pacotes ou esperar por uma correção ou fazer o downgrade ...

Para uma melhor experiência de desenvolvedor. Podemos configurar um comando como abaixo dentro da ferramenta CLI de elétrons.

sudo chown root pathToChromeSandboxDynamicallyGenearted && sudo chmod 4755 pathToChromeSandboxDynamicallyGenearted

Um comando como electron --ConfigSandbox.
O usuário estará ciente e a sandbox pode ser facilmente configurada.
E mesmo quando é a primeira vez. Podemos perguntar a eles se desejam realizar as ações. s ou n. E então tudo o que eles precisam fazer é inserir a senha. Dessa forma, isso será feito em um piscar de olhos. E isso levará a uma grande experiência do usuário e ganhará com o tempo. Porque você vai confiar no fornecedor ou na comunidade. E vá em frente. Em vez de pesquisar em toda a rede. E isso é ainda mais valioso para os mais iniciantes de nós. E é bom em todos os casos.

Este problema foi resolvido, mas ainda o estou enfrentando com o elétron 7.0.0. Existe um commit que resultou em uma correção?

Por que o problema foi encerrado? Parece não haver correção disponível, pois ainda persiste mesmo na v7.0.0

Porque é uma questão de empacotar seu aplicativo, mas não uma questão de Electron.

Ah, certo. Mas como faço para consertar isso? Existe alguma maneira de o usuário final não ter que fazer nenhum trabalho extra?

Existe alguma maneira de o usuário final não ter que fazer nenhum trabalho extra?

Sim, existe uma maneira, já foi discutida antes.

sudo sysctl kernel.unprivileged_userns_clone = 1

Há um problema com os usuários do WSL (há muitos que usam o WSL) e o WSL 1 não usa um kernel Linux real ... teríamos que esperar pelo lançamento do WSL2.

Para referência sobre esta limitação: https://askubuntu.com/questions/1145525/how-to-create-proc-sys-kernel-unprivileged-userns-clone-file

CONFIG_USER_NS = y ativa o recurso de namespaces de usuário, mas eles ainda estão restritos a usuários privilegiados por padrão. Isso sugere sysctl kernel.unprivileged_userns_clone = 1

Confirmo que a execução de sudo sysctl kernel.unprivileged_userns_clone=1 é outra solução alternativa, comentário relacionado.

Sim eu uso manjaro e i3wm, peguei o mesmo erro mas com isso está funcionando.

Estou perdendo alguma coisa ou não é mais possível simplesmente baixar e executar um aplicativo Electron sem acesso root? Desculpe, eu não sabia que isso era específico do Debian e que o kernel principal nem mesmo suporta a desabilitação de namespaces sem privilégios.

Perdoe minha ousadia, mas isso é absolutamente insano. Electron expõe a API Node.js mesmo em processos de renderização. Usar / habilitar o sandbox do Chromium em um aplicativo Electron é completamente inútil e, como todos podem ver nos relatórios de bug no GitHub apontando para esse problema, também é altamente contraproducente. Desative-o se possível.

Electron expõe a API Node.js mesmo em processos de renderização.

nodeIntegration está desabilitada por padrão desde a v5.

Desculpe, eu não sabia que isso era específico do Debian e que o kernel principal nem mesmo suporta a desabilitação de namespaces sem privilégios.

Então, rodando o debian, pareço ter sorte de ter acesso root em minha máquina. Mas estou correto de que esse recurso, como está, impedirá que os usuários executem aplicativos eletrônicos (como AppImage ou não) sem

a) tendo sudo , ou
b) ser capaz de convencer alguém que tem sudo a habilitar namespaces sem privilégios?

@ black-puppydog bem, se eles estão construindo o aplicativo a partir da fonte, eles podem editar o script de início para passar o argumento --no-sandbox para o elétron. Deve ser possível modificar um AppImage com o mesmo efeito (descompactando e reembalando), mas eu não tentei fazer isso sozinho. Também não é impossível que alguns criadores de AppImage incluam esse sinalizador em suas compilações, caso em que essas imagens específicas simplesmente funcionarão.

Caso contrário, acho que você está correto. Observe que o kernel da linha principal sempre tem namespaces sem privilégios habilitados e não oferece nenhuma maneira de desabilitá-los. Portanto, por que isso é apenas um problema no Debian.

@ black-puppydog Pelo que me lembro, o instalador pede uma senha de root quando você instala o Debian pela primeira vez em sua máquina. Mas sim, no Debian (ou qualquer outro sistema que usa o patch do kernel do Debian), você precisa ter acesso root (via sudo ou outro) ou executar aplicativos Electron com --no-sandbox .

@ndorf No Linux principal, os namespaces do usuário podem ser desabilitados ao não compilar no recurso, mas não podem ser habilitados / desabilitados em tempo de execução ou restritos apenas a processos privilegiados. O Debian corrige seus kernels de forma que os namespaces do usuário sejam restritos a processos privilegiados por padrão, mas podem ser habilitados para todos os processos com uma configuração em /proc/sys .

A razão pela qual o Debian o restringe é que os namespaces de usuários sem privilégios são um sério risco de segurança com um longo histórico de vulnerabilidades. Os namespaces de usuário sem privilégios permitem o acesso de processos sem privilégios a muitas funcionalidades do kernel (UID 0, recursos, montar um sistema de arquivos, criar um inode de dispositivo, etc.) que estava restrito a processos privilegiados apenas por um longo tempo. Qualquer código do kernel baseado na suposição de que processos sem privilégios nunca serão capazes de fazer essas coisas está vulnerável agora que os processos sem privilégios repentinamente são capazes de fazer essas coisas.

Existe uma solução possível enquanto isso, até que cada distribuição Linux habilite esses recursos?

Veja a mensagem original:

Se eu chown e chmod o arquivo, ele funciona bem

Veja também aqui # 16631 (comentário) Portanto, para fazer suid sandbox funcionar, você basicamente tem que ajustar o binário chrome-sandbox desta forma:

* `sudo chown root chrome-sandbox`

* `chmod 4755 chrome-sandbox`

O problema é mais grave, embora, ao executar pacotes appimage / snap, eu ainda não tenha revelado uma solução alternativa decente para esses casos. Ele está funcionando se o appimage for executado com --no-sandbox arguemnt, mas isso é um hack.

Isso funciona se eu estiver executando o aplicativo a partir do diretório descompactado. Como faço para empacotar este diretório depois de alterar as permissões de chrome-sandbox ?

@ shrinidhi111 4755 pode ser preservado quando empacotado, pelo menos no caso de pacotes pacman / deb. Os pacotes também podem ser ajustados no nível de dist específico, por exemplo . Quanto ao proprietário do root, normalmente quando o pacote é instalado a partir do repo no Linux, os arquivos relacionados obtêm o proprietário do root. No caso da compilação de AppImage, eu o reembalei e codifiquei --no-sandbox arg no script AppRun interno, pois o construtor de elétrons ainda não faz isso fora da caixa. O pacote Snap é formado pelo construtor de elétrons com --no-sandbox arg codificado (correção relacionada adicionada há cerca de 6 meses).

@ shrinidhi111 4755 pode ser preservado quando empacotado, pelo menos no caso de pacotes pacman / dev. Os pacotes também podem ser ajustados no nível de dist específico, por exemplo . Quanto ao proprietário do root, normalmente quando o pacote é instalado a partir do repo no Linux, os arquivos relacionados obtêm o proprietário do root. No caso da compilação de AppImage, eu o reembalei e codifiquei --no-sandbox arg no script AppRun interno, pois o construtor de elétrons ainda não faz isso fora da caixa. O pacote Snap é formado pelo construtor de elétrons com --no-sandbox arg codificado (correção relacionada adicionada há cerca de 6 meses).

Criar um arquivo instantâneo foi uma ideia excelente e me poupou muito trabalho. Obrigado novamente!

como isso ainda não está resolvido

no snap foi corrigido, eu tenho meu próprio build que funciona com o appimage. pois o resto não está resolvido.

Este tópico é incrivelmente longo e o erro ainda é encontrado. Existe um resumo da situação em algum lugar? Talvez esse resumo possa ser vinculado ao erro.

Parece que https://github.com/electron/electron/issues/17972#issuecomment -495767027 e similares estão propondo que é suficiente ter o elétron funcionando de forma fácil e segura apenas em sistemas com acesso root. Talvez fosse bom se o sistema detectasse as configurações de permissões incorretas e oferecesse avisos aos desenvolvedores, para reduzir os usuários que se deparam com esse problema, mas talvez esse seja um problema separado. Parece também que seria bom se houvesse um caminho para usuários sem acesso root para usar o elétron facilmente, com a compreensão proeminente de que recursos não confiáveis ​​são mais perigosos do que o normal.

caminho para usuários sem acesso root para usar o elétron facilmente

--no-sandbox argumento CLI.

Vladimiry, eu estava pensando, por exemplo, em usuários finais sem muita experiência em terminais ou executando aplicativos que envolvem o elétron

Eu estava pensando, por exemplo, em usuários finais sem muita experiência em terminais ou em execução de aplicativos que envolvem o elétron

Incorpore esse --no-sandbox ao atalho do aplicativo. Qualquer pacote Linux aqui funcionará bem independentemente do kernel.unprivileged_userns_clone do sistema

Isso é verdade se eu for um desenvolvedor e fizer um aviso adequado para meus usuários finais. Muitos desenvolvedores nunca aprenderão sobre esse problema devido ao ambiente de simulação do namespace que funciona para eles? Também é preocupante que as soluções existentes sejam implementadas sem comunicar às pessoas envolvidas que recursos não confiáveis ​​são mais perigosos.

Esta solução só funciona quando você recebe esse erro por causa do WSL

Encontrei esse problema ao tentar usar electron no WSL (WSL2 no meu caso).
Mesmo usando um servidor X11, o electron não foi capaz de rodar no X11.

Tive que construir o electron para o Windows, mesmo que o executasse dentro do WSL. Depois disso, tudo funciona como exceto
A maneira mais simples de fazer isso:

• Desinstale o elétron npm uninstall electron
• Alterar plataforma de configuração de npm export npm_config_platform=win32
• Instale o elétron npm install electron
• Remova a variável de ambiente unset npm_config_platform

Isso sugere sysctl kernel.unprivileged_userns_clone=1

Eu vejo esse problema com WSL (Windows 10), Ubuntu 18.04 instalado em WSL.
sudo sysctl kernel.unprivileged_userns_clone=1 não funciona.

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

Usar chown e chmod também não é uma opção.

@MarshallOfSound zip não oferece suporte a permissões, mas, em última análise, o problema não é a permissão chmod, mas sim o proprietário. O auxiliar de sandbox setuid é suid _to root_, porque ele precisa executar funções que estão disponíveis apenas para root. Se fosse possível definir as permissões apropriadas sem primeiro obter privilégios de root, isso seria uma vulnerabilidade muito séria no Linux. Felizmente para o Linux, e infelizmente para nós, esse não é o caso.

zip _does_ oferece suporte a permissões em sistemas baseados em unix (ou pelo menos nas variantes do Linux que testei). Veja https://serverfault.com/a/585889/17620

Os bits de permissão são armazenados no sufixo do cabeçalho do arquivo do diretório central do zip. O campo externalFileAttributes do sufixo pode ser usado para armazenar os bits de permissão para cada entrada de arquivo / diretório.

cc @MarshallOfSound

Eu tenho o mesmo 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]$ 

executado como usuário normal, tem erro: FATAL:setuid_sandbox_host.cc(157)] 。run como root, tem erro: FATAL:electron_main_delegate.cc(211)]

mas quando eu instalo o snap depois, execute como root ou o usuário normal está ok。

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

Isso funciona bem.

@cuixiping funciona: +1:

Eu fiz

$ 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

Tive o mesmo problema quando executei o electron no Deepin e resolvi o problema com este código
electron . --no-sandbox

espero que isso te ajude

não funciona

@fabiospampinato sua adaptação desabilita o sandbox para todos os tipos de pacotes Linux, mas pelo menos os pacotes DEB e Pacman funcionam bem com o sandbox SUID (provavelmente todos os pacotes não semelhantes a contêineres), há apenas a necessidade de definir o bit de permissão SUID para chrome-sandbox binário. Mas não defina o bit de permissão SUID para o pacote Snap, pois o Snap Store rejeita esses tipos de pacotes. Portanto, eu defino o bit SUID para todos os pacotes Linux que esperam pacotes Snap / AppImage que têm sandboxing desabilitado, código relacionado .

Oi @vladimiry
Não consegui acessar o link que você anexou aqui. Você pode me ajudar com isso?
Além disso, você conseguiu descobrir como fazer --no-sandbox no script after-pack do construtor de elétrons?

Obrigado

@ tushar-compro, aqui está https://github.com/vladimiry/ElectronMail/tree/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack. Basicamente, eu defino 4755 bits no script after-pack para alguns tipos de pacote e ainda reempacotando os pacotes appimage + snap. Na verdade, o construtor de elétrons já incorporou --no-sandbox arg no snap, mas ainda não em appimage https://github.com/electron-userland/electron-builder/pull/4496. Compre o caminho, atualmente o construtor de elétrons já define 4755 bits https://github.com/electron-userland/electron-builder/blob/fc85a42a26df863b5bade4b769182b299ff24e0a/packages/app-builder-lib/templates/linux/after-install.tpl # L7. Portanto, a versão recente do criador de elétrons deve simplificar as coisas para a maioria dos desenvolvedores.

@vladimiry
Estou certo em entender que você definiu o bit 4755 para alvos que NÃO sejam de imagem e snap.
https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack/index.ts#L17

Mas o problema está ocorrendo durante o uso do instalador .appimage na distribuição debian.

Estou faltando alguma coisa aqui?

Mas o problema está ocorrendo durante o uso do instalador .appimage na distribuição debian.

Como eu disse, o appimage ainda requer um tratamento especial. Reembalo-o e incorporo --no-sandbox no script ./AppRun . Localize a palavra-chave DISABLE_SANDBOX_ARGS_LINE aqui https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

Mas o problema está ocorrendo durante o uso do instalador .appimage na distribuição debian.

Como eu disse, o appimage ainda requer um tratamento especial. Reembalo-o e incorporo --no-sandbox no script ./AppRun . Localize a palavra-chave DISABLE_SANDBOX_ARGS_LINE aqui https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

o último criador de elétrons cuida do argumento no sanbox automaticamente tanto no snap quanto no appimage.

@vladimiry
Então, estou certo em entender que a configuração de 4755 bits que você fez é para instaladores diferentes de appimage e snap. E para appimage você configurou o não-sandbox. Você pode, por favor, confirmar.

@ p3x-robot
sim. você está parcialmente certo.

1. O criador de elétrons mais recente não define sandbox para snap, mas NÃO para appimage. No entanto, eles definiram 4755 bits para appimage.
2. No meu projeto estou usando electron-version 20.xx atualizá-lo para 22.xx será um esforço por si só. Apenas tentando evitar isso, se possível. Atualizar para a v22 será o último recurso.

o último criador de elétrons cuida do argumento no sanbox automaticamente tanto no snap quanto no appimage.

Ainda não foi possível localizar em seu código o snippet específico do appimage semelhante a este aplicado para snaps (https://github.com/electron-userland/electron-builder/pull/4496 ainda aberto). De qualquer forma, no meu caso, a reembalagem ainda é necessária, uma vez que coloquei outros argumentos, além dos relacionados ao sanbox.

Então, estou certo em entender que a configuração de 4755 bits que você fez é para instaladores diferentes de appimage e snap. E para appimage você configurou o não-sandbox. Você pode, por favor, confirmar.

Correto. Mas o construtor de elétrons moderno define 4755 internamente. Eu verifico, porém, que não está definido para snap / appimage, pois isso seria um erro. Por exemplo, o snap não começará com 4755 bits definidos como binário de elétrons, se bem me lembro das coisas.

@vladimiry
Eu só preciso definir o no-sandbox, pois minhas appimages não estão funcionando no debian.

Acredito que não precisarei de reembalagem neste caso. Mas não consegui encontrar a documentação correta do construtor de elétrons para fazer isso. Ou você acha que também vou precisar reembalar?

Você pode me indicar a documentação certa que pode me ajudar em como fazer isso.

Além disso, eu entendo que tenho ambas as opções de configuração de 4755 bits ou de configuração no-sandbox.
Qual você acha melhor?

Além disso, eu entendo que tenho ambas as opções de configuração de 4755 bits ou de configuração no-sandbox.

Se bem me lembro das coisas, as configurações 4755 para appimage não resolverão o problema. Você precisa (um de):

• inicie seu arquivo appimage com --no-sandbox arg linha de comando
• tenha --no-sandbox embutido no script ./AppRun localizado em seu arquivo appimage (portanto, é necessário reempacotamento).

Você pode me indicar a documentação certa que pode me ajudar em como fazer isso.

Duvido que você encontre informações detalhadas sobre o problema em qualquer documentação. Não tenho conhecimento de nenhum documento relevante.

Além disso, eu entendo que tenho ambas as opções de configuração de 4755 bits ou de configuração no-sandbox.

Se bem me lembro das coisas, as configurações 4755 para appimage não resolverão o problema. Você precisa (um de):

• inicie-o com --no-sandbox arg linha de comando
• tenha --no-sandbox incorporado no script ./AppRun localizado em seu arquivo appiamge (portanto, é necessário reempacotamento).

Você pode me indicar a documentação certa que pode me ajudar em como fazer isso.

Duvido que você encontre informações detalhadas sobre o problema em qualquer documentação. Não tenho conhecimento de nenhum documento relevante.

o construtor de elétrons mais recente incorpora --no-sandbox no ./AppRun , eu costumava reempacotar, mas agora é inútil, eu apenas uso o construtor de elétrons nativo.

@vladimiry
sim. definir 4755 sozinho não funcionará. Com 4755, precisamos alterar o proprietário do chrome-sandbox para root.
De qualquer forma, muito obrigado pela ajuda. Vou tentar consultar seu código e definir o no-sandbox então.

@ p3x-robot
Você pode compartilhar algum link (repositório de construtor de elétrons) onde podemos ver o código fazendo isso.

https://github.com/patrikx3/onenote

@vladimiry
sim. definir 4755 sozinho não funcionará. Com 4755, precisamos alterar o proprietário do chrome-sandbox para root.
De qualquer forma, muito obrigado pela ajuda. Vou tentar consultar seu código e definir o no-sandbox então.

@ p3x-robot
Você pode compartilhar algum link (repositório de construtor de elétrons) onde podemos ver o código fazendo isso.

https://github.com/patrikx3/onenote

o construtor de elétrons mais recente incorpora o --no-sandbox no ./AppRun, eu costumava reempacotar, mas agora é inútil, eu apenas uso o construtor de elétrons nativo.

Acabei de testá-lo usando a versão recente do construtor de elétrons e ele não incorpora o --no-sandbox no script ./AppRun sh. Se você iniciar o appimage, ele falhará com um erro conhecido [759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found . Talvez você tenha o sinalizador kernel.unprivileged_userns_clone habilitado em seu sistema. Se for assim, tente desabilitá-lo como sudo sysctl kernel.unprivileged_userns_clone=0 e iniciar o arquivo appimage novamente.

o construtor de elétrons mais recente incorpora o --no-sandbox no ./AppRun, eu costumava reempacotar, mas agora é inútil, eu apenas uso o construtor de elétrons nativo.

Acabei de testá-lo usando a versão recente do construtor de elétrons e ele não incorpora o --no-sandbox no script ./AppRun sh. Se você iniciar o appimage, ele falhará com um erro conhecido [759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found . Talvez você tenha o sinalizador kernel.unprivileged_userns_clone habilitado em seu sistema. Se for assim, tente desabilitá-lo como sudo sysctl kernel.unprivileged_userns_clone=0 e iniciar o arquivo appimage novamente.

estranho, há 10 mil instalações instantâneas com o criador de elétrons mais recente. e definitivamente o criador de elétrons mostra que adiciona essa bandeira ...

há 10k snap

Estamos falando sobre appimage, não sobre instantâneos. O Snap, é claro, tem o argumento incorporado conforme mencionei acima, aqui https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197 -L202.

há 10k snap

Estamos falando sobre appimage, não sobre instantâneos. O Snap, é claro, tem o argumento incorporado conforme mencionei acima, aqui https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197 -L202.

você está certo. Eu estava pensando por algum motivo que era feito no appimage, eu até removi o código para reempacotar e adicionar no-sandbox, mas eu tentei novamente e vejo que está faltando, então eu adicionei minha reversão da minha construção, não funciona. desculpe, no meu corifeus-builder, você pode ver o que estou fazendo: https://github.com/patrikx3/corifeus-builder/blob/master/src/utils/appimage/after-all-artifact-build.js

Olá @nornagon, considerando o quão comum é esse problema, o tutorial de início rápido oficial do elétron pode ser atualizado para incluir a solução alternativa para que os iniciantes tenham uma experiência positiva?

Edit: Graças ao incentivo da comunidade, abri um FR # 26478

@gabefair Parece uma proposta razoável. Você estaria interessado em abrir um PR?