Electron: Le binaire d'aide du bac à sable SUID a été trouvé, mais n'est pas configuré correctement

Malheureusement, il n'y a aucun moyen de configurer cela correctement automatiquement, car la définition des autorisations appropriées nécessite des privilèges root et nous ne voulons pas demander de mot de passe root pendant npm install .

Idéalement, Arch configurerait son support du noyau sans privilège CLONE_NEWUSER et Chromium (et Electron) pourrait utiliser le bac à sable de l'espace de noms au lieu de s'appuyer sur l'ancien bac à sable setuid. Les applications distribuées sur Linux devront l'intégrer dans leur processus d'installation. Voir https://github.com/electron-userland/electron-installer-debian/pull/184 et https://github.com/electron-userland/electron-installer-redhat/pull/112 par exemple.

Pendant le développement, nous devrions probablement imprimer quelque chose sur npm install avec des instructions si nous détectons que le bac à sable de l'espace de noms n'est pas disponible.

Hé, merci pour la réponse super rapide!

Est-ce que CLONE_NEWUSER non privilégié vient de CONFIG_USER_NS=y ? Si c'est le cas, cela devrait être la configuration actuelle.

S'il vous plaît laissez-moi savoir si je peux faire quelque chose pour aider, ou si cela est attendu sur Arch, je suis heureux de fermer - je comprends qu'il faut s'attendre à des problèmes lors de l'exécution de distributions à la pointe de la technologie et cela ne me dérange pas résoudre ce problème dans un PKGBUILD plutôt que de s'attendre à ce que cela fonctionne parfaitement directement à partir de npm. Acclamations!

CONFIG_USER_NS=y active la fonctionnalité d'espaces de noms d'utilisateurs, mais ils sont toujours limités aux utilisateurs privilégiés par défaut. Cela suggère sysctl kernel.unprivileged_userns_clone=1

Existe-t-il une solution de contournement possible jusqu'à ce que chaque distribution Linux active ces fonctionnalités ?

@kitingChris Le bac à sable setuid EST la solution de contournement. Il vous suffit de vous assurer que lors du développement / de la publication d'une application électronique, vos scripts de développement / d'emballage définissent correctement les autorisations de l'assistant sandbox en tant que @nornagon lié ci-dessus.

Existe-t-il une solution de contournement possible jusqu'à ce que chaque distribution Linux active ces fonctionnalités ?

Voir le message d'origine :

Si je chown et chmod le fichier, cela fonctionne bien

Voir aussi ici https://github.com/electron/electron/issues/16631#issuecomment -476082063 Donc, pour faire fonctionner suid sandbox, vous devez essentiellement modifier le binaire chrome-sandbox cette façon :

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

Le problème est plus grave, mais si vous exécutez des packages appimage/snap, je n'ai pas encore révélé de solution de contournement décente pour ces cas. Cela fonctionne si appimage est exécuté avec --no-sandbox arguments, mais c'est un hack.

@nornagon

car la définition des autorisations appropriées nécessite des privilèges root et nous ne voulons pas demander de mot de passe root lors de l'installation de npm.

L'exécution de chmod 4755 node_modules/electron/dist/chrome-sandbox ne nécessite pas d'autorisation root et cela devrait être suffisant pour exécuter une telle commande pour envelopper l'application dans les packages deb/pacman/etc, comme lorsque ces packages sont installés tous les fichiers, y compris chrome-sandbox normalement détenu par root. Ce serait donc formidable que l'électron fasse chmod 4755 node_modules/electron/dist/chrome-sandbox automatiquement pendant le processus d'installation, car il ne serait alors pas nécessaire de gérer ce cas manuellement comme mentionné ici .

CONFIG_USER_NS=y active la fonctionnalité des espaces de noms d'utilisateurs, mais ils sont toujours limités aux utilisateurs privilégiés par défaut. Cela suggère sysctl kernel.unprivileged_userns_clone=1

Je confirme que l'exécution de sudo sysctl kernel.unprivileged_userns_clone=1 est une autre solution de contournement, commentaire connexe .

@vladimiry Je devais d'abord chown puis chmod. Dans l'autre sens, cela n'a pas fonctionné.

@burningTyger vous avez raison , je viens de modifier le message d'origine.

@nornagon Si nous chmod 4755 out/Release/chrome-sandbox sur CI, cette autorisation sera-t-elle conservée une fois que nous l'aurons zip ou devons-nous apporter cette modification dans electron-download pour corriger l'autorisation sur DL ?

idem voici une mauvaise nouvelle fonction pour ce qu'il faut changer ça... :(

@MarshallOfSound zip ne prend pas en charge les autorisations, mais en fin de compte, le problème n'est pas l'autorisation chmod, mais plutôt le propriétaire. L'assistant sandbox setuid est suid _to root_, car il doit exécuter des fonctions qui ne sont disponibles que pour root. S'il était possible de définir les autorisations appropriées sans d'abord obtenir les privilèges root, ce serait une vulnérabilité très grave dans Linux. Heureusement pour Linux, et malheureusement pour nous, ce n'est pas le cas.

Voici les options telles que je les vois :

1. Ne changez rien dans Electron. Recommandez aux développeurs d'activer les CLONE_USERNS non privilégiés sur leur noyau pour permettre au bac à sable de l'espace de noms de s'exécuter à la place du bac à sable setuid.
2. Démarrez sans sandbox si aucune méthode de sandbox n'est disponible _uniquement lors du démarrage d'une application non emballée_. Si Electron démarre une application packagée, refusez de démarrer sans sandbox.
3. Dans tous les cas, si aucune méthode de sandbox n'est disponible, démarrez sans sandbox et imprimez un avertissement.
4. Désactivez le sandboxing par défaut sur Linux.

Je penche pour (2). Cela faciliterait le développement sans compromettre la sécurité de l'application déployée.

Je ne sais pas encore quoi faire à propos de snap/flatpak, car je ne connais pas leur fonctionnement. Il est possible qu'ils sandboxent déjà suffisamment l'application pour que nous puissions désactiver complètement le sandboxing dans cette situation, comme nous le faisons lors de la création de la version Mac App Store d'Electron.

Pour l'instant, j'aime plus la première option.

1. Démarrez sans bac à sable si aucune méthode de bac à sable n'est disponible uniquement lors du démarrage d'une application non compressée. Si Electron démarre une application packagée, refusez de démarrer sans sandbox.

Un tel scénario serait en quelque sorte trompeur. On peut exécuter avec succès une application non emballée sans sandboxing, mais il est possible que l'application emballée ne fonctionne pas de la même manière avec le sandboxing activé. Comme, par exemple, le cas où vous accédez au processus principal à partir du processus de rendu et non via l'interface remote . Ou le cas de l'encapsulation de l'application dans des packages AppImage / Snap / Flatpak.

1. Dans tous les cas, si aucune méthode de sandbox n'est disponible, démarrez sans sandbox et imprimez un avertissement.

Ainsi, une application packagée conçue et développée en mode bac à sable peut être exécutée sans bac à sable si aucun bac à sable n'est disponible. Cela ne me semble pas bien.

1. Désactivez le sandboxing par défaut sur Linux.

Qu'est-ce que cela signifie exactement? Quel serait le moyen d'activer le sandboxing sur Linux de la manière dont l'application démarre ou échoue si aucun sandboxing n'est disponible (la situation actuelle, sandboxing forcé).

J'aime aussi (1), mais pour défendre un peu (2), l'API exposée à l'application ne changerait pas lors de la désactivation du bac à sable. La seule chose que nous désactiverions est le bac à sable au niveau du système d'exploitation. Nous chargerions toujours l'application de la même manière, elle ne serait tout simplement pas protégée par le système d'exploitation.

Nous chargerions toujours l'application de la même manière, elle ne serait tout simplement pas protégée par le système d'exploitation.

Ensuite, ça me semble bien aussi. Merci pour l'explication.

Je n'aime pas le 2., car la sécurité optionnelle amène généralement les gens à désactiver la sécurité.

En entrant dans la peau des "utilisateurs stupides", je préférerais voir Electron fonctionner par défaut. S'il s'agit d'une mesure de sécurité très importante, donnez-moi un avertissement et une bonne explication des raisons pour lesquelles je dois faire un travail supplémentaire. Si ce n'est pas si important, alors ne me donne pas le mauvais goût de "ça ne marche pas".

Pour cette raison, j'aime le 1. (avec forcer à quitter, comme maintenant) ou le 4.

:x: chown root:root chrome-sandbox && chmod 4755 chrome-sandbox soulève quelques drapeaux rouges pour moi.

Juste pour être très clair sur ce qu'il fait : il définit le bit SUID sur chrome-sandbox , ce qui permet à _tout utilisateur_ d'exécuter le fichier _en tant que root_. Cela signifie que s'il existe un moyen d'utiliser chrome-sandbox malveillante, ou si le contenu devient malveillant, n'importe quel utilisateur peut devenir root. chrome-sandbox serait une cible très intéressante pour l'attaque.

Je déconseille fortement de faire cette solution de contournement sur npm install , car cela nécessiterait sudo (l'utilisateur doit écrire un mot de passe), c'est invasif et nous pourrions ne pas comprendre les conséquences pour la sécurité de le faire.

chown root:root chrome-sandbox && chmod 4755 chrome-sandbox lève quelques drapeaux rouges pour moi.

Bien sûr, il le fait. Mais vous pouvez activer le sandboxing User Namespace comme alternative sudo sysctl kernel.unprivileged_userns_clone=1 (activé par défaut sur Ubuntu mais pas sur Arch).

Juste pour être très clair sur ce qu'il fait : il définit le bit SUID sur chrome-sandbox , ce qui permet à _tout utilisateur_ d'exécuter le fichier _en tant que root_. Cela signifie que s'il existe un moyen d'utiliser chrome-sandbox malveillante, ou si le contenu devient malveillant, n'importe quel utilisateur peut devenir root. chrome-sandbox serait une cible très intéressante pour l'attaque.

Oui, mais aussi ce binaire est exactement le même que celui fourni avec Chrome, donc si cela vous inquiète, vous devriez probablement aussi désinstaller Chrome :)

Existe-t-il un moyen de s'exécuter sans le bac à sable / exécuter sans "l'assistant du bac à sable" ? Les premiers utilisateurs se plaignent 😅
Je m'attendais à ce que The SUID sandbox helper binary was found, but is not configured correctly .
Je détesterais revenir à l'électron 4.x 🤨

Message d'erreur

Snapcraft Review & Suid

J'ai essayé de télécharger un snap avec le drapeau suid sur chrome-sandbox mais le processus de révision de Snapcraft interdit l'utilisation des drapeaux 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 pour désactiver le sandboxing au niveau du système d'exploitation --no-sandbox doit être passé en tant qu'argument d'application, c'est- app.commandLine.appendSwitch dire que ici . Je ne sais pas si cela vous aidera car je ne l'ai pas encore essayé, ce serait formidable si vous le faisiez. Pour l'instant, je préfère sortir l'application que j'ai construite en mode mixte : smile:. Electron v5 est utilisé pour tous les packages, à l'exception de AppImage et Snap, car il n'est pas encore tout à fait clair comment faire en sorte que ces packages fonctionnent correctement avec le sandboxing activé, mais cela deviendra clair à un moment donné.

Si Snapcraft interdit les drapeaux suid, la seule option est probablement de désactiver entièrement le sandboxing d'Electron dans Snapcraft et de s'appuyer sur le conteneur utilisé par Snapcraft. Je ne sais pas quelle est la meilleure façon de le faire : est-il possible de spécifier des indicateurs de ligne de commande supplémentaires lors de l'empaquetage via Snapcraft ? Si c'est le cas, nous pourrions ajouter le drapeau --no-sandbox . Sinon, nous devrons peut-être ajouter un mécanisme de détection spécifique pour détecter l'exécution dans Snapcraft/Flatpak et désactiver le sandboxing en fonction de cette détection.

Certains documents liés à Snap https://docs.snapcraft.io/browser-support-interface

@posix4e pouvez-vous nous éclairer sur le problème de l'exécution du package Snap en bac à sable dans les modes Espace de noms utilisateur et bac à sable/de secours SUID ? On dirait que vous avez une expérience pertinente de la configuration instantanée du navigateur Brave. CC @flexiondotorg.

Juste pour être très clair sur ce qu'il fait : il définit le bit SUID sur chrome-sandbox , ce qui permet à _tout utilisateur_ d'exécuter le fichier _en tant que root_. Cela signifie que s'il existe un moyen d'utiliser chrome-sandbox malveillante, ou si le contenu devient malveillant, n'importe quel utilisateur peut devenir root. chrome-sandbox serait une cible très intéressante pour l'attaque.

Oui, mais aussi ce binaire est exactement le même que celui fourni avec Chrome, donc si cela vous inquiète, vous devriez probablement aussi désinstaller Chrome :)

Je suis en partie inquiet de laisser un binaire de Chrome avoir root:root avec un SUID défini, oui. Très peu de code est sans bugs. Voici le code source, pour mémoire : https://github.com/chromium/chromium/tree/master/sandbox/linux/suid

Mais je suis plus inquiet si npm install :

1. Téléchargez un tas de logiciels à la volée.
2. Créez automatiquement l'un des fichiers root:root et SUID.

Je pense que ce serait la première pile logicielle que je connaisse qui effectue automatiquement un sudo chown root:root && sudo chmod 4755 sur un fichier appartenant à un utilisateur non root.

Faire une installation de sudo chown root:root && sudo chmod 475 sur npm devrait être hors de question, npm devrait s'exécuter en tant que root pour définir les autorisations. Le modèle de hook de npm permettrait à tous les packages installés d'exécuter également leurs hooks en tant que root. Avec peut-être des centaines de packages et de dépendances imbriquées, ce serait très dangereux.

Faire un sudo chown root:root && sudo chmod 475 sur l'installation de npm devrait être hors de question

Ce n'est pas considéré comme une option pour autant que je sache.

Je suis d'accord que faire tout ce qui nécessiterait des privilèges root lors de l'installation de npm est un non-démarreur. C'est pourquoi je ne l'ai pas listé comme l' une des options .

Pour ce que ça vaut, electron-installer-debian 1.2.0, electron-installer-redhat 1.1.0 et electron-installer-snap 3.2.0 ont été publiés avec les modifications du bac à sable SUID. Les versions bêta d'Electron Forge v5 et v6 devraient également être mises à jour de manière transitoire (via les mises à jour de version dans la gamme, utilisez npm update ou yarn upgrade manière appropriée).

Il suffit de lier le code associé pour plus de clarté.

Juste pour être clair, pour Snaps, il y avait plus (à savoir, l'ajout de la prise en charge du sandbox du navigateur comme indiqué ci-dessus). Voir les modifications du PR associé pour plus de détails.

Je viens d'appuyer sur ceci, chown / chmod fonctionne, mais ce n'est pas la seule action nécessaire à prendre si vous exécutez dans une image Docker.

Si vous faites cela, vous recevrez une autre erreur :

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

La solution consiste à ajouter --privileged à la commande docker run . Je ne pense pas que ce soit une bonne solution, principalement sur CI.

@JCMais, il semble qu'Electron tente à tort d'utiliser le bac à sable de l'espace de noms dans docker, même s'il devrait essayer d'utiliser le bac à sable suid. Je ne sais pas pourquoi, mais vous pouvez forcer le bac à sable suid avec --disable-namespace-sandbox . Si vous lancez docker avec --privileged (ou --cap-add SYS_ADMIN , ou un profil seccomp personnalisé qui permet CLONE_NEWUSER), alors les espaces de noms seront disponibles à l'intérieur du bac à sable et il n'y a pas besoin du bac à sable setuid ou de son assistant exécutable .

Comme @thomasnordquist, j'ai fini par désactiver le sandboxing pour les packages Snap/AppImage à l'aide d'un script de préchargement. Vous créez un script sh de type préchargement nommé binaire d'origine qui est ensuite utilisé pour charger le binaire d'électrons renommé/original avec l'argument --no-sandbox . C'est pratique à faire dans le script after-pack du constructeur d'électrons

@nornagon, comment dois-je exactement passer ce drapeau à l'électron ? J'ai juste essayé d'ajouter --disable-namespace-sandbox mais cela continue de me donner une erreur :

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

Je peux confirmer que cela m'a détruit en un clin d'œil et que tous nos utilisateurs Linux sont bloqués sur une ancienne version jusqu'à ce que je puisse y remédier.

Je suis TOTALEMENT pour un moyen d'améliorer la sécurité, mais cela a été expédié sans indicateur de fonctionnalité pour le désactiver.

J'aimerais également faire valoir que cela n'aurait pas dû être expédié sans une fonctionnalité permettant de le désactiver via le code. Je suppose que c'était peut-être accidentel car --no-sandbox ne fonctionne pas à moins d'être manuellement donné à partir de la ligne de commande.

S'il y a un problème avec la façon dont electron-installer-snap a implémenté la prise en charge du bac à sable, veuillez me le faire savoir dans son outil de suivi des problèmes.

S'il y a un problème avec la façon dont electron-installer-snap a implémenté la prise en charge du bac à sable, veuillez me le faire savoir dans son outil de suivi des problèmes.

J'aimerais également entendre quelqu'un confirmer que le changement est suffisant pour résoudre le problème avec les packages Snap. Ainsi, les commentaires positifs/négatifs sont les bienvenus. Voir les informations associées.

@vladimiry Je suis allé de l'avant et j'ai testé cela et cela n'a pas fonctionné.

J'ai besoin d'une solution qui ne résout pas les correctifs du système d'exploitation, sysctl ou les redémarrages. J'ai besoin de quelque chose qui fonctionne maintenant. --no-sandbox serait préférable.

Ce serait beaucoup plus utile pour moi si quelqu'un pouvait fournir une application Electron minimale que je pourrais utiliser pour reproduire le Snap emballé qui ne fonctionne pas. J'ai utilisé un fork de electron-quick-start pour créer un Snap dans CircleCI et je l'ai installé sur mon ordinateur portable (Debian Stretch) pour vérifier que mes modifications ont au moins permis de créer une application Electron fonctionnelle.

"N'a pas fonctionné" ne m'aide pas à identifier ce que je peux faire dans electron-installer-snap pour qu'il soit correctement emballé pour les autres.

@burtonator , merci d'avoir testé le truc. Pour autant que je sache, le script bash/sh de type chargeur de build Snap/AppImage qui démarre le binaire/électron d'origine avec l'argument --no-sandbox cmd est la seule solution de contournement vérifiée pour le moment.

@malept avant de tester le sudo sysctl kernel.unprivileged_userns_clone=0 .

@vladimiry oui, mon ordinateur portable a déjà ce paramètre utilisateur.

Si quelqu'un est à la recherche d'une solution à ce départ de @thomasnordquist solution ou mon adaptation de celui - ci, ils travaillent en désactivant le bac à sable sous Linux.

@fabiospampinato votre adaptation désactive le bac à sable pour tous les types de packages Linux, mais au moins les packages DEB et Pacman fonctionnent bien avec le sandbox SUID (probablement tous les packages qui ne sont pas de type conteneur), il suffit de définir le bit d'autorisation SUID sur chrome-sandbox binaire. Mais ne définissez pas le bit d'autorisation SUID pour le package Snap, car Snap Store rejette ce type de packages. J'ai donc défini le bit SUID pour tous les packages Linux, en attendant les packages Snap/AppImage qui désactivent le sandboxing, le code associé .

CONFIG_USER_NS=y active la fonctionnalité des espaces de noms d'utilisateurs, mais ils sont toujours limités aux utilisateurs privilégiés par défaut. Cela suggère sysctl kernel.unprivileged_userns_clone=1

Je confirme que l'exécution de sudo sysctl kernel.unprivileged_userns_clone=1 est une autre solution de contournement, commentaire connexe .

Merci mon pote, je travaille pour moi ! @vladimiry

savez-vous si cela fonctionne maintenant avec 5.0.2 ?

@p3x-robot Aucune mention de ce problème dans le changelog. Je viens de vérifier pour être sûr et l'erreur est toujours là pour moi.

@rybaczewa merci pour la réponse, je continue aussi sur la v4, car c'est un gros problème, j'ai hâte que la v5 fonctionne, ciao

J'ai hâte que la v5 fonctionne

la v5 fonctionne

Pour être clair pour les personnes dans ce fil @p3x-robot @rybaczewa, ce problème est laissé ouvert à des fins d'information / en aval. Electron lui-même fonctionne comme prévu et il n'y a rien ici à "réparer".

Si vous voyez ce message de journal, vous devez soit exécuter sudo sysctl kernel.unprivileged_userns_clone=1 soit donner au binaire chrome_sandbox les autorisations correctes, comme indiqué dans le message d'erreur.

@vladimiry @MarshallOfSound pourquoi dites-vous que c'est corrigé ? Dans Snap, je ne peux pas installer mes applications P3X Redis et P3X Onenote ni sudo sysctl kernel.unprivileged_userns_clone=1 ni donner le chrome_sandbox v5.0.x. Je ne peux installer qu'avec la v4.xx

Vous pensez qu'un utilisateur voudra utiliser sudo ? Ils penseront que ce programme est mauvais et ils désinstalleront l'application.
Les versions v5 ou v6 ou v7 ne fonctionnent pas correctement, c'est donc un bug :

La prise en charge de @p3x-robot snap comme indiqué ci-dessus dépend de la façon dont vous effectuez le snap. electron-installer-snap a un support pour cela prêt à l'emploi et comme mentionné ci-dessus, si ce module a des problèmes / ne fonctionne pas, veuillez soulever un problème sur ce module.

Veuillez consulter le dépôt electron-installer-snap pour plus de détails ou la documentation Snapcraft sur le sandboxing du navigateur

Pour réitérer, ma compréhension actuelle ici est qu'il n'y a pas de bogue à corriger, le bac à sable d'Electron fonctionne comme prévu. Ce qui est discuté ici, ce sont les problèmes auxquels les gens sont confrontés avec l'empaquetage du binaire chrome_sandbox

c'est bizarre, car j'ai déjà ajouté un bac à sable :

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

sortir:

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$ 

J'essaye ceci comme : app.enableSandbox() , mais j'obtiens :

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

Si je supprime la ligne, ça marche.

@MarshallOfSound j'utilise electron-builder

pour vous tous, si vous voulez que cela fonctionne, j'ai créé un assistant :
https://github.com/patrikx3/redis-ui/blob/master/src/build/after-pack.js
si vous utilisez electron-builder , vous l'ajoutez comme ceci :

pour vous tous, si vous voulez que cela fonctionne, j'ai créé un assistant :

Une telle solution a déjà été mentionnée à plusieurs reprises dans cette discussion sur ce problème, c'est pourquoi j'ai écrit avant que l'électron v5 fonctionne.

@vladimiry merci, j'ai raté cette solution, je viens d'ajouter une solution native javascript au lieu de tapuscrit...

le seul problème est que lorsque je fais ce piratage après le pack, il n'utilise pas sur le panneau l'icône d'électron, mais il génère une 2ème icône, comment pouvez-vous résoudre ce problème ? Je pense que c'est le drapeau sans bac à sable qui le fait. n'importe qui?

cela n'arrive qu'avec le --no-sandbox :

@fabiospampinato votre adaptation désactive le bac à sable pour tous les types de packages Linux, mais au moins les packages DEB et Pacman fonctionnent bien avec le sandbox SUID (probablement tous les packages qui ne sont pas de type conteneur), il suffit de définir le bit d'autorisation SUID sur chrome-sandbox binaire. Mais ne définissez pas le bit d'autorisation SUID pour le package Snap, car Snap Store rejette ce type de packages. J'ai donc défini le bit SUID pour tous les packages Linux, en attendant les packages Snap/AppImage qui désactivent le sandboxing, le code associé .

savez-vous comment je peux conserver une icône au lieu de deux ?

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

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

@p3x-robot, il existe un moyen d'ajouter l'argument --no-sandbox à l'application conteneur Snap empaquetée sans introduire un script bash/sh de type préchargeur :

• Décompressez d'abord le snap en exécutant unsquashfs your-snap-file.snap .
• Modifiez ./squashfs-root/command.sh en y ajoutant les arguments nécessaires.
• Remettez le dossier ./squashfs-root dans le package snap en exécutant la commande snapcraft pack ./squashfs-root .

Je n'ai pas essayé, mais je pense que l'action de reconditionnement similaire peut également être appliquée au package AppImage, c'est-à-dire qu'il s'agit d'exécuter différentes commandes unpack/pack.

Je suppose que les actions de reconditionnement décrites peuvent être déclenchées dans le crochet du constructeur d'électrons afterAllArtifactBuild .

@vladimiry merci beaucoup, car celui-ci est intéressant pour l'afterAllArtifactBuild, je vais essayer de changer le command.sh sans décompresser, mais c'est pour demain, merci encore !

celui est intéressant pour l'afterAllArtifactBuild

@p3x-robot afterAllArtifactBuild hook n'est en fait pas déclenché comme je m'y attendais, mais il est assez facile de déclencher le Snap ou tout autre type de package construit par programmation. Voir ici l'exemple de code. snapFile est le fichier de résultat ici, vous pouvez donc le décompresser/ unsquashfs ensuite, appliquer les modifications nécessaires et remettre en forme/ snapcraft pack . Dans l'exemple de code, je place les dictionnaires Hunspell dans le dossier ./usr/share/hunspell Snap.

@vladimiry, j'utilise simplement Electron v4, car cela fonctionne. Je pense que quelqu'un va régler ça.

@p3x-robot J'ai toujours tendance à penser qu'il faut admettre qu'il n'y a rien à réparer.

@vladimiry il n'y a rien à réparer, bien sûr. :)

quelqu'un sait si Electron v5.0.2 fonctionne avec le problème du bac à sable ?

C'est comme la v.5.0.0 :smile:

J'espère que ce n'est pas hors sujet, mais pour AppImages sur Debian (9), j'obtiens l'erreur :

The setuid sandbox is not running as root. 

Corrigez-moi si je me trompe mais je comprends (principalement à partir de cette discussion) que cela est causé par la fonctionnalité d'espaces de noms d'utilisateurs désactivée qui est désactivée par défaut sur Debian.

Donc concernant cette proposition :

1. Ne changez rien dans Electron. Recommandez aux développeurs d'activer les CLONE_USERNS non privilégiés sur leur noyau pour permettre au bac à sable de l'espace de noms de s'exécuter à la place du bac à sable setuid.

Je voudrais afficher un message aux utilisateurs disant que cela ne fonctionne que lorsque la fonctionnalité des espaces de noms d'utilisateurs est activée (avec peut-être un indice sur la façon de le faire) et suggérer d'utiliser le package .deb comme alternative.

Comment puis-je implémenter un tel message avant que l'erreur ne s'affiche ? Existe-t-il un moyen d'ajouter un script personnalisé à l'AppRun de l'AppImage sans décompresser ni remballer ?

Existe-t-il un moyen d'ajouter un script personnalisé à l'AppRun de l'AppImage sans décompresser ni remballer ?

@gcascio, il y avait des messages dans le fil sur l'utilisation d'un script sh de type chargeur qui peut être injecté par un script

Merci pour votre réponse. Mais je pense que l'AppRun généré n'est pas disponible lorsque afterpack est appelé ou est-ce que je me trompe, du moins je ne le trouve pas dans appOutDir ?

Je pense que l'AppRun généré n'est pas disponible lorsque l'afterpack est appelé

J'écrivais sur l'utilisation d'un script sh de type chargeur, mais pas sur la correction du script AppRun. Si vous souhaitez corriger le script AppRun, il semble qu'il n'y ait aucun moyen de le faire sans reconditionnement.

D'accord j'ai mal compris. Je vais peut-être aller avec le remballage alors merci.

Je vais peut-être aller avec le remballage alors merci.

@gcascio au cas où vous auriez besoin d'un modèle .

ia même erreur "Le binaire d'aide au bac à sable SUID a été trouvé" mais sur le fichier snap après l'installation
comment peut-on régler ça

@vladimiry Je travaille dans un Docker IDE en ligne appelé http://gitpod.io exécutant un conteneur Debian. Je ne peux pas résoudre le problème de chrome-sandbox car je n'ai pas d'accès sudo. Le ton général ici est qu'il s'agit d'un problème Chrome et non d'un problème Electron, mais si Electron pouvait résoudre le problème, ne serait-ce pas une bonne chose ?

Depuis ce site https://www.gitpod.io/blog/gitpodify/ j'ai vu une solution pour utiliser Puppeteer dans le conteneur.

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

Electron pourrait-il essayer un code comme celui-ci si l'erreur du bac à sable se produit, avant de tuer le processus ? Ou est-ce quelque chose que je pourrais invoquer avec un fichier bash ?

Electron pourrait-il essayer un code comme celui-ci si l'erreur du bac à sable se produit, avant de tuer le processus ? Ou est-ce quelque chose que je pourrais invoquer avec un fichier bash ?

Oui, passer l'argument --no-sandbox au binaire de l'application électronique en général est censé contourner le problème.

Selon le package d'installation, vous pouvez définir le bit d'autorisation SUID (4755) sur chrome-sandbox binary (pour les packages comme deb, pacman, etc.) ou coder en dur l'argument --no-sandbox du script sh/bash du chargeur (pour les packages comme Snap et AppImage). C'est ce que je fais actuellement et il n'y a donc rien à faire pour les utilisateurs de l'application (aucun accès sudo requis).

La récente version du constructeur d'électrons contient déjà un codage en dur de l'argument --no-sandbox , mais uniquement pour le package Snap.

Merci @vladimiry electron résolu le problème. Je vais aussi vérifier SNAP.

il existe de nouveaux constructeurs d'électrons, mais l'AppImage n'est toujours pas corrigé, n'est-ce pas ?

est-ce que l'électron 6 corrige l'erreur du bac à sable ? je suis toujours sur v4 car je ne peux pas résoudre ce problème, ni 5 ni 6.

Voici la situation :

• Electron v5 a permis le sandboxing en mode mixte (c'est-à-dire que certains processus sont en sandbox et d'autres non) sur Linux. Cela ne change pas si vos processus de rendu sont en bac à sable par défaut, mais cela signifie que le processus GPU est maintenant en bac à sable.
• Le bac à sable de Chromium sous Linux utilise une fonctionnalité du système d'exploitation appelée CLONE_NEWUSER . Certains noyaux sont construits avec cette fonctionnalité réservée aux utilisateurs privilégiés par prudence. Vous pouvez en savoir plus à ce sujet ici [lwn, 2016].
• Lorsque CLONE_NEWUSER n'est pas disponible, Chromium utilise un mécanisme de sandboxing différent qui nécessite un binaire d'aide défini pour root. Si ce binaire n'est pas présent ou n'a pas les bonnes autorisations ( 4755 _et appartient à root_), le bac à sable ne pourra pas démarrer.
• La définition des autorisations binaires de l'assistant doit être effectuée par un utilisateur privilégié (c'est-à-dire root). Nous ne définissons pas ces autorisations sur npm install , car nous ne voulons pas demander un accès root pendant npm install .
• Les packages de version Electron v5 incluent le binaire d'aide, mais il appartient aux différents outils d'emballage et de distribution de s'assurer qu'il obtient les bonnes autorisations et la bonne propriété.

Il existe deux solutions de contournement :

1. Activez l'accès non privilégié à CLONE_NEWUSER dans votre noyau. Certains noyaux prennent en charge le changement avec sysctl kernel.unprivileged_userns_clone=1 .
2. Désactivez complètement le sandbox en lançant avec --no-sandbox . L'ajout de cet argument depuis JS est malheureusement insuffisant, car le processus GPU est lancé avant l'exécution du processus principal JS.

Nous ne prendrons pas en charge la désactivation automatique du bac à sable dans Electron lorsque ces conditions sont détectées. Vous devez vous assurer que vos packages distribués définissent les autorisations appropriées. La plupart des outils (au moins electron-builder, electron-installer-snap, electron-installer-debian et electron-installer-redhat) prennent en charge cela automatiquement et ne nécessitent aucune configuration de la part du développeur. Si vous utilisez un autre outil qui ne prend pas en charge cela, veuillez soulever un problème sur cet outil et créer un lien vers ce commentaire.

Je ferme ce problème car, comme mentionné dans le paragraphe précédent, nous ne modifierons pas l'exigence selon laquelle Electron en production nécessite l'accès à un bac à sable fonctionnel, sauf indication contraire explicite. Cependant, pour faciliter le développement, j'ai ouvert #19550 pour suivre l'option de dégradation automatique en mode non sandbox lorsque Electron est installé via npm install , plutôt que via un package distribué.

@p3x-robot, vous pouvez trouver un exemple minimal pour la solution de contournement 2. mentionnée par @nornagon ici qui est inspirée de @vladimiry

@gcascio mais je peux supprimer le snap hack non? comme le snap est élaboré dans le générateur d'électrons, pouvez-vous confirmer?

@gcascio ça marche, merci beaucoup ! Ça marche!

@gcascio no workie, il génère 2 icônes, donc je suis revenu à electron v4.2.8... :(

@p3x-robot merci pour le retour. Au cas où vous seriez intéressé, j'ai créé un problème et je l'enverrai dès que je trouverai un peu de temps.

@nornagon donc nous ne pouvons même pas exécuter Electron 6 sur Debian et il n'y a aucun moyen que nous donnions à un processus chrome des autorisations root. Les solutions de contournement données ne sont pas suffisantes du point de vue de l'utilisateur.

Il existe deux solutions de contournement :
Activez l'accès non privilégié à CLONE_NEWUSER dans votre noyau. Certains noyaux prennent en charge le changement avec sysctl kernel.unprivileged_userns_clone=1.

Il n'y a absolument aucun moyen de jouer avec l'ordinateur des clients est la façon de s'y prendre.

Désactivez complètement le sandbox en lançant avec --no-sandbox. L'ajout de cet argument depuis JS est malheureusement insuffisant, car le processus GPU est lancé avant l'exécution du processus principal JS.

Que diriez-vous d'ajouter un indicateur --sandbox et de désactiver la fonctionnalité sandbox par défaut ? Cela a l'avantage de ne pas déranger 99% des personnes utilisant Electron.

Les solutions de contournement données ne sont pas suffisantes du point de vue de l'utilisateur.

L'utilisation d'un script/programme de type chargeur qui ajoutera --no-sandbox arg peut également être considérée comme une solution de contournement, donc aucune action de l'utilisateur final n'est nécessaire. En outre, un tel chargeur pourrait d'abord tester le support de user namespace et ajouter --no-sandbox uniquement si nécessaire.

@pronebird donner la racine setuid binaire chrome-sandbox est beaucoup moins dangereux que d'exécuter Electron sans bac à sable. Considérez : _vous_ qui expédiez les binaires Electron, vous pouvez donc être sûr d'expédier du code de confiance (par exemple en le signant). Cependant, si votre application peut être convaincue de charger du code non fiable (peut-être intentionnellement, par exemple en naviguant vers une URL sur le Web), l'application exécutera volontiers ce code avec la permission de l'utilisateur, sans aucune sorte de bac à sable. Je serais beaucoup plus préoccupé par la défense contre les attaques axées sur l'exécution de JS non fiables dans un processus non sandbox dans votre application que par les attaques impliquant l'exploitation d'un bogue dans le même système de sandboxing que Chrome utilise. (Et je m'attendrais à ce que ces derniers soient corrigés _très rapidement_ s'ils étaient découverts.) Si vous souhaitez auditer vous-même le code du binaire chrome-sandbox , vous pouvez commencer ici : https://chromium.googlesource. com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox.c#424

Si vous vous engagez à fonctionner sans bac à sable Electron, je vous recommande fortement le bac à sable d'une autre manière, par exemple snapcraft ou flatpak, les emballeurs pour lesquels je pense incluent des scripts de lancement qui désactivent le bac à sable d'Electron à l'intérieur du conteneur.

@nornagon

donner la racine setuid binaire chrome-sandbox est beaucoup moins dangereux que d'exécuter Electron sans sandbox. Considérez : vous êtes celui qui expédie les binaires Electron, vous pouvez donc être sûr que vous envoyez du code de confiance (par exemple en le signant). Cependant, si votre application peut être convaincue de charger du code non fiable (peut-être intentionnellement, par exemple en naviguant vers une URL sur le Web), l'application exécutera volontiers ce code avec la permission de l'utilisateur, sans aucune sorte de bac à sable. Je serais beaucoup plus préoccupé par la défense contre les attaques axées sur l'exécution de JS non fiables dans un processus non sandbox dans votre application que par les attaques impliquant l'exploitation d'un bogue dans le même système de sandboxing que Chrome utilise. (Et je m'attendrais à ce que ces derniers soient corrigés très rapidement s'ils étaient découverts.)

Bien sûr, mais exécuter un bac à sable n'a pas de sens si vous avez une application qui ne charge jamais de contenu distant. Je pense que cela doit être le cas pour Electron - pour créer des applications de bureau à l'aide d'une pile Web, en chargeant peut-être JSON à partir du Web, mais pas comme pour simplement afficher des pages Web comme si nous n'avions pas Safari pour cela. Nous avons dépassé le temps où les gens avaient l'habitude d'envelopper les sites Web dans un espace téléphonique, n'est-ce pas ?

Je pense que les frais généraux sont beaucoup trop importants. J'ai ajouté un script d'amorçage aujourd'hui dans notre application et supprimé le binaire chrome-sandbox de la distribution, ce qui représentait 5 Mo supplémentaires. Malheureusement, electron-builder ne supporte rien de tout cela, nous avons donc dû ajouter un crochet et le faire nous-mêmes.

Si vous souhaitez auditer vous-même le code du binaire chrome-sandbox, vous pouvez commencer ici : https://chromium.googlesource.com/chromium/src/+/refs/heads/master/sandbox/linux/suid/sandbox. c#424

Merci. Cela dépend vraiment d'un modèle de menace, et il est impossible d'exécuter quoi que ce soit de Google avec des autorisations root.

Cela peut être tout à fait sûr, mais il serait également très difficile de vérifier que toutes les sources sont intactes, car les constructions d'électrons sont expédiées via npm. Nous devrions configurer un serveur de construction personnalisé pour Electron et auditer les sources nous-mêmes. Ce serait un effort énorme et je préférerais l'éviter.

@pronebird Je ne vais pas trop m'impliquer dans la discussion sur le bac à sable, mais ma position ici est que nous devrions avoir le bac à sable activé par défaut comme nous le faisons actuellement.

Cela peut être tout à fait sûr, mais il serait également très difficile de vérifier que toutes les sources sont intactes car les constructions d'électrons sont expédiées via npm

Ceci est fondamentalement incorrect, les constructions d'électrons ne sont pas expédiées via npm. Le package electron sur npm contient en fait environ 2 fichiers et environ 40 lignes de JS. Les versions réelles d'Electron sont livrées via S3 et ont également des sommes de contrôle sur S3 afin que les utilisateurs puissent valider que la version qu'ils téléchargent est en fait la version fournie par Electron.

@MarshallOfSound

Ceci est fondamentalement incorrect, les constructions d'électrons ne sont pas expédiées via npm. Le paquetage électronique sur npm contient en fait environ 2 fichiers et environ 40 lignes de JS. Les versions réelles d'Electron sont livrées via S3 et ont également des sommes de contrôle sur S3 afin que les utilisateurs puissent valider que la version qu'ils téléchargent est en fait la version fournie par Electron.

Ce que je voulais dire, c'est que les builds sont téléchargés pendant l'étape npm install . Je ne voulais pas dire qu'ils sont physiquement hébergés sur npm. Qu'ils soient hébergés sur S3. Prouvez-moi que j'ai tort, mais je parie que les sommes de contrôle sont hébergées sur le même S3, ce qui abaisse le niveau de sécurité d'un tel système, ce n'est qu'une jambe. Mais ce n'est pas le sujet. Imaginez le scénario dans lequel vos builds sont falsifiés et les sommes de contrôle mises à jour en conséquence. Maintenant, nous avons un problème. C'est simplement un contrôle des risques et des dommages de mon côté. Pas de racine = moins de risques que quelque chose de vraiment grave se produise.

Le binaire @pronebird chrome-sandbox ne devrait certainement pas faire 5 Mo, c'est un bogue. J'ai ouvert le #20049 pour le réparer, merci de l'avoir signalé.

Vous pouvez certainement choisir de désactiver le sandboxing pour votre cas d'utilisation. Il est dommage que l'architecture de Chromium fasse en sorte que vous deviez passer directement --no-sandbox sur la ligne de commande plutôt que d'appeler app.commandLine.appendSwitch ; idéalement, la désactivation du bac à sable serait possible sans nécessiter de script wrapper. Espérons qu'avec #20049, le souci de supprimer le binaire sera amélioré, car 200 Ko supplémentaires sont beaucoup plus raisonnables à vivre que 5 Mo.

Existe-t-il une option pour utiliser un binaire système ? J'ai des réserves quant à l'attribution d'un bit root suid à quoi que ce soit dans mon dossier node_modules/. Merci.

@gardner, vous pouvez passer --no-sandbox arg qui est une sorte de solution de contournement facile lorsque vous êtes en mode développeur.

VSCode vient tout juste de passer à Electron 6 et nous obtenons maintenant des rapports indiquant que VSCode ne démarre plus à moins que l'option --no-sandbox soit fournie. Quelle est la voie à suivre ici? Réfs : https://github.com/microsoft/vscode/issues/81056

snap est maintenant prêt à l'emploi, pour appimage, il existe un code écrit en dur :
https://github.com/electron-userland/electron-builder/issues/3872#issuecomment -517875676

le reste je ne sais pas, je ne publie que NPM, AppImage et SNAP...

en gros, vous devez reconditionner chaque type d'élément pour ajouter un argument ( --no-sandbox ) au script de lancement.

il n'y a pas de solution sur Electron 6 je suppose, soit vous devez l'écrire en fonction de vos packages, soit attendre un correctif ou une rétrogradation ...

Pour une meilleure expérience de développeur. Nous pouvons configurer une commande comme ci-dessous dans l'outil electron cli.

sudo chown root pathToChromeSandboxDynamicallyGenearted && sudo chmod 4755 pathToChromeSandboxDynamicallyGenearted

Une commande comme electron --ConfigSandbox.
L'utilisateur sera au courant et le bac à sable peut être facilement configuré.
Et même lors de la première exécution. Nous pouvons leur demander s'ils veulent prendre des mesures. oui ou non. Et puis tout ce qu'ils ont à faire est d'entrer le mot de passe. De cette façon, cela se fera en un coup d'œil. Et cela conduira à une grande expérience utilisateur et gagnera dans le temps. Parce que vous ferez confiance au vendeur ou à la communauté. Et allez avec. Au lieu de chercher partout sur le net. Et c'est encore plus précieux pour les plus débutants d'entre nous. Et c'est sympa dans tous les cas.

Ce problème a été résolu mais je l'ai toujours avec electron 7.0.0 . Y a-t-il un commit qui a abouti à un correctif ?

Pourquoi le problème a-t-il été clos ? Il ne semble pas y avoir de correctif disponible car il persiste même dans la v7.0.0

Parce qu'il s'agit d'emballer votre application mais pas d'Electron.

Ah, d'accord. Mais comment dois-je procéder pour résoudre ce problème, cependant? Existe-t-il un moyen pour l'utilisateur final de ne pas avoir à faire de travail supplémentaire ?

Existe-t-il un moyen pour l'utilisateur final de ne pas avoir à faire de travail supplémentaire ?

Oui, il y a un moyen, cela a déjà été discuté.

sudo sysctl kernel.unprivileged_userns_clone=1

Il y a un problème avec les utilisateurs de WSL (il y en a beaucoup qui utilisent WSL) et WSL 1 n'utilise pas de noyau Linux réel... il faudrait attendre la sortie de WSL2.

Pour référence concernant cette limitation : https://askubuntu.com/questions/1145525/how-to-create-proc-sys-kernel-unprivileged-userns-clone-file

CONFIG_USER_NS=y active la fonctionnalité des espaces de noms d'utilisateurs, mais ils sont toujours limités aux utilisateurs privilégiés par défaut. Cela suggère sysctl kernel.unprivileged_userns_clone=1

Je confirme que l'exécution de sudo sysctl kernel.unprivileged_userns_clone=1 est une autre solution de contournement, commentaire connexe .

Oui, j'utilise manjaro et i3wm, j'ai pris la même erreur mais avec ça ça marche.

Ai-je raté quelque chose, ou n'est-il plus possible de simplement télécharger et exécuter une application Electron sans accès root ? Désolé, je n'avais pas réalisé que cela était spécifique à Debian et que le noyau principal ne prend même pas en charge la désactivation des espaces de noms non privilégiés.

Pardonnez mon audace, mais c'est complètement fou. Electron expose l'API Node.js même dans les processus de rendu. Utiliser/activer le bac à sable de Chromium dans une application Electron est totalement inutile, et comme vous pouvez tous le voir dans les rapports de bogues autour de GitHub indiquant ce problème, c'est également très contre-productif. Veuillez le désactiver si possible.

Electron expose l'API Node.js même dans les processus de rendu.

nodeIntegration option

Désolé, je n'avais pas réalisé que cela était spécifique à Debian et que le noyau principal ne prend même pas en charge la désactivation des espaces de noms non privilégiés.

Donc sous debian, j'ai l'air chanceux d'avoir un accès root sur ma machine. Mais ai-je raison de dire que cette fonctionnalité telle qu'elle est empêchera les utilisateurs d'exécuter des applications électroniques (en tant qu'AppImage ou non) sans

a) ayant sudo , ou
b) être capable de convaincre quelqu'un qui a sudo d'activer les espaces de noms non privilégiés ?

@black-puppydog eh bien, s'ils construisent l'application à partir de la source, ils pourraient éditer le script de démarrage pour transmettre l'argument --no-sandbox à electron. Il devrait être possible de modifier une AppImage avec le même effet (en la décompressant et en la remballant), mais je n'ai pas essayé moi-même. Il n'est pas non plus impossible que certains créateurs d'AppImage incluent ce drapeau dans leurs versions, auquel cas ces images spécifiques fonctionneraient.

Sinon, je pense que tu as raison. Notez que le noyau principal a toujours des espaces de noms non privilégiés activés et ne fournit aucun moyen de les désactiver. C'est pourquoi ce n'est un problème que sur Debian.

@black-puppydog Si je me souviens bien, le programme d'installation vous demande un mot de passe root lorsque vous installez Debian pour la première fois sur votre machine. Mais oui, sur Debian (ou tout autre système utilisant le correctif du noyau Debian), vous devez soit avoir un accès root (via sudo ou autrement), soit exécuter des applications Electron avec --no-sandbox .

@ndorf Dans Linux principal, les espaces de noms d'utilisateurs peuvent être désactivés en ne compilant pas dans la fonctionnalité, mais ils ne peuvent pas être activés/désactivés au moment de l'exécution ou limités aux processus privilégiés uniquement. Debian corrige ses noyaux de telle sorte que les espaces de noms d'utilisateurs sont limités aux processus privilégiés par défaut, mais peuvent être activés pour tous les processus avec un paramètre inférieur à /proc/sys .

La raison pour laquelle Debian le restreint est que les espaces de noms d'utilisateurs non privilégiés représentent un risque de sécurité sérieux avec une longue histoire de vulnérabilités. Les espaces de noms d'utilisateurs non privilégiés permettent aux processus non privilégiés d'accéder à de nombreuses fonctionnalités du noyau (UID 0, capacités, monter un système de fichiers, créer un inode de périphérique, etc.) qui ont été limitées aux processus privilégiés pendant très longtemps. Tout code du noyau s'appuyant sur l'hypothèse que les processus non privilégiés ne pourront jamais faire ces choses est vulnérable maintenant que les processus non privilégiés sont soudainement capables de faire ces choses.

Existe-t-il une solution de contournement possible jusqu'à ce que chaque distribution Linux active ces fonctionnalités ?

Voir le message d'origine :

Si je chown et chmod le fichier, cela fonctionne bien

Voir aussi ici #16631 (commentaire) Donc, pour faire fonctionner suid sandbox, vous devez essentiellement modifier le binaire chrome-sandbox cette façon :

* `sudo chown root chrome-sandbox`

* `chmod 4755 chrome-sandbox`

Le problème est plus grave, mais si vous exécutez des packages appimage/snap, je n'ai pas encore révélé de solution de contournement décente pour ces cas. Cela fonctionne si appimage est exécuté avec --no-sandbox arguments, mais c'est un hack.

Cela fonctionne si j'exécute l'application à partir du répertoire déballé. Comment packager ce répertoire après avoir modifié les permissions de chrome-sandbox ?

@shrinidhi111 4755 peut être conservé lors de l'empaquetage, au moins dans le cas des packages pacman/deb. Les packages peuvent également être modifiés au niveau de la dist spécifique, par exemple . En ce qui concerne le propriétaire racine, normalement, lorsque le package est installé à partir du référentiel sous Linux, les fichiers associés obtiennent le propriétaire racine. Dans le cas de la construction d'AppImage, je le reconditionne et je code en dur --no-sandbox arg dans le script AppRun interne, car le constructeur d'électrons ne le fait pas encore hors de la boîte. Le package Snap est formé par electron-builder avec --no-sandbox arg codé en dur (correctif associé ajouté il y a environ 6 mois).

@shrinidhi111 4755 peut être conservé une fois emballé, au moins dans le cas des packages pacman/dev. Les packages peuvent également être modifiés au niveau de la dist spécifique, par exemple . En ce qui concerne le propriétaire racine, normalement, lorsque le package est installé à partir du référentiel sous Linux, les fichiers associés obtiennent le propriétaire racine. Dans le cas de la construction d'AppImage, je le reconditionne et je code en dur --no-sandbox arg dans le script AppRun interne, car le constructeur d'électrons ne le fait pas encore hors de la boîte. Le package Snap est formé par electron-builder avec --no-sandbox arg codé en dur (correctif associé ajouté il y a environ 6 mois).

La création d'un fichier instantané était une excellente idée et m'a permis d'économiser beaucoup de travail. Merci encore!

comment est-ce encore non résolu

sur snap est corrigé, j'ai ma propre version qui fonctionne avec appimage. car le reste n'est pas résolu.

Ce fil est incroyablement long et l'erreur persiste. Y a-t-il un résumé de la situation quelque part? Peut-être qu'un tel résumé pourrait être lié à l'erreur.

Il semble que https://github.com/electron/electron/issues/17972#issuecomment -495767027 et similaires proposent qu'il suffise d'avoir une fonction électronique facilement et en toute sécurité uniquement sur les systèmes avec accès root. Ce serait peut-être bien si le système détectait les paramètres d'autorisation incorrects et offrait des avertissements aux développeurs, afin de réduire les utilisateurs confrontés à ce problème, mais c'est peut-être un problème distinct. Il semble également que ce serait bien s'il y avait un chemin pour les utilisateurs sans accès root pour utiliser facilement l'électron, avec une compréhension évidente que les ressources non fiables sont plus dangereuses que d'habitude.

chemin pour les utilisateurs sans accès root pour utiliser electron facilement

--no-sandbox Argument CLI.

vladimiry, je pensais par exemple aux utilisateurs finaux sans grande expérience des terminaux ou à l'exécution d'applications qui enveloppent l'électron

Je pensais par exemple aux utilisateurs finaux sans grande expérience des terminaux, ou exécutant des applications qui enveloppent l'électron

Intégrez ce --no-sandbox dans le raccourci de l'application. Tout package Linux ici fonctionnera bien, quelle que soit la valeur système de kernel.unprivileged_userns_clone . Il s'agit donc d'empaqueter l'application.

C'est vrai si je suis développeur et que je fais un avertissement approprié pour mes utilisateurs finaux. De nombreux développeurs n'apprendront-ils jamais ce problème en raison du bac à sable de l'espace de noms qui fonctionne pour eux ? Il est également inquiétant que les solutions existantes soient en place sans communiquer aux personnes concernées que les ressources non fiables sont plus dangereuses.

Cette solution ne fonctionne que lorsque vous obtenez cette erreur à cause de WSL

J'ai rencontré ce problème en essayant d'utiliser electron sur WSL (WSL2 dans mon cas).
Même en utilisant un serveur X11, electron n'a pas pu fonctionner sur X11.

J'ai dû construire electron pour Windows, même si je l'exécute dans WSL. Après cela, tout fonctionne comme sauf
La façon la plus simple de le faire :

• Désinstaller l'électron npm uninstall electron
• Changer la plate-forme de configuration npm export npm_config_platform=win32
• Installer l'électron npm install electron
• Désactivez la variable d'environnement unset npm_config_platform

Cela suggère sysctl kernel.unprivileged_userns_clone=1

Je vois ce problème avec WSL (Windows 10), Ubuntu 18.04 installé dans WSL.
sudo sysctl kernel.unprivileged_userns_clone=1 ne fonctionne pas.

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

L'utilisation de chown et chmod n'est pas non plus une option.

@MarshallOfSound zip ne prend pas en charge les autorisations, mais en fin de compte, le problème n'est pas l'autorisation chmod, mais plutôt le propriétaire. L'assistant sandbox setuid est suid _to root_, car il doit exécuter des fonctions qui ne sont disponibles que pour root. S'il était possible de définir les autorisations appropriées sans d'abord obtenir les privilèges root, ce serait une vulnérabilité très grave dans Linux. Heureusement pour Linux, et malheureusement pour nous, ce n'est pas le cas.

zip prend en charge les autorisations sur les systèmes basés sur Unix (ou au moins sur les variantes de Linux que j'ai testées). Voir https://serverfault.com/a/585889/17620

Les bits d'autorisation sont stockés dans le suffixe d'en-tête de fichier du répertoire central du zip. Le champ externalFileAttributes du suffixe peut être utilisé pour stocker les bits d'autorisation pour chaque entrée de fichier/répertoire.

cc @MarshallOfSound

J'ai le même problème !

[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]$ 

exécuter en tant qu'utilisateur normal , a une erreur : FATAL:setuid_sandbox_host.cc(157)] exécuter en tant qu'utilisateur root , a une erreur : FATAL:electron_main_delegate.cc(211)]

mais quand je miam installer snap après, exécuter en tant qu'utilisateur root ou normal est ok

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

Cela fonctionne bien.

@cuixiping ça marche :+1:

J'ai fait

$ 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

J'ai eu le même problème lorsque j'ai exécuté electron sur Deepin et j'ai résolu le problème avec ce code
electron . --no-sandbox

j'espère que ça t'aide

ne fonctionne pas

@fabiospampinato votre adaptation désactive le bac à sable pour tous les types de packages Linux, mais au moins les packages DEB et Pacman fonctionnent bien avec le sandbox SUID (probablement tous les packages qui ne sont pas de type conteneur), il suffit de définir le bit d'autorisation SUID sur chrome-sandbox binaire. Mais ne définissez pas le bit d'autorisation SUID pour le package Snap, car Snap Store rejette ce type de packages. J'ai donc défini le bit SUID pour tous les packages Linux, en attendant les packages Snap/AppImage qui désactivent le sandboxing, le code associé .

Salut @vladimiry
Je n'ai pas pu accéder au lien que vous avez joint ici. Pouvez-vous aider?
De plus, avez-vous pu comprendre comment faire --no-sandbox dans le script after-pack de générateur d'électrons ?

Merci

@tushar-compro, ici https://github.com/vladimiry/ElectronMail/tree/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack. Fondamentalement, j'ai défini 4755 bits dans le script après-pack pour certains types de packages tout en reconditionnant les packages appimage + snap. En fait, le constructeur d'électrons a déjà intégré --no-sandbox arg dans snap mais pas encore dans appimage https://github.com/electron-userland/electron-builder/pull/4496. Achetez le chemin, ces jours-ci, le constructeur d'électrons définit déjà 4755 bits https://github.com/electron-userland/electron-builder/blob/fc85a42a26df863b5bade4b769182b299ff24e0a/packages/app-builder-lib/templates/linux/after-install.tpl #L7. La version récente du générateur d'électrons devrait donc simplifier les choses pour la plupart des développeurs.

@vladimiry
Ai-je raison de comprendre que vous avez défini le bit 4755 pour des cibles AUTRES QUE appimage et snap.
https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/hooks/afterPack/index.ts#L17

Mais le problème se produit lors de l'utilisation du programme d'installation .appimage sur la distribution Debian.

Est-ce que j'ai râté quelque chose?

Mais le problème se produit lors de l'utilisation du programme d'installation .appimage sur la distribution Debian.

Comme je l'ai dit, l'appimage nécessite toujours un traitement spécial. Je le reconditionne et intègre le --no-sandbox dans le script ./AppRun . Recherchez le mot-clé DISABLE_SANDBOX_ARGS_LINE ici https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

Mais le problème se produit lors de l'utilisation du programme d'installation .appimage sur la distribution Debian.

Comme je l'ai dit, l'appimage nécessite toujours un traitement spécial. Je le reconditionne et intègre le --no-sandbox dans le script ./AppRun . Recherchez le mot-clé DISABLE_SANDBOX_ARGS_LINE ici https://github.com/vladimiry/ElectronMail/blob/704865abe5187bbf3e9f15ba5a83612f249f8118/scripts/electron-builder/build-appimage.ts.

le dernier générateur d'électrons prend automatiquement en charge l'argument no sanbox dans snap et appimage.

@vladimiry
Donc, ai-je raison de comprendre que le paramètre 4755 bits que vous avez effectué est destiné aux installateurs autres que appimage et snap. Et pour appimage, vous avez défini no-sandbox. Pouvez-vous confirmez s'il vous plaît.

@p3x-robot
Oui. tu as en partie raison.

1. Le dernier constructeur d'électrons ne définit pas de bac à sable pour snap mais PAS pour appimage. Cependant, ils ont défini 4755 bits pour appimage.
2. Dans mon projet, j'utilise la version électronique 20.xx La mise à jour vers 22.xx sera un effort en soi. J'essaye juste d'éviter ça si possible. La mise à jour vers la v22 sera le dernier recours.

le dernier générateur d'électrons prend automatiquement en charge l'argument no sanbox dans snap et appimage.

Impossible de localiser dans leur code l'extrait spécifique à l'application similaire à celui- ci appliqué aux snaps (https://github.com/electron-userland/electron-builder/pull/4496 toujours ouvert). Quoi qu'il en soit, dans mon cas, le remballage est toujours nécessaire puisque j'y ai mis des arguments supplémentaires, autres que ceux liés à sanbox.

Donc, ai-je raison de comprendre que le paramètre 4755 bits que vous avez effectué est destiné aux installateurs autres que appimage et snap. Et pour appimage, vous avez défini no-sandbox. Pouvez-vous confirmez s'il vous plaît.

Correct. Mais le constructeur d'électrons moderne définit 4755 en interne. Je vérifie cependant qu'il n'est pas défini pour snap/appimage car ce serait une erreur. Par exemple, snap ne démarrera pas avec 4755 bits définis sur le binaire électronique si je me souviens bien des choses.

@vladimiry
J'ai juste besoin de définir no-sandbox car mes images d'application ne fonctionnent pas dans Debian.

Je pense que je n'aurai pas besoin de remballage dans ce cas. Mais je n'ai pas pu trouver la bonne documentation du constructeur d'électrons pour le faire. Ou pensez-vous que j'aurai aussi besoin de remballage?

Pouvez-vous m'indiquer la bonne documentation qui peut m'aider dans la façon de le faire.

De plus, je comprends que j'ai les deux options, soit la définition de 4755 bits, soit la définition de l'absence de bac à sable.
Lequel pensez-vous est le meilleur?

De plus, je comprends que j'ai les deux options, soit la définition de 4755 bits, soit la définition de l'absence de bac à sable.

Si je me souviens bien, les paramètres 4755 d'appimage ne résoudront pas le problème. Vous devez (l'un des) :

• démarrez votre fichier appimage avec la ligne de commande --no-sandbox arg
• avoir --no-sandbox intégré dans le script ./AppRun situé dans votre fichier appimage (un reconditionnement est donc nécessaire).

Pouvez-vous m'indiquer la bonne documentation qui peut m'aider dans la façon de le faire.

Je doute que vous trouviez des informations détaillées sur le problème dans une quelconque documentation. Je ne connais aucun document pertinent.

De plus, je comprends que j'ai les deux options, soit la définition de 4755 bits, soit la définition de l'absence de bac à sable.

Si je me souviens bien, les paramètres 4755 d'appimage ne résoudront pas le problème. Vous devez (l'un des) :

• démarrez-le avec la ligne de commande --no-sandbox arg
• avoir --no-sandbox intégré dans le script ./AppRun situé dans votre fichier appiamge (un reconditionnement est donc nécessaire).

Pouvez-vous m'indiquer la bonne documentation qui peut m'aider dans la façon de le faire.

Je doute que vous trouviez des informations détaillées sur le problème dans une quelconque documentation. Je ne connais aucun document pertinent.

le constructeur d'électrons le plus récent intègre le --no-sandbox dans le ./AppRun , j'avais l'habitude de reconditionner, mais maintenant c'est inutile, j'utilise juste le constructeur d'électrons natif.

@vladimiry
Oui. le réglage 4755 seul ne fonctionnera pas. Avec 4755, nous devons changer le propriétaire de chrome-sandbox en root.
En tout cas, merci beaucoup pour votre aide. Je vais essayer de faire référence à votre code et de définir le non-bac à sable alors.

@p3x-robot
Pouvez-vous s'il vous plaît partager un lien (dépôt de constructeur d'électrons) où nous pouvons voir le code faire cela.

https://github.com/patrikx3/onenote

@vladimiry
Oui. le réglage 4755 seul ne fonctionnera pas. Avec 4755, nous devons changer le propriétaire de chrome-sandbox en root.
En tout cas, merci beaucoup pour votre aide. Je vais essayer de faire référence à votre code et de définir le non-bac à sable alors.

@p3x-robot
Pouvez-vous s'il vous plaît partager un lien (dépôt de constructeur d'électrons) où nous pouvons voir le code faire cela.

https://github.com/patrikx3/onenote

le constructeur d'électrons le plus récent intègre le --no-sandbox dans le ./AppRun, j'avais l'habitude de reconditionner, mais maintenant c'est inutile, j'utilise simplement le constructeur d'électrons natif.

Je viens de le tester à l'aide de la version récente du générateur d'électrons et il n'intègre pas le --no-sandbox dans le script ./AppRun sh. Si vous démarrez l'image d'application, elle échoue avec une erreur connue de type [759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found . Peut-être que le drapeau kernel.unprivileged_userns_clone activé sur votre système. Si c'est le cas, essayez de le désactiver comme sudo sysctl kernel.unprivileged_userns_clone=0 et redémarrez le fichier appimage.

le constructeur d'électrons le plus récent intègre le --no-sandbox dans le ./AppRun, j'avais l'habitude de reconditionner, mais maintenant c'est inutile, j'utilise simplement le constructeur d'électrons natif.

Je viens de le tester à l'aide de la version récente du générateur d'électrons et il n'intègre pas le --no-sandbox dans le script ./AppRun sh. Si vous démarrez l'image d'application, elle échoue avec une erreur connue de type [759164:1013/160044.572604:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found . Peut-être que le drapeau kernel.unprivileged_userns_clone activé sur votre système. Si c'est le cas, essayez de le désactiver comme sudo sysctl kernel.unprivileged_userns_clone=0 et redémarrez le fichier appimage.

bizarre, il y a des installations instantanées 10k avec le dernier constructeur d'électrons. et définitivement le constructeur d'électrons montre qu'il ajoute ce drapeau ...

il y a 10k snap

Nous parlons d'appimage, pas de snap. Snap a bien sûr l'argument intégré comme je l'ai mentionné ci-dessus, ici https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197 -L202.

il y a 10k snap

Nous parlons d'appimage, pas de snap. Snap a bien sûr l'argument intégré comme je l'ai mentionné ci-dessus, ici https://github.com/electron-userland/electron-builder/blob/df5d050e47f2030e48e65c0e3b542c3aec61e9de/packages/app-builder-lib/src/targets/snap.ts#L197 -L202.

vous avez raison. Je pensais que pour une raison quelconque, cela avait été fait dans appimage, j'ai même supprimé le code du reconditionnement et ajouté no-sandbox, mais j'ai réessayé et je vois qu'il manque, alors j'ai ajouté mon retour de ma version, non travaux. désolé, dans mon corifeus-builder, vous pouvez voir ce que je fais : https://github.com/patrikx3/corifeus-builder/blob/master/src/utils/appimage/after-all-artifact-build.js

Salut @nornagon compte tenu de la démarrage rapide des électrons peut solution de contournement afin que les débutants aient une expérience positive ?

Edit : Grâce aux encouragements de la communauté j'ai ouvert un FR #26478

@gabefair Cela semble être une proposition raisonnable. Seriez-vous intéressé à ouvrir un PR?