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.

À partir d'Electron 20, le bac à sable est activé pour les processus de rendu sans aucune configuration supplémentaire. Si vous voulez désactiver le sandbox pour un processus, consultez la section Désactivation du bac à sable pour un seul processus .

Sandbox behavior in 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).

note

Pour plus d'informations sur la communication IPC, consultez La communication inter-processus.

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 disposent dans tous les cas d'un sous-ensemble polyfill de l'API Node.js. 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 :

  • electron (following renderer process modules: contextBridge, crashReporter, ipcRenderer, nativeImage, webFrame, webUtils)
  • events
  • timers
  • url

Les node: imports suivants sont également pris en charge:

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 des 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 puisque 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​

Pour la plupart des applications, le sandboxing est le meilleur choix. Dans les cas d'utilisation incompatibles avec le bac à sable (par exemple, lorsque vous utilisez des modules natifs de node dans le rendu), il est possible de désactiver le bac à sable pour des processus spécifiques. Mais cela s'accompagne bien sur de risques de sécurité et, surtout si du code ou du contenu non fiable est présent dans le processus hors bac à sable.

Désactivation du bac à sable pour un seul processus​

Dans Electron, la mise en bac à sable d'un renderer peut être désactivé par processus en définissant la propriété sandbox: false dans les webPreferencesà l'appel du constructeur de BrowserWindow.

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

La mise en bac à sable est également désactivée chaque fois que l'intégration de Node.js est activée dans le moteur de rendu. Ce qui peut être réalisé via le constructeur de BrowserWindow en définisasant la valeur de nodeIntegration: true.

main.js
app.whenReady().then(() => {
  const win = new BrowserWindow({
    webPreferences: {
      nodeIntegration: 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' API app.enableSandbox. Notez que cette API doit être appelée avant l'événement ready de l’application.

main.js
app.enableSandbox()
app.whenReady().then(() => {
  // any sandbox:false calls are overridden since `app.enableSandbox()` was called.
  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 --no-sandbox du CLI , 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 rencontrent un certain 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és, 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 pouvons garantir que chaque correctif sera rétroporté. Vous aurez plus de chance d'être en sécurité en utilisant la dernière version stable d'Electron.