Aller au contenu principal

Mise en bac à sable de processus

L'une des principales fonctionnalités de sécurité de Chromium est que les processus peuvent être exécutés dans un bac à sable. Le bac à sable, en limitant l'accès à la plupart des ressources du système, limite les dommages qu'un code malveillant pourrait causer — les processus en bac à sable ne peuvent utiliser librement que les cycles et la mémoire du processeur. Afin d’effectuer des opérations nécessitant des privilèges supplémentaires, les processus en bac à sable utilisent des canaux de communication dédiés pour déléguer ces tâches à des processus plus privilégiés.

Dans Chromium, le bac à sable est appliqué à la plupart des processus autres que le processus principal. Cela inclut les processus de rendu, ainsi que les processus utilitaires tels que le service audio, le service GPU et le service réseau.

Reportez-vous au document Conception du bac à sable pour plus d'informations.

Politiques du bac à sable d’Electron

Electron est livré avec un environnement de bac à sable mixte, ce qui signifie que les processus s'y exécutant peuvent fonctionner aux côtés de processus privilégiés. Par défaut, les processus de rendu ne sont pas en bac à sable mais les processus utilitaires le sont. Notez que dans Chromium le processus principal (navigateur) est privilégié et ne peut pas être mis en bac à sable.

Historiquement, cette approche du bac à sable mixte a été établie car la disponibilité de Node.js dans le moteur de rendu est un outil extrêmement puissant pour les développeurs d'applications. Malheureusement cette fonctionnalité est également une vulnérabilité de sécurité tout aussi massive.

Théoriquement les rendus hors bac à sable ne sont pas un problème pour les applications de bureau qui affichent uniquement du code de confiance mais ils rendent Electron moins sûr que Chromium pour afficher du contenu Web non fiable. Cependant même du code prétendument fiable peut être dangereux - il existe d’innombrables vecteurs d’attaque utilisables par des acteurs malveillants, du script cross-site à l’injection de contenu aux attaques "man-in-the-middle" sur des sites Web distants chargés pour n’en nommer que quelques-uns. Pour cette raison, nous recommandons d'être très prudent et d’activer le bac à sable pour les rendus dans la grande majorité des cas.

Notez qu'il y a une discussion active dans le gestionnaire de tickets au sujet de l'activation par défaut de la mise en bac à sable des rendus . Voir #28466) pour plus de détails.

Comportement du bac à sable dans Electron

Dans Electron les processus mis en bac à sable se comportent principalement de la même manière qu'avec Chromium mais il y a quelques concepts supplémentaires à considérer puisque Electron s’interface avec Node.js.

Processus de rendu

Lorsque les processus de rendu dans Electron sont en bac à sable, ils se comportent de la même manière qu'un moteur de rendu Chrome régulier le ferait. Un moteur de rendu en bac à sable n'aura pas d'environnement Node.js initialisé.

Par conséquent, lorsque le bac à sable est activé, les processus de rendu ne peuvent effectuer des tâches privilégiées (telles que l’interaction avec le système de fichiers, apporter des modifications au système ou engendrer des sous-processus) qu'en déléguant ces tâches au processus principal par la communication inter-processus (IPC).

Scripts de préchargement (preload)

Afin de permettre aux processus de rendu de communiquer avec le processus principal, les scripts de préchargement attachés aux rendus en bac à sable auront toujours un sous-ensemble polyfill de l'API Node.js disponible. Une fonction require similaire au module require de Node module est exposée mais ne peut importer qu'un sous-ensemble des modules intégrés d'Electron et de Node :

En outre, le script de préchargement simule également certaines primitives Node.js en tant que globales :

Étant donné que la fonction require est un polyfill avec des fonctionnalités limitées, vous ne serez pas en mesure d’utiliser modules CommonJS pour séparer votre script de préchargement en plusieurs fichiers . Si vous avez besoin de diviser votre code de préchargement, utilisez un groupeur de module tel que webpack ou Parcel.

Notez que parce que l’environnement présenté au script preload est sensiblement plus privilégié que celui d’un rendu en bac à sable, il est toujours possible de créer une fuite des API privilégiées vers du code non sécurisé en cours d’exécution dans le processus de rendu à moins que contextIsolationne soit activé.

Configuration du bac à sable

Activation du bac à sable pour un processus unique

Dans Electron, la mise en bac à sable d'un rendu peut être activé au niveau de chaque processus individeullement par la préférence sandbox: true dans le constructeur de la BrowserWindow.

// main.js
app.whenReady().then(() => {
const win = new BrowserWindow({
webPreferences: {
sandbox: true
}
})
win.loadURL('https://google.com')
})

Activation globale du bac à sable

Si vous souhaitez forcer l'activation du bac à sable pour tous les rendus, vous pouvez utiliser l' app.enableSandbox API. Notez que cette API doit être appelée avant l'événement ready de l’application.

// main.js
app.enableSandbox()
app.whenReady().then(() => {
// inutile de passer `sandbox: true` puisque `app.enableSandbox()` a été appelé.
const win = new BrowserWindow()
win.loadURL('https://google.com')
})

Désactivation du bac à sable de Chromium (pour test uniquement)

Vous pouvez également désactiver entièrement le bac à sable de Chromium avec le drapeau CLI --no-sandbox , qui le désactivera pour tous les processus (y compris les processus utilitaires). Nous vous recommandons fortement d'utiliser ce drapeau uniquement à des fins de test, et jamais en production.

Notez que l'option sandbox : true désactivera toujours l'environnement Node.js du moteur de rendu .

Une note sur le rendu de contenu non fiable

Le rendu de contenu non fiable dans Electron est encore un territoire quelque peu inconnu, bien que certaines applications trouvent le succès (par exemple. Beaker Browser). Notre objectif est de nous rapprocher le plus possible de Chrome en termes de sécurité des contenus en bac à sable, mais en fin de compte, nous serons toujours à la traîne en raison de quelques problèmes fondamentaux :

  1. Nous n’avons pas les ressources ou l’expertise dédiées dont Chromium dispose pour appliquer la sécurité à son produit. Nous faisons de notre mieux pour utiliser ce que nous avons, pour hériter de tout ce que nous pouvons de Chromium et pour répondre rapidement aux problèmes de sécurité , mais Electron ne peut pas être aussi sûr que Chromium sans les ressources que Chromium est en mesure de consacrer.
  2. Certaines fonctionnalités de sécurité de Chrome (telles que la navigation sécurisée et la transparence des certificats ) nécessitent une autorité centralisée et des serveurs dédiés, qui vont à l’encontre des objectifs du projet Electron. En tant que tel, nous désactivons ces fonctionnalités dans Electron, au détriment de la sécurité associée qu’elles apporteraient autrement.
  3. Il n'y a qu'un seul Chromium, alors qu'il y a plusieurs milliers d'applications créées sur Electron, qui se comportent tous légèrement différemment. La prise en compte de ces différences peut générer un énorme espace de possibilité, et rendre difficile d'assurer la sécurité de la plate-forme dans des cas d'utilisation inhabituels.
  4. Nous ne pouvons pas transmettre directement les mises à jour de sécurité aux utilisateurs, nous comptons donc sur les fournisseurs d’applications pour mettre à niveau la version d’Electron sous-jacente à leur application afin que mises à jour de sécurité atteignent les utilisateurs.

Alors que nous faisons de notre mieux pour rétroporter les correctifs de sécurité Chromium vers d'anciennes versions d'Electron, nous ne garantissons pas que chaque correctif sera rétroporté. Votre meilleure chance de rester en sécurité est d'être sur la dernière version stable d'Electron.