From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- .../securite/application_security/index.html | 224 ++++++++++ files/fr/archive/b2g_os/securite/index.html | 71 ++++ .../index.html | 89 ++++ .../b2g_os/securite/security_model/index.html | 396 ++++++++++++++++++ .../b2g_os/securite/system_security/index.html | 449 +++++++++++++++++++++ 5 files changed, 1229 insertions(+) create mode 100644 files/fr/archive/b2g_os/securite/application_security/index.html create mode 100644 files/fr/archive/b2g_os/securite/index.html create mode 100644 files/fr/archive/b2g_os/securite/installing_and_updating_applications/index.html create mode 100644 files/fr/archive/b2g_os/securite/security_model/index.html create mode 100644 files/fr/archive/b2g_os/securite/system_security/index.html (limited to 'files/fr/archive/b2g_os/securite') diff --git a/files/fr/archive/b2g_os/securite/application_security/index.html b/files/fr/archive/b2g_os/securite/application_security/index.html new file mode 100644 index 0000000000..07b15909b5 --- /dev/null +++ b/files/fr/archive/b2g_os/securite/application_security/index.html @@ -0,0 +1,224 @@ +--- +title: La sécurité des applications +slug: Archive/B2G_OS/securite/Application_security +tags: + - Apps + - Firefox OS + - Guide + - Mobile + - Security +translation_of: Archive/B2G_OS/Security/Application_security +--- +
+

Cet article explique en détail le modèle de sécurité des applications Firefox OS.

+
+ +

Les contrôles de sécurité d'applications web introduites dans Firefox OS sont les suivants :

+ + + +

Types d'applications

+ +

Firefox OS supporte trois types d'applications : web, privilégiée et certifiée. Le type d'application est déclaré dans le manifeste d'application et indique la liste des permissions que chaque application peut demander.

+ + + +
+

Note : Pour plus de détails sur les différents types d'applications, voir la documentation du manifeste d'application.

+
+ +

Mettre une application à disposition

+ +

Sous Firefox OS, les applications peuvent être mises à disposition de deux façons différentes : hébergées ou empaquetées. Les applications web classiques peuvent être mises à disposition via deux mécanismes, les applications privilégiées et certifiées en revanche doivent être empaquetées.

+ +

Les applications hébergées

+ +

Une application hébergée est constituée uniquement d'un fichier manifeste sur le serveur web du développeur, qui contient un launch_path pour indiquer quelles pages doivent figurer lorsque l'application est lancée. D'un point de vue de la sécurité, les applications hébergées fonctionnent presque comme des sites web normaux. Lorsqu'une application hébergée est chargée, se sont les URL « normales » de ces pages, qui sont chargées. Elles sont chargées depuis le serveur web, ou depuis l'appareil si elles étaient stockées dans un fichier cache.

+ +

Les applications empaquetées

+ +

Une application empaquetée est un application web ayant l'ensemble de ses ressources (HTML, CSS, JavaScript, manifeste et ainsi de suite) contenues dans un fichier zip (les ressources ne sont pas présentes sur un serveur web). Pour plus de détails sur ce format, voir la page sur les applications empaquetées.

+ +

Origine de l'application

+ +

Pour les applications hébergées, l'origine de l'application correspond à l'origine du manifeste de l'application.

+ +

Pour les applications empacketées, l'origine est affectée de façon unique à l'application lors de l'installation. Les applications privilégiées et certifiées peuvent également demander une origine spécifique en spécifiant le paramètre origin dans le fichier manifeste de l'application.

+ +

Installation de l'application

+ +

Les applications sont installées grâce à l'API JavaScript Apps  :

+ + + +

Afin de garantir qu'une application est bien installée comme une application web, il faut s'assurer que le site web ne trompe pas le mécanisme avec un manifeste d'application. Pour cela, on vérifie que le type MIME du manifeste servi est application/x-web-app-manifest+json. Cette restriction est levée lorsque le manifeste de l'application a la même origine que la page demandant l'installation de l'application.

+ +

Mise à jour

+ +

Le processus de mise à jour pour les applications est décrit à la page mise à jour des applications.

+ +

Autorisations

+ +

Les applications peuvent avoir des privilèges supplémentaires par rapport à ceux accordés aux sites web normaux. Par défaut, une application possède les mêmes autorisations qu'une page web normale. Afin d'obtenir des autorisations supplémentaires, il faut tout d'abord lister les autorisations nécessaires dans le manifeste :

+ +

Déclaration de manifeste

+ +

Pour chaque autorisation supplémentaire, le manifeste doit lister cette autorisation ainsi qu'une description lisible de la raison pour laquelle l'application souhaite accéder à cette autorisation. Par exemple, si une application souhaite utiliser l'API de navigator.geolocation, le manifeste devra contenir le fragment suivant :

+ +
"permissions": {
+  "geolocation":{
+    "description": "Required for autocompletion in the share screen",
+  }
+},
+
+ +

Cela permettra à l'application de demander la permission pour utiliser la géolocalisation (de la même manière qu'une page web). Pour plus de détails sur le fichier de manifeste, voir manifeste d'application.

+ +
+

Note : À l'heure actuelle, les descriptions des autorisations ne sont pas affichées : voir le bug 823385.

+
+ +

Accorder les permissions

+ +

Lorsque les autorisations sont demandées dans le manifeste, il y a deux modes pour activer les permissions : la demande ou l'activation par défaut. L'activation par défaut est mise en place grâce au manifeste, sans autre interaction. Les permissions demandées sont affichées lors de la première utilisation et l'utilisateur peut choisir d'autoriser ou non l'API. En général, Firefox OS ne demande les autorisations que si celles-ci ont un impact sur la vie privée et qu'il est pertinent que l'utilisateur sache pourquoi l'API est utilisée. Par exemple, l'application demandera une permission pour accéder aux contacts, mais l'établissement d'une connexion TCP brute est implicitement autorisé car ici, il n'est pas nécessaire que l'utilisateur fournisse son accord. Lorsque les applications sont revues pour être intégrées au Marketplace, l'utilisation des permissions est examinée afin d'assurer la protection des utilisateurs.

+ +

Révoquer les permissions

+ +

À tout moment, les utilisateurs peuvent changer d'avis sur les permissions qui auront été demandées. Pour révoquer une permission, il faut aller dans l'application Paramètres. En revanche, les permissions activées par défaut ne sont pas paramétrables.

+ +

Application web Sandbox

+ +

Stockage des données par application

+ +

Chaque application s'exécute dans une sandbox de façon indépendante, ce qui signifie que toutes les données stockées par une application sont séparées des données stockées par les autres applications. Parmi ces données, on retrouve les cookies, les données locales et les autorisations liées au site.

+ +

A diagram showing three Firefox OS apps all open is separate sandboxes, so none of them can affect each other.

+ +
+
Cela signifie que si l'utilisateur possède deux applications installées, Appli A et Appli B, ces applications ne partageront pas les cookies, les différentes données locales et les autorisations. Ceci s'applique également si ces deux applications ouvrent un <iframe> qui pointe vers la même origine. Par exemple, si Appli A et Appli B ouvrent un <iframe> pointant vers http://www.mozilla.org, elles iront toutes les deux sur ce site, mais ce dernier sera récupéré et servi avec des cookies distincts selon les deux applications.
+ +
 
+
+ +

Ainsi, si l'utilisateur se connecte sur Facebook avec l'Appli A, cela n'aura aucun impact sur l'utilisation de Facebook par l'Appli B. Le cookie de connexion entre Facebook et l'Appli A n'est disponible que pour l'Appli A. Si l'Appli B ouvre un <iframe> pour Facebook, le cookie ne sera pas disponible. C'est pourquoi, quand l'Appli B ouvre Facebook, elle affichera la page de connexion plutôt que le compte de l'utilisateur.

+ +

Une application ne peut en ouvrir une autre

+ +

Cela signifie que les applications ne peuvent pas ouvrir d'autres applications en utilisant les iframes. Si l'application A crée une <iframe> dont le src correspond à l'URL de l'application B, cela n'ouvrira pas l'application B dans l'<iframe>. Cela ouvrira uniquement le site web situé à cet emplacement. Elle n'utilisera aucun des cookies de l'application B et le comportement observé sera le même que si l'application n'était pas installée sur l'appareil de l'utilisateur.

+ +

Cela s'applique également aux applications empaquetées (voir ci-après pour plus d'informations). Si l'application A tente d'ouvrir l'application empaquetée B en utilisant un <iframe> dirigeant vers l'URL app:// de l'application B, celle-ci ne sera pas chargée. Cela provoquera une erreur 404 ou une autre erreur. Que l'application B soit installée ou non, cela échouera car l'application A ne peut pas détecter si l'application B est installée.

+ +
+
La même chose se produit si la frame de plus haut niveau de l'application A est dirigée vers une URL de l'application B. Pour chaque frame, le système connaît l'application ouverte, ainsi, toute tentative d'ouverture de l'application B depuis une frame de l'application A échouera comme décrit précédemment et l'application A ne pourra accéder à aucune des ressources de B.
+ +
 
+
+ +

Les raisons de ce fonctionnement

+ +

Cette approche possède des avantages et des inconvénients. Un des premiers inconvénients est le suivant : si l'utilisateur interagit avec le même site web à travers plusieurs applications, il devra se connecter à toutes les applications. De même, si un site web veut stocker des données localement et que l'utilisateur interagit avec ce site web parmi les différentes applications, les données vont ainsi se dupliquer pour chaque application. Cela peut poser problème lorsque le volume de données devient conséquent.

+ +
+
Le principal avantage de cette approche est qu'il s'agit d'un modèle plus stable. Il est impossible que plusieurs applications interagissent les unes avec les autres par un site tiers de manière inattendue. Par exemple, l'installation d'une application ne peut pas empêcher le fonctionnement d'une autre application. Quand une application est désinstallée, les données utilisées par une autre application ne peuvent pas être supprimées. De même, la désinstallation d'une application ne pourra poser aucun problème de dépendance pour une autre application.
+ +
 
+ +

Cela permet aussi de bénéficier d'une meilleure sécurité. Un utilisateur peut ainsi utiliser son application SuperRéseauSocial pour se connecter à Facebook sans se soucier du fait que l'application DessineMoiUnMouton puisse exploiter des données tierces grâce à d'éventuelles failles du site.

+
+ +

Cela permet aussi de bénéficier de certains avantages en ce qui concerne la vie privée. L'utilisateur peut ainsi installer l'application MonPartiPolitique en toute sécurité sans se soucier du fait que MonAppliProfessionnelle puisse détecter les nouvelles données.

+ +

Isolement des permissions

+ +
+
De façon analogue aux données, les permissions sont isolées les unes des autres. Ainsi si l'application A charge une page de http://maps.google.com et demande à l'utilisateur la permission d'utiliser la géolocalisation, que l'utilisateur autorise la page et choisit « oui, se souvenir de cette décision », cela signifie seulement que http: //maps.google com aura accès à la géolocalisation depuis l'application A. Si l'application B utilise la page http://maps.google.com, cette page n'aura pas accès à la géolocalisation sauf si l'utilisateur accorde à nouveau la permission.
+ +
 
+
+ +
+
De façon semblable au navigateur, les permissions sont isolées selon l'origine. Si l'application A est autorisée à utiliser l'API Geolocation, cela ne signifie pas que toutes les origines présentes dans l'application A pourront utiliser l'API. Par exemple, si l'application A ouvre une <iframe> vers http://maps.google.com, alors http://docs.google.com devra demander la permission à l'utilisateur pour pouvoir utiliser l'API de géolocalisation.
+ +
 
+
+ +

Sandbox pour l'API Browser

+ +

Pour sécuriser les applications qui ouvrent un grand nombre d'URL, comme les navigateurs, nous avons ajouté un indicateur (flag) browserContentL'indicateur browserContent permet à chaque application d'avoir non pas un, mais deux bacs à sable (sandboxes) : un pour l'application elle-même et l'autre pour tout le contenu web ouvert par l'application.

+ +

Par exemple, si l'application monNavigateur est chargée depuis https://monnavigateur.com, les scripts et ressources seront chargées dans ce bac à sable, ils appartiennent à ce domaine.

+ +

Ensuite, si une page de l'application crée un <iframe mozbrowser>, une sandbox différente sera créée et utilisée pour cette <iframe>. Cette sandbox sera différente de la première. Ainsi, si cet <iframe> dirige vers https://monnavigateur.com, cela se traduira par l'utilisation d'autres cookies pour cet <iframe mozbrowser>. De même, le contenu à l'intérieur de la <iframe mozbrowser> verra des données locales différentes de celles correspondant à l'application.

+ +

Ceci s'appliquera également si l'application monNavigateur souhaite intégrer des fonctionnalités de Google Maps pour proposer des outils de navigation basés sur la géolocalisation. Ainsi, si l'application ouvre un <iframe> vers http://maps.google.com, il recevra un ensemble de cookies pour http://maps.google.com. Si l'utilisateur navigue alors à l'intérieur du <iframe mozbrowser> contenant http://maps.google.com, cela utilisera différents cookies et d'autres autorisations au niveau le plus haut de l'application.

+ +

Voici un autre scénario où cela peut être utile : l'application Yelp. Cette application permet d'ouvrir différents sites Internet de restaurants. En utilisant <iframe mozbrowser>, afin d'ouvrir le site du restaurant, l'application Yelp s'assure que le site web du restaurant ne contiendra pas d'<iframe> pointant vers l'application Yelp. En effet, si le site du restaurant pointe d'une certaine façon vers http://yelp.com, il « verra » le site web Yelp plutôt que l'application. Ainsi, il est théoriquement impossible que le site du restaurant attaque les données de l'application Yelp.

+ +

Résumé sur la sécurité des applications

+ +
+
Le tableau ci-dessous résume les différents types d'applications de Firefox OS et décrit le format, l'installation et les processus de mise à jour pour les applications web fonctionnant sur Firefox OS.
+ +
 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Les types d'application web
TypeMise à dispositionModèle d'autorisationsInstallationMise à jour
WebHébergée ou empaquetéeLes permissions les moins sensibles qui ont le moins d'impact lorsqu'un contenu web non autorisé est exposéPeut être installée depuis n'importe où +
+
Peut être mis à jour de façon transparente pour l'utilisateur ou explicitement grâce au Marketplace, en fonction de l'emplacement où l'application a été installée et du mécanisme de livraison
+
+
PrivilégiéEmpaquetée ou signéeLes API privilégiées ont besoin d'une validation et d'une authentification de l'applicationDoit être installée depuis le MarketplaceMise à jour via un Marketplace de confiance, l'utilisateur est invité à approuver le téléchargement et l'installation des mises à jour
CertifiéEmpaquetée +
+
Les API puissantes et dangereuses ne sont pas disponibles pour les applications tierces
+
+
L'application est préinstallée sur l'appareilMise à jour uniquement dans le cadre des mises à jour du système
+ +
+

Note : Pour la version 1.0 de Firefox OS, bien que les applications web puissent être installées depuis n'importe quel site ou Marketplace, certaines applications privilégiées ne peuvent être installées que depuis le Marketplace de Mozilla. La gestion des autres Marketplace de confiance n'est pas encore finalisée.

+
+ +

 

diff --git a/files/fr/archive/b2g_os/securite/index.html b/files/fr/archive/b2g_os/securite/index.html new file mode 100644 index 0000000000..d57b968b65 --- /dev/null +++ b/files/fr/archive/b2g_os/securite/index.html @@ -0,0 +1,71 @@ +--- +title: Sécurité dans Firefox OS +slug: Archive/B2G_OS/securite +tags: + - Firefox OS + - Mobile + - Sécurité +translation_of: Archive/B2G_OS/Security +--- +

Les articles suivants sont relatifs à la sécurité de Firefox OS. Ceci inclut les fonctionnalités de sécurité liées au système, la sécurité des applications, les processus d'installation d'applications sécurisés...

+ + + + + + + + +
+

Documentation à propos de la sécurité dans Firefox OS

+ +
+
Le modèle de sécurité de Firefox OS
+
Un aperçu du modèle de sécurité de Firefox OS.
+
Sécurité du système
+
Détails des mécanismes de sécurité directement inclus dans Firefox OS.
+
Sécurité des applications dans Firefox OS
+
Un aperçu de la manière dont les applications sont sécurisées dans Firefox OS.
+
Installation et mise à jour sécurisée des applications
+
Comment Firefox OS installe et met à jour les applications de manière sécurisée.
+
Permissions logicielles dans Firefox OS
+
Un guide expliquant quelles sont les permissions requises par différents types d'applications pour qu'elles puissent réaliser certaines tâches.
+
 Déboguer et tester la sécurité avec Firefox OS
+
Ce guide vous montre les étapes basiques du test de la sécurité. De l'ouverture d'un débogueur JavaScript à distance pour mettre en place un proxy d'interception HTTP(S) contre une version ordinateur de Firefox OS.
+
+ +

Voir tout...

+
+

Obtenir de l'aide de la communauté

+ +

Si vous travaillez avec Firefox OS ou développez des applications que vous aimeriez voir fonctionner sur des appareils Firefox OS, des ressources communautaires sont à votre disposition !

+ + + +
    +
  • Posez votre question sur le canal IRC de Mozilla : #b2g
  • +
+ +

N'oubliez pas la netiquette pour poser vos questions…

+ + + + + +
+ +

 

+ +

+Firefox OS
diff --git a/files/fr/archive/b2g_os/securite/installing_and_updating_applications/index.html b/files/fr/archive/b2g_os/securite/installing_and_updating_applications/index.html new file mode 100644 index 0000000000..e133d1e6d2 --- /dev/null +++ b/files/fr/archive/b2g_os/securite/installing_and_updating_applications/index.html @@ -0,0 +1,89 @@ +--- +title: Installation et mise à jour d'applications +slug: Archive/B2G_OS/securite/Installing_and_updating_applications +tags: + - Apps + - Firefox OS + - Guide + - Installation + - Mise à jour +translation_of: Archive/B2G_OS/Security/Installing_and_updating_applications +--- +
+

Cet article constitue un guide sur le processus de mise à jour des application Firefox OS.

+
+ +

Vue d'ensemble de l'implémentation

+ +

Types d'applications

+ +

Il existe de base trois catégories d'applications qui peuvent être mises à jour en utilisant ce mécanisme :

+ +
+
Applications centrales
+
Les applications centrales (celles qui sont livrées comme faisant partie du système Firefox OS de base, comme Téléphone) sont empaquetées, certifiées, pré-installées et non supprimables. Elles ne peuvent être mises à jour que lors de la mise à niveau du système complet ou d'une mise à jour des couches Gonk et Gaia.
+
Applications installées par l'utilisateur
+
Les applications installées par l'utilisateur sont soit empaquetées, soit hébergées. La politique de mise à jour est le principal sujet de cet article.
+
Applications tierces pré-installées
+
Ces applications sont pré-installées par l'opérateur ou le fabricant, mais ne font pas partie du cœur du système d'exploitation de la plate-forme. Leur mise à jour est soumise aux mêmes règles et conventions que pour les applications installées par l'utilisateur.
+
+ +

Suppositions concernant les utilisateurs

+ +

Pour au moins les premières versions de Firefox OS, les hypothèses suivantes sont prises en compte à propos des utilisateurs :

+ + + +

Toutes ces conditions utilisateurs sont répandues dans beaucoup de pays, il paraît donc juste de faire de telles hypothèses. Notre objectif est d'essayer d'optimiser l'expérience utilisateur lors des mises à jour pour les personnes concernées par celles-ci. En général, ces suppositions n'auront pas d'impact négatif sur les utilisateurs qui disposent d'un accès WiFi rapide et pas cher.

+ +

Paramètres de conception technique

+ +

Cette section aborde quelques principes de conception pour l'implémentation des mises à jour d'applications dans Firefox OS :

+ + + +

Considérations pour les développeurs

+ +

Il y a plusieurs choses dont les développeurs doivent prendre en considération, compte-tenu du modèle de mise à jour des applications :

+ + + +

Expérience utilisateur

+ +

Principes de conception

+ +

Afin de bénéficier de la meilleure expérience utilisateur possible lors de la mise à jour des applications, quelques principes essentiels doivent être gardés à l'esprit :

+ + + +

Types de mises à jour

+ +

Il existe trois types basiques de mise à jour :

+ +
+
Manuel : individuel
+
Une mise à jour d'une unique application, à l'initiative de l'utilisateur
+
Manuel : lot
+
Une mise à jour de plusieurs applications en une seule fois, à l'initiative de l'utilisateur
+
Silencieuse
+
Une mise à jour en arrière-plan, automatisée
+
diff --git a/files/fr/archive/b2g_os/securite/security_model/index.html b/files/fr/archive/b2g_os/securite/security_model/index.html new file mode 100644 index 0000000000..77e0212528 --- /dev/null +++ b/files/fr/archive/b2g_os/securite/security_model/index.html @@ -0,0 +1,396 @@ +--- +title: Présentation de la sécurité de Firefox OS +slug: Archive/B2G_OS/securite/Security_model +translation_of: Archive/B2G_OS/Security/Security_model +--- +
+

Ce document donne un aperçu du cadre de la sécurité de Mozilla Firefox OS, qui est conçu pour protéger les appareils mobiles contre les menaces de la plateforme, des applications et des données. Dans le Firefox OS, Mozilla a mis en place un modèle de sécurité globale, intégrée et multicouche qui offre une protection best-of-breed contre les risques de sécurité pour les téléphones mobiles.

+
+ +

Sécurité de la plate-forme

+ +

La plate-forme Firefox OS utilise un modèle de sécurité multi-couches qui est conçu pour atténuer les risques d'exploitation à tous les niveaux. Une première ligne de contre-mesures combinée avec une stratégie de sécurité en profondeur offrent une protection complète contre les menaces.

+ +

L'architecture sécurisée

+ +

Le système d'exploitation Firefox OS connecte des applications Web au matériel sous-jacent. C'est une technologie de pile intégrée, composée des niveaux suivants:

+ +

+ + + +

Gecko est le contrôleur d'accès qui applique les politiques de sécurité destinées à protéger l'appareil mobile d'une mauvaise utilisation. La couche Gecko agit comme intermédiaire entre les applications web (à la couche Gaia) et le téléphone. Gonk offre des caractéristiques du matériel du téléphone mobile sous-jacent directement à la couche Gecko. Les applications Web accèdent à des fonctionnalités du téléphone mobile uniquement via les API Web, et seulement si Gecko permet la demande d'accès il n'y a pas d'accès direct, pas de «porte arrière» dans le téléphone. Gecko applique des autorisations et empêche l'accès aux demandes non autorisées.

+ +

le déploiement du système

+ +

Firefox OS est livré installé sur un téléphone intelligent. L'image du système d'origine est créée par une source de confiance connuehabituellement le OEM (Original Equipment Manufacturer) de l'appareil qui est responsable de l'assemblage, la construction, les tests et la signature numérique de l'emballage de distribution.

+ +

Les mesures de sécurité sont utilisées dans la pile de technologie. Les privilèges du système de fichiers sont appliqués par les listes de contrôle d'accès de Linux (les ACL). Les applications du système sont installées sur un support de stockage qui est en lecture seule (sauf pendant les mises à jour, quand il est temporairement en lecture-écriture); généralement il n'y a que les zones contenant le contenu de l'utilisateur qui peuvent être en lecture-écriture. Divers composants dans le matériel de l'appareil sont équipés de protections qui sont mises en œuvre par défaut en tant que pratique standard de l'industrie - les fabricants de puces, par exemple, employent des techniques de durcissement pour réduire les vulnérabilités. La plate-forme de base (Gecko et Gonk) est durcie pour renforcer sa défense contre les menaces potentielles, et les caractéristiques de durcissement du compilateur sont utilisées le cas échéant. Pour plus de détails, voir Runtime security.

+ +

Mises à jour de Système Sécurisé

+ +

Les mises à jour ultérieures et les correctifs de la plate-forme Firefox OS sont déployés en utilisant un processus Mozilla sécurisé qui garantit l'intégrité continue de l'image du système sur le téléphone mobile. La mise à jour est créée par une entité connue, une source de confiance - habituellement le OEM de l'appareil - qui est responsable de l'assemblage, la construction, les tests et la signature numérique du paquet de mise à jour.

+ +

Les mises à jour du système peuvent concerner tout ou une partie de la pile Firefox OS. Si des changements à Gonk sont inclus dans la mise à jour, cependant FOTA (Firmware Over The Air) est le processus d'installation utilisé. Les mises à jour FOTA peuvent également inclure toute autre partie de la pile de Firefox OS, y compris la gestion de l'appareil (FOTA, firmware / drivers), la gestion des paramètres (paramètres de Firefox OS), les mises à jour de sécurité, Gaia, Gecko, et d'autres correctifs.

+ +

Les mises à jour qui ne comportent pas Gonk peuvent être effectuées en utilisant la mise à jour de l'utilitaire système Mozilla. Firefox OS utilise le même framework de mise à jour, les mêmes processus et le même format Mozilla ARCHIVE (MAR) (utilisé pour les packages de mise à jour) que le produit Firefox Desktop.

+ +

Un service intégré dans la mise à jour — lequel peut être fourni par le fabricant  sur le téléphone mobile vérifie périodiquement les mises à jour système. Une fois un paquet système devient disponible et est détecté par le service de mise à jour, l'utilisateur est invité à confirmer l'installation. Avant que les mises à jour soient installées sur l'appareil mobile, le stockage de l'appareil est vérifié pour un espace suffisant pour appliquer la mise à jour, et la distribution est vérifiée pour:

+ + + +

Les mesures de sécurité suivantes sont utilisées au cours du processus de mise à jour:

+ + + +

Des contrôles rigoureux sont en mis place pour veiller à ce que la mise à jour est appliquée correctement sur le téléphone mobile.

+ +
+

Note: Pour plus d'informations sur la façon dont les mises à jour fonctionnent et comment créer et distribuer des mises à jour, lire Création et application des paquets de mise à jour de Firefox OS.

+
+ +

Securité des applications

+ +

Firefox OS utilise une stratégie de sécurité de défense en profondeur pour protéger le téléphone mobile des applications intrusives ou malveillantes. Cette stratégie utilise une variété de mécanismes, y compris les niveaux d'autorisation implicites basés sur un modèle de confiance de l'application, l'exécution en sandbox au moment de l'exécution, d'un accès au matériel sous-jacent du téléphone mobile uniquement par API, un modèle d'autorisation robuste, et les processus d'installation et de mise à jour sécurisé. Pour les détails techniques, faire référence à Application security.

+ +

Dans Firefox OS, toutes les applications sont des applications Web - programmes écrits en utilisant HTML5, JavaScript, CSS, les médias, et d'autres technologies Web ouvertes (les pages en cours d'exécution dans le navigateur ne sont pas visées; que les applications Web dans ce contexte). Parce qu'il n'y a d'application binaires  («natives») installées par l'utilisateur, tous les accès au système sont strictement effectués via les API Web. Même l'accès au système de fichiers ne se produit que par le biais des API Web et une base de données SQLite back-end - il n'y a pas d'accès direct entre les applications et les fichiers stockés sur la carte SD.

+ +

Firefox OS limite et fait respecter la portée des ressources qui peuvent être consultées ou utilisées par une application, tout en soutenant un large éventail d'applications avec différents niveaux d'autorisationMozilla a mis en place un contrôle serré sur ce type d'applications qui peuvent accéder aux API. Par exemple, seules les applications certifiées (livrées avec le téléphone) peuvent avoir accès à l'API de téléphonie.

+ +

Cela empêche une situation, par exemple, dans laquelle une application arbitraire tiers est installée, compose un numéro de téléphone pay-per-use (900 et 910), et engrange une grosse facture de téléphone cellulaire.

+ +

D'autres applications OEM pourraient cependant être sélectionnées pour avoir accès à l'API de téléphonie. Par exemple, un opérateur pourrait fournir une application de systèmes de gestion qui permet à un client de gérer sont compte, y compris la possibilité de téléphoner au service client ou le service d'aide de l'opérateur directement.

+ +

 

+ +

Applications approuvées et non approuvées

+ +

 

+ +

Firefox OS catégorise les applications selon les types suivants:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeNiveau de confianceDescription
CertifiéTrès fiableLes applications du système qui ont été approuvées par l'opérateur ou l'OEM (en raison de risques de corruption de l'appareil ou un risque pour la fonctionnalité critique). Les applications et services système uniquement; non destinées à des applications tierces.
+ Cette désignation est réservée à un petit nombre d'applications critiques. Exemples: SMS, Bluetooth, appareil photo, horloge système, la téléphonie et le numéroteur par défaut (pour que les services d'urgence soient toujours accessibles).
PrivilégiéFiableDes applications tierces qui ont été examinées, approuvées et signées numériquement par un marché autorisé.
Web (tout le reste)appliqueNon fiableContenu Web régulier. Comprend les applications installées (stockées sur le téléphone mobile) et des applications hébergées (stockées à distance, avec seulement une application manifeste stockée sur le téléphone mobile). Le manifeste pour les applications hébergées peut être obtenu grâce à un marché.
+ +

Le niveau de confiance d'une application détermine, en partie, sa capacité à accéder aux fonctionnalités de téléphone mobile.

+ + + +

Certaines opérations, telles que l'accès au réseau, sont supposées être une autorisation implicite pour toutes les applications. En général, plus l'opération est sensible (par exemple, composer un numéro de téléphone ou accéder à la liste de contacts), plus le niveau de confiance de l'application nécessaire pour l'exécuter est élevé.

+ +
+

Remarque: pour plus d'informations sur les API disponibles et leurs niveaux d'autorisation, consulter App permissions.

+
+ +

Principe de la Moindre partie de Permissions

+ +

Pour les applications Web, le framework de sécurité de Firefox OS suit le principe des moindres autorisations: commencer avec les autorisations minimales absolues, puis accorder sélectivement des privilèges supplémentaires que lorsque cela est nécessaire et raisonnable. Par défaut, une application commence avec de très faibles autorisations, ce qui est comparable au contenu Web non sécurisé. Si l'application effectue des appels API Web qui nécessitent des autorisations supplémentaires, il doit énumérer ces autorisations supplémentaires dans son manifeste (décrit plus loin dans ce document). Gecko envisagera d'accorder l'accès de l'API Web à une application que si les privilèges applicables sont priés explicitement dans son manifeste. Gecko accordera l'autorisation demandée uniquement si le type de l'application Web (certifiée, confiance, ou Web) est suffisamment qualifié pour l'accès.

+ +

Processus d'Examen pour Applications Privilégiés dans le Marché

+ +

Pour qu'une application devienne privilégée, le fournisseur de l'application doit la soumettre pour examen sur le Marketplace. Le Marketplace soumet l'application dans un processus de révision du code rigoureux: vérification de son authenticité et de l'intégrité, veiller à ce que les autorisations demandées sont utilisées aux fins indiquées (dans la justification de l'autorisation), vérifier que l'utilisation des autorisations implicites est appropriée, et de valider que toutes les interfaces entre le contenu de l'application privilégiée et contenu externe non privilégié ont les mesures d'atténuation appropriées pour prévenir des attaques d'élévation de privilèges. Le Marketplace a la responsabilité de veiller à ce que l'application web ne se comportera pas malicieusement avec les autorisations qu'il est accordée.

+ +

Après q'une application est passé cet examen, elle est approuvée pour utilisation, le manifeste de l'application est signé numériquement par le Marketplace, et il est disponible pour les utilisateurs mobiles. La signature garantit que, si la boutique en ligne a été en quelque sorte piratée, le pirate ne pouvait pas sortir avec l'installation de contenu arbitraire ou du code malveillant sur les téléphones des utilisateurs. En raison de ce processus de vérification, Firefox OS donne des applications privilégiées obtenues à partir du Marketplace un plus haut degré de confiance tous les jours que de contenu Web.

+ +

 

+ +
+

Remarque: pour en savoir plus à propos de Marketplace, y compris le marché de Firefox, aller à la zone du Marketplace.

+
+ +

 

+ +

Applications empaquetées et hébergées

+ +

Les applications pour Firefox OS peuvent être soit empaquetées (stockées sur le téléphone mobile) ou hébergées (stockées sur un serveur web distant, avec juste un manifeste stocké sur le téléphone mobile). Il ya quelques différences dans la façon dont la sécurité est gérée pour chaque. Néanmoins, les applications empaquetées et hébergées sont toutes deux soumises à l'application sandboxing, qui est décrite plus loin dans ce document.

+ +
+

Note: Vous pouvez en savoir plus sur les applications hébergées et empaquetées à Auto-publication d'application

+
+ +

Applications empaquetées

+ +

Une application empaquetée se compose d'un fichier ZIP contenant des ressources d'application (HTML5, CSS, Javascript, images, médias), ainsi que d'un manifeste qui fournit une liste explicite des actifs et leurs valeurs de hachage correspondant. Applications certifiées et privilégiées doivent être empaquetées parce que le manifeste de l'application doit être signé numériquement. Quand un utilisateur obtient une application incluse dans le paquet, le fichier ZIP téléchargé sur le téléphone mobile, et le manifeste est lu à partir d'un emplacement connu à l'intérieur du fichier ZIP. Pendant le processus d'installation, les actifs d'applications sont dignes de confiance et restent stockés localement dans le paquet. Toutes les autorisations explicites sont demandées lors de l'exécution, montrant à l'utilisateur les intentions d'utilisation des données de l'application, et sont persistées par défaut.

+ +

Pour faire référence à des ressources d'applications dans une application empaquetée, l'URL commence par app: en utilisant le format suivant:

+ +

app://identifier/path_within_zipfile/file.html

+ +

où app:// représente le point de montage du fichier ZIP, et l'identifiant est un UUID qui est généré lorsque l'application est installée sur le téléphone mobile. Ce mécanisme garantit que les ressources appelées avec app:URL contenues dans le fichier ZIP. Le chemin au sein d'une app: est relative, donc des liens relatifs à des ressources dans le fichier ZIP sont autorisés.

+ +

Alors que les applications empaquetées sont principalement destinées à être utilisées pour les applications certifiées ou privilégiées, les applications web régulières peuvent aussi être empaquetées. Cependant, elles ne gagnent pas d'augmentation de l'accès en confiance ou autorisations simplement parce qu'elles sont empaquetées.

+ +

Applications hébergées

+ +

Les applications hébergées sont situées sur un serveur Web et chargées via HTTP. Seulement le manifeste de l'application est stocké sur le téléphone mobile. Tout le reste est stocké à distance. Certaines APIs sont disponibles uniquement aux applications privilégiées et certifiées, ce qui nécessite que l'application soit empaquetée en raison des exigences de signature. Par conséquent, une application hébergée n'aura pas accès à l'une des API Web qui nécessitent un statut d'application privilégiée ou certifiée.

+ +

Du point de vue de la sécurité, des applications hébergées fonctionnent très bien comme des sites Web normaux. Une application hébergée est chargée en invoquant un codage en dur, URL pleinement qualifiée qui pointe vers la page de démarrage dans le répertoire racine de l'application sur le serveur Web. Une fois une application hébergée est chargée, le téléphone mobile pointe vers des pages en utilisant les mêmes URL qui sont utilisées lors de la navigation sur le site web.

+ +

Manifeste d'une Application

+ +

Le manifeste d'une application Open Web contient des informations dont le navigateur Web a besoin pour interagir avec une application. Un manifeste est un fichier JSON avec (au moins) un nom et une description pour l'application. Pour plus de détails, reportez-vous à FAQs about app manifests.

+ +

Exemple de Manifeste

+ +

Les lignes de code suivantes montrent un exemple de manifeste avec les réglages de base seulement:

+ +
{
+  "name": "My App",
+  "description": "My elevator pitch goes here",
+  "launch_path": "/",
+  "icons": {
+    "128": "/img/icon-128.png"
+  },
+  "developer": {
+    "name": "Your name or organization",
+    "url": "http://your-homepage-here.org"
+  },
+  "default_locale": "en"
+}
+ +

Paramètres de sécurité dans le Manifeste de l'Application

+ +

Le manifeste peut également contenir d'autres paramètres, y compris les paramètres de sécurité suivants:

+ +

 

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Champs

+
+

Description

+
+

permissions

+
+

Permissions requises par l'application. Une application doit énumérer toutes les API Web qu'elle entend utiliser qui nécessite l'autorisation de l'utilisateur. La plupart des autorisations ont du sens pour les applications privilégiées ou des applications certifiées, mais pas pour les applications hébergées. Propriétés par API:

+ +
    +
  • Description: Une chaîne spécifiant l'intention derrière la demande d'utilisation de cette API. Requis
  • +
  • Accès: Une chaîne spécifiant le type d'accès requis pour l'autorisation. Les autorisations implicites sont accordées lors de l'installation. Requis pour seulement quelques API. Les valeurs acceptées: read, readwrite, readcreate, et createonly.
  • +
+
+

installs_allowed_from

+
+

L'origine de l'application; peut être au singulier ou un tableau des origines (scheme+unique hostname) qui sont autorisés à déclencher l'installation de cette application. Permet aux fournisseurs d'applications de restreindre les installations à partir de seulement l'autorisation du Marketplace (https://marketplace.firefox.com/).

+
+

csp

+
+

Content Security Policy (CSP). Appliquée à toutes les pages chargées dans l'application. Utilisé pour durcir l'application contre les bugs qui pourraient permettre à un attaquant d'injecter du code dans l'application. Si non spécifié, les applications privilégiées et certifiées ont des réglages système par défaut. Syntaxe:
+ https://developer.mozilla.org/en-US/docs/Apps/Manifest#csp

+ +

Notez que cette directive ne peut augmenter le CSP appliqué. Vous ne pouvez pas l'utiliser, par exemple, de réduire le CSP appliqué à une application privilégiée.

+
+

type

+
+

Type d'application (web, privilegiée, or certifiée).

+
+ +

 

+ +

Firefox OS exige que le manifeste soit servi avec un type mime spécifique (application / x-web-app-manifeste + JSON) et à partir du même nom d'hôte pleinement qualifié (origine) à partir de laquelle l'application est servie. Cette restriction est assouplie lorsque l'application manifeste (et donc l'application manifeste) est de la même origine avec la page qui a demandé l'application à installer. Ce mécanisme est utilisé pour assurer qu'il est impossible de tromper un site Web en accueillant un manifeste d'application.

+ +

 

+ +

Exécution sandbox

+ +

 

+ +

Cette section décrit l'application et l'exécution sandboxes.

+ +

Application Sandbox

+ +

Le framework de sécurité de Firefox OS utilise sandboxing comme une stratégie de défense en profondeur pour atténuer les risques et protéger le téléphone mobile, la plate-forme, et les données. Sandboxing est une façon de mettre les frontières et les restrictions autour d'une application en cours d'exécution. Chaque application fonctionne dans son propre espace de travail et a uniquement accès aux API Web et les données dont elle a l'accès, ainsi que les ressources associées à cet espace de travail (bases de données IndexedDB, biscuits, stockage en mode déconnecté, et ainsi de suite).

+ +

La figure suivante donne un aperçu de ce modèle de sécurité.

+ +

 

+ +

 

+ +

+ +

 

+ +

En isolant chaque application, son impact est contenue dans son propre espace de travail et ne peut pas interférer avec quoi que ce soit (comme d'autres applications ou leurs données) en dehors de cet espace de travail.

+ +

Execution Sandbox

+ +

B2G (Gecko) s'exécute dans un processus de système hautement privilégiée qui a accès à des fonctionnalités matérielles dans le téléphone mobile. A l'exécution, chaque application fonctionne à l'intérieur d'un environnement d'exécution qui est un processus enfant du processus système de B2G. Chaque processus enfant a un ensemble restreint de privilège OS - par exemple, un processus enfant ne peut pas lire ou écrire des fichiers arbitraires sur le système de fichiers directement. Un accès privilégié est fourni via des API Web, qui sont médiées par le processus B2G mère. Le parent s'assure que, quand un processus enfant demande une API privilégiée, il dispose de l'autorisation nécessaire pour effectuer cette action.

+ +

Les applications communiquent uniquement avec le processus de base B2G, pas avec d'autres processus ou applications. Les applications ne fonctionnent pas indépendamment de B2G, ne peuvent ouvrir des applications de l'autre. La seule «communication» entre les applications est indirecte (par exemple, quand une application établit une alarme système et une autre application déclenche une notification du système à la suite de celui-ci), et est médiée par le processus B2G.

+ +

Hardware Access Only via the Web API

+ +

 

+ +

Les applications Web ont un seul point d'entrée pour accéder aux fonctionnalités de téléphonie mobile: les API Web de Firefox OS, qui sont mises en œuvre dans Gecko. Gecko fournit la seule porte d'entrée de l'appareil mobile et les services sous-jacents. La seule façon d'accéder à la fonctionnalité matérielle du périphérique est de faire un appel d'API Web. Il n'y a aucune API "native" et il n'y a pas d'autres façons (pas de «portes arrières") pour contourner ce mécanisme et d'interagir directement avec le matériel ou pénétrer dans la couche logicielle de bas niveau.

+ +

 

+ +

Infrastructure de sécurité

+ +

La figure suivante montre les composantes du framework de sécurité de Firefox OS:

+ +

+ + + +

Gestion des autorisations et mise en application

+ +

La sécurité de Firefox OS est conçue pour vérifier et appliquer les autorisations accordées à des applications web.

+ +

Le système accorde une autorisation particulière à une application que si le contenu lui demande, et seulement si elle a les autorisations appropriées demandées dans le manifeste de l'application. Certaines autorisations exigent en outre l'autorisation de l'utilisateur, qui est invité à accorder l'autorisation (comme dans le cas d'une application demandant l'accès à l'emplacement actuel de l'utilisateur). Ce framework app-centrique fournit un contrôle plus granulaire sur les autorisations que les approches de rôle centré traditionnelles (dont les rôles individuels sont affectés chacun un ensemble d'autorisations).

+ +

Une API Web a donné un ensemble d'actions et d'écouteurs. Chaque API Web a un niveau d'autorisation requis. Chaque fois une API Web est appelé, Gecko vérifie les exigences d'autorisation (rôle de consultation) basées sur:

+ + + +

Si la demande ne satisfait pas aux critères d'autorisation, alors Gecko rejette la demande. Par exemple, des applications non approuvées ne peuvent pas exécuter des API Web qui sont réservées pour des applications de confiance.

+ +

Inviter les utilisateurs pour Permissions

+ +

En plus des autorisations qui sont implicitement associées aux applications web, certaines opérations nécessitent l'autorisation explicite de l'utilisateur avant de pouvoir être exécutées (par exemple, "l'application web peut avoir accès à votre appareil photo?"). Pour ces opérations, les applications web sont tenues de spécifier, dans leur manifeste, leur justification pour exiger cette autorisation. Cette intention d'utilisation des données informe les utilisateurs sur ce que l'application Web a l'intention de faire avec ces données si l'autorisation est accordée, ainsi que tout risque impliqué. Cela permet aux utilisateurs de prendre des décisions éclairées et de garder le contrôle sur leurs données.

+ +

Processus de mise à jour sécurisé d'une Application

+ +

 

+ +

+ +

Pour les mises à niveau d'applications et des correctifs à une application privilégiée, les fournisseurs d'applications soumettent l'archive mis à jour pour l'autorisation du Marketplace, où elle est examinée et, si elle est approuvée, signée et mise à la disposition des utilisateurs. Sur les appareils OS Firefox, une application utilitaire de une mise à jour  vérifie périodiquement des mises à jour de l'application. Si une mise à jour est disponible, l'utilisateur est alors interroger s'ils veulent l'installer. Avant qu'une mise à jour soit installée sur l'appareil mobile, le paquet est vérifié:

+ + + +

Des contrôles rigoureux sont mises en place pour veiller à ce que la mise à jour soit appliquée correctement sur le téléphone mobile. Le package de mise à jour complète doit être téléchargé dans un emplacement spécifique et sécurisé avant le début du processus de mise à jour. L'installation ne remplace pas les données des utilisateurs.

+ +
+

NotePour plus d'informations sur les mises à jour d'applications, lisez Updating apps.

+
+ +

Securité de l'appareil (Hardware)

+ +

Les mécanismes de sécurité pour le matériel de l'appareil mobile sont généralement traitées par l'OEM. Par exemple, un OEM peut offrir une SIM (Subscriber Identity Module) serrures à carte, avec PUK (PIN Unlock Key) codes pour débloquer les cartes SIM qui sont devenus verrouillé les entrées suivantes de code PIN erroné. Contactez votre OEM pour plus de détails. Firefox OS ne permettent aux utilisateurs de configurer des codes d'accès et les écrans de délai d'attente, qui sont décrits dans la section suivante.

+ +

Sécurité des données

+ +

Les utilisateurs peuvent stocker des données personnelles sur leur téléphone qu'ils veulent garder privées, y compris les contacts, les informations financières (bancaires et les détails de cartes de crédit), les mots de passe, des calendriers, et ainsi de suite. Firefox OS est conçu pour protéger contre les applications malveillantes qui peuvent voler, exploiter, ou de détruire des données sensibles.

+ +

Code d'accès et Ecran de temporisation

+ +

Firefox OS permet aux utilisateurs de définir un code d'accès à leur téléphone mobile afin que ceux qui fournissent le code d'accès puissent utiliser le téléphone. Firefox OS fournit également un écran de temporisation qui est affiché après une période d'inactivité configurable depuis le téléphone , nécessitant une authentification de mot de passe avant de reprendre l'utilisation du téléphone.

+ +

Données sandbox

+ +

Comme décrit précédemment, les applications sont sandbox à l'exécution. Cela empêche les applications d'accéder aux données qui appartient à d'autres applications à moins que les données soient explicitement partagées, et que l'application dispose des autorisations suffisantes pour y accéder.

+ +

Données sérialisées

+ +

Les applications Web n'ont pas un accès direct en lecture et écriture au système de fichiers. Au lieu de cela, tous les accès au stockage se produisent uniquement via les API Web. Les API Web lisent à partir, et écrivent sur, le stockage via une base de données SQLite intermédiaire. Il n'y a pas d'accès E / S directe. Chaque application possède son propre stockage de données, qui est sérialisé sur le disque par la base de données.

+ +

 

+ +

Destruction de données

+ +

Quand un utilisateur désinstalle une application, toutes les données (cookies, localStorage, IndexedDB, etc.) associées à cette application sont supprimées.

+ +

Privacy

+ +

Mozilla est engagé à protéger la vie privée de l'utilisateur et les données utilisateur en fonction de ses principes de confidentialité (https://www.mozilla.org/privacy/), qui découlent du Manifeste Mozilla (https://www.mozilla.org/about/manifesto.html). La politique de confidentialité Mozilla Firefox décrit comment Mozilla collecte et utilise des informations sur les utilisateurs du navigateur Web Mozilla Firefox, y compris ce que Firefox envoie aux sites Web, ce que Mozilla fait pour sécuriser les données, les pratiques de données de Mozilla, et ainsi de suite. Pour plus d'informations, voir:

+ + + +

Firefox OS met en œuvre ces principes en mettant le contrôle des données de l'utilisateur dans les mains de l'utilisateur, qui doit décider où cette information est personnelle va. Firefox OS offre les fonctionnalités suivantes:

+ + diff --git a/files/fr/archive/b2g_os/securite/system_security/index.html b/files/fr/archive/b2g_os/securite/system_security/index.html new file mode 100644 index 0000000000..98ab311d64 --- /dev/null +++ b/files/fr/archive/b2g_os/securite/system_security/index.html @@ -0,0 +1,449 @@ +--- +title: Sécurité du système +slug: Archive/B2G_OS/securite/System_security +translation_of: Archive/B2G_OS/Security/System_security +--- +
+

Cet article donne un aperçu du modèle de sécurité du système de Firefox OS ; il explique comment le système d'exploitation assure la sécurité et applique des autorisations.

+
+ +

Terminologie

+ +

Avant de plonger dans le modèle de sécurité du système, voici quelques termes clés que vous devez comprendre.

+ +
+
Application web
+
Une application Web, application open web, application mozilla, ou application est un programme écrit en HTML, JavaScript, et d'autres technologies Open Web, fonctionnant sur Firefox OS (ou toute autre plate-forme qui prend en charge le même modèle d'application installable). Toutes les demandes présentées aux internautes sur B2G sont des applications web. Par exemple, le Dialer est une application Web dans Firefox OS. Pages exécutées dans le navigateur ne sont pas désignés comme des applications Web dans ce contexte.
+
Processus b2g
+
Le processus de b2g Firefox OS est généralement appelé "b2g" ou "Gecko". Ceci est, essentiellement, une application qui fonctionne avec des privilèges élevés (par exemple, s'exécute en tant que root) et contrôle l'accès que toute application Web a sur toutes les ressources et les dispositifs.
+
Content process
+
Ceci est un processus enfant engendré par le processus de B2G, et qui communique avec le processus B2G. Elle représente une application web. Ceci est un processus à faible privilégié (exemple: exécuter comme utilisateur régulier et a un accès et vue sur / pour le système d'exploitation très limitée). Il communique avec le processus de base de Firefox OS en utilisant la communication inter-processus (IPC).
+
IPDL
+
Intercommunication Protocole Définition Langue, vous pouvez aussi consulter IPDL.
+
AOSP
+
Android Open Source Project (Projet Open source Android).
+
Appel system
+
Une interface d'appel entre l'espace de l'utilisateur (processus) et le noyau. Il n'y a pas d'autre moyen direct pour un processus de l'espace pour communuquer au noyau.
+
DAC, MAC
+
Discretionary Access Control (configuré par l'utilisateur) and Mandatory Access Control (forcée par le noyau).
+
FOTA
+
Firmware Over The Air met a jour le mecanisme du système. Il décrit les mises à jour du firmware complètes, généralement envoyés "over the air", soit sur une connexion sans fil à un téléphone mobile.
+
MSU, MAR
+
Mozilla System Updater, Mozilla ARchive. Terme utilisé pour décrire les mises à jour de Gecko, en utilisant le même mécanisme de mise à jour et le format archive comme pour Firefox Desktop.
+
+ +

Objectifs et portée du modèle de sécurité du système Firefox OS

+ +

Le modèle de sécurité du système Firefox OS est conçu pour:

+ + + +

Voir les sections ci-dessous pour des explications plus détaillées de chacun de ces objectifs, et comment ils sont traités par Firefox OS.

+ +

Mettre en œuvre les permissions

+ +

Le modèle de sécurité d'application décrit comment les utilisateurs accordent des autorisations pour les applications, que ce soit directement ou par un tiers de confiance. Ces autorisations sont appliquées sur le processus contenu par l'application de tout accès à la ressource est réalisée par l'intermédiaire d'un appel IPC au processus de base.

+ + + +

Initialisation du processus de contenu

+ +

Toutes les applications web tournent dans un processus distinct doté de droits : le processus de contenu de Firefox OS. Ce processus est lancé par le processus de base b2g quand il atteint un <iframe> type spécial : <iframe mozapp>. Cela sépare l'application web du reste du contenu et est fortement associée à un manifeste (voir le modèle de sécurité des applications pour plus d'informations). Les processus de contenu sont lancés dans le récipient appelé récipient « en dehors du processus », ou un OOP (Out Of Process). Il est représenté par le processus plugin-conteneur et utilise un code similaire au plug-in-conteneur utilisé par le bureau Firefox.

+ +

Risques

+ + + +

Implémentation

+ +

Initialisation dans le processus b2g

+ +

Dans cet ordre :

+ +
    +
  1. fork()
  2. +
  3. setuid(new, different, unused user id|nobody) (which is an unprivileged user)
  4. +
  5. chrdir('/')
  6. +
  7. execve('plugin-container')
  8. +
+ +

Cela garantit que le processus de POO fonctionne dans un espace mémoire séparé (nouveau processus) et un utilisateur des droits bas ne peut pas élever ses privilèges au niveau du processus de b2g.

+ +

Gestion des descripteurs de fichier

+ +

Les descripteurs de fichiers sont traités en utilisant une méthode whitelist; une liste de descripteurs de fichiers autorisés (FDs) est créé et stocké dans l'objet mFileMap. La fonction LaunchApp() ferme avec force tous les FDS qui ne sont pas sur la liste blanche. Ceci est fait après fork() (qui est quand les FDs sont copiés) mais avant execve() (qui est quand la nouvelle application commence à courir).

+ +

Contrairement à la méthode plus traditionnelle qui utilise une liste noire (close-on-exec flag: CLOEXEC), ce qui garantit aucun FDs sont laissées ouvertes; ceci est donc plus fiable.

+ +

Content process sandboxing (processus de contenu des droits réduits)

+ +

Risques

+ + + +

Cet element a une table de modélisation des menaces avec un sandbox de permis, en plus de la rapide récapitulation des risques mentionnés ci-dessus.

+ +
+

Étendue : les menaces suivantes apparaissent si un attaquant exécute du code arbitraire dans le processus de contenu. En d'autres termes, l'attaquant a déjà trouvé une vulnérabilité au sein de gecko.

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MenaceImpact potentielFacteur(s) de vraisemblanceMesures d'atténuation proposées(s)
+

Les processus de contenu malveillants exploitent la vulnerabilité du noyau

+ +

"2 étapes attaquent".

+
Critique: le contrôle de l'appareil complet.Faible: Contenu processus a un nombre limité de système appelle disponibles. +
    +
  • Réduire le nombre d'appels système permi au strict minimum.
  • +
  • Utilisez des correctifs proactives pour protéger le noyau, comme PaX (Protection Against eXecution).
  • +
+
+

Elévation de privilèges au processus parent.

+ +

processus de contenu malveillant exploite processus parent par l'intermédiaire de IPDL.

+ +

"2 étapes attaquent".

+
Haut: Possibilité d'exécuter un nombre important d'appels système sensibles (perte de données, l'accès à la caméra, l'accès au réseau, etc.).Moyen: Une grande quantité de code dans le processus parent. Grande surface d'attaque. sanitization Minimal des données envoyées par l'intermédiaire de BNPI (il est en mesure d'envoyer des pointeurs, par exemple). +
    +
  • Exécutez le processus parent comme non-root / utilisateur non privilégié.
  • +
  • Attempt to sandbox the parent process as much as possible.
  • +
+
+

Les processus de contenu malveillant exploite le processus parent pour exploiter la vulnérabilité du noyau exposée.

+ +

"3 étapes attaquent".

+
Critique: le contrôle de l'appareil complet. +

Faible: Requiert un bug dans le processus parent qui peut être consulté par le biais de BNPI.

+ +

Nécessite la vulnérabilité du noyau au sein de l'appel système accessible au processus parent (beaucoup plus d'appels système sont disponibles pour le processus parent, par rapport au processus de contenu.)

+
+
    +
  • Exécutez le processus parent comme non-root / utilisateur non privilégié.
  • +
  • Attempt to sandbox the parent process as much as possible.
  • +
  • Utilisez des correctifs proactives pour protéger le noyau, comme PaX (Protection Against eXecution).
  • +
+
+

Contenu malveillant, processus parent ou de l'application Web exploite un bug dans le matériel de l'appareil.

+ +

"1 and 2 steps attack".

+
+

Haut: Possibilité d'exécuter des opérations privilégiées (comme les appels, l'envoi de SMS, etc.) jusqu'à:

+ +

Critique: Capacité d'exécuter du code au niveau du matériel, le contrôle de l'appareil complet.

+
Faible: Nécessite un canal de communication avec le matériel, acquis par le biais de IPDL ou d'un appel système, et un bug matériel. +
    +
  • Périphériques matériels Fuzz.
  • +
  • Travailler autour des problèmes via le noyau et / ou  patchs API de processus parents (désactiver l'accès à la fonctionnalité matérielle vulnérable ou aseptiser les données avant de passer au-dessus).
  • +
+
+ +
+

Note: PaX (Protection Against eXecution) est un patch du noyau de GrSecurity (docs), qui met en œuvre les deux «PaX» et des protections additionel tels que UDEREF et SMAP.

+ +

vulnérabilités non listés sont atténués par le sandbox lui-même.

+
+ +

Implementation

+ +
+

Superviseur n'a pas encore été mis en œuvre.

+
+ +

Process Model Sandbox

+ +
+

Remarque : Les processus en cours d'exécution de contenu sont les applications Web, et sont les processus à sandbox.

+
+ +

Implémentation des API de Gecko

+ +

Les API exposées via JavaScript dans le processus de contenu ne devrait jamais tenter d'accéder aux ressources du système de fichiers directs. Au lieu de cela, ils doivent émettre un appel IPDL pour la ressource. Cela signifie que toute API faisant accès à la ressource doit avoir une composante dans le processus parent d'accéder à la ressource pour le compte du processus de contenu.

+ +

Des précautions supplémentaires doivent être prises lors de l'implémentation des appels. Toutes les entrées doivent être désinfectés par le processus parent. Le contenu processus ne peut pas être digne de confiance, et de la IPDL messages provenant du contenu processus ne peut pas être digne de confiance.

+ +
+

Attention : Toute confiance accordée au processus de contenu peut et sera utilisé pour échapper à la sandbox.

+
+ +

Qu'est-ce que seccomp

+ +

Seccomp signifie le mode de calcul sécurisé. Il y a actuellement 2 version de seccomp:

+ +
    +
  1. +

    seccomp, disponibles dans le noyau Linux 2.6.12 et ci-dessus:

    + +
      +
    • +

      Activation seccomp limite les appels des processus du système à lire, écrire, sigreturn, et la sortie.

      +
    • +
    • +

      Utilise l'appel système prctl().

      +
    • +
    • +

      Peut être démarré après l'initialisation du processus, dans un lieu d'arbitrage.

      +
    • +
    +
  2. +
  3. +

    seccomp-bpf également appelé mode filtre seccomp ou mode 2, est disponible dans le noyau Linux 3.5 et ci-dessus:

    + +
      +
    • +

      Identique à seccomp, mais met en oeuvre BPF pour filtrer les appels système.

      +
    • +
    • +

      Peut utiliser une liste blanche des d'appels et arguments systèmes lors de l'initialisation, au lieu d'appels système codé en dur.

      +
    • +
    • +

      Plus flexible, permet une "sandbox plus permissive". Utile pour sandbox légèrement plus faibles, et pour un chemin de transition vers "sandbox stricte".

      +
    • +
    • +

      Ajoute un drapeau qui empêche les processus de traitement et de l'enfant pour revenir privilèges.

      +
    • +
    +
  4. +
+ +
+

Remarque : En raison de la flexibilité accrue qui est permi, nous avons décidé d'utiliser seccomp-bpf, avec rétroportage à tout noyau <3.5. Cela inclut la plupart des noyaux Android actuels. Un patch est déjà disponible et peut généralement être appliquée sans conflits (voir le bogue 790923).

+
+ +

Performances seccomp-bpf

+ +

Les performance seccomp-bpf à des impacts chaque fois qu'il y a un appel system . Il n'y a pas de référence exacte, comme la mesure dépend de la mise en œuvre. Nous estimons que cela peut influer sur les performances jusqu'à 1% quand un appel système est fait et seccomp-bpf est activé pour le processus en cours. Cela reste à être mesurée par QA.

+ +

Étant donné que le nombre d'appels système est considérablement réduit dans notre modèle de processus, nous prévoyons également l'impact sur les performances du monde réel qui devrait être presque nulle.

+ +

Les appels IPDL peuvent toutefois ajouter la latence et réduire les performances, en fonction de leur mise en œuvre. Il est fortement recommandé de regarder la mise en œuvre de chrome pour les API gourmandes en ressources telles que les appels OpenGL. De façon similaire à seccomp-bpf, si nous réduisons le nombre d'appel IPDL, nous allons minimiser les impacts sur les performances.

+ +

Implémentation

+ +

seccomp est activé dans Gecko avec --enable-content-sandbox.

+ +

Le reporteur, qui reporte les appel systèmes refusé (le cas échéant) ne soit jamais construit par défaut et est activé avec l'option --enable-content-sandbox-reporter.

+ +

La majeure partie du code est dans gecko/security/sandbox. Le liste blanche elle-même est stocké dans gecko/security/sandbox/seccomp_filter.h.

+ +

La liste blache peut contenir des appels système qui peuvent être utilisés les cloisonnements. En règle générale, ces appels ont des commentaires indiquant pourquoi, et devraient éventuellement être supprimés lorsque le code affecté est fixé. Par conséquent, il est presque jamais OK pour ajouter le code qui va briser le sandbox, puis ajoutez l'appel dans la liste blanche, sans un examen très attentif. Dans le doute, soulever un bug. La plupart du temps cependant, ce qui est faux, et la ressource devrait plutôt être contrôlé, accessible par le processus de b2g, puis passé au processus de contenu si l'accès est accordé et / ou les données sont filtrées.

+ +

Durcissement du système de fichiers

+ +

Risques

+ + + +

Implémentation

+ +

La raison en est que seules les zones qui contiennent du contenu d'utilisateur peut être en lecture-écriture (à moins que le système d'exploitation lui-même exige une nouvelle zone de lecture-écriture dans le futur), et doivent inclurenodev, nosuid, et noexec Les supports du système de fichiers standard sont limitées comme suit:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Point de montageSystème de fichiersOptions
/rootfsread-only
/devtmpfsread-write, nosuid, noexec, mode=0755
/dev/ptsptsfsread-write, nosuid, noexec, mode=0600
/procprocread-write, nosuid, nodev, noexec
/syssysfsread-write, nosuid, nodev, noexec
/cacheyaffs2 or ext4read-write, nosuid, nodev, noexec
/efsyaffs2 or ext4read-write, nosuid, nodev, noexec
/systemext4read-only, nodev
/dataext4read-write, nosuid, nodev, noexec
/mnt/sdcardext4 or vfatread-write, nosuid, nodev, noexec, uid=1000, fmask=0702, dmask=0702
/acctcgroupread-write, nosuid, nodev, noexec
/dev/cpuctlcgroupread-write, nosuid, nodev, noexec
+ +
+

Remarque : Les points de montage exacts peuvent varier.

+
+ +

Linux DAC

+ +

Le Linux DAC représente le modèle d'autorisation de système de fichiers de Linux bien connue.

+ +
+

Remarque : Ceci est le traditionel user/group/other modèle d'autorisation et non les Linux POSIX 1E ACLs.

+
+ + + +

Mises à jour du système sécurisé

+ +

Risques

+ + + +

Implémentation

+ +

Mises à jour ultérieures et des correctifs à la plate-forme Firefox OS sont déployés en utilisant un processus sécurisé de Mozilla qui assure l'intégrité continue de l'image du système sur le téléphone mobile. La mise à jour est créé par un connu, source de confiance - habituellement le OEM de l'appareil - qui est responsable de l'assemblage, la construction, les essais et la signature numérique du package de mise à jour.

+ +

Firmware over the air updates

+ +

Les mises à jour du système peuvent concerner tout ou une partie de la pile Firefox OS. Si des modifications à Gonk sont inclus dans la mise à jour, puis la FOTA (Firmware Over the Air) est le processus d'installation utilisé. les mises à jour FOTA peuvent également inclure toute autre partie de la pile de Firefox OS, y compris la gestion des périphériques (FOTA, firmware / pilotes), la gestion des paramètres (réglages du système d'exploitation Firefox), les mises à jour de sécurité, Gaia, Gecko, et d'autres correctifs.

+ +

Mises à jours MSU/MAR

+ +

Les mises à jour qui ne concernent pas Gonk peuvent être effectuées en utilisant l'utilitaire Mozilla System Update. Firefox OS utilise le même cadre de mise à jour, les processus et Mozilla ARchive (MAR) Format (utilisé pour les packages de mise à jour) que le produit Firefox Desktop.

+ +

Service de mise à jour

+ +
+

Remarque : Le service de mise à jour peut être fourni par l'OEM.

+
+ +

Un service de mise à jour intégrée sur le téléphone mobile vérifie périodiquement les mises à jour du système. Une fois un paquet de système devient disponible et est détecté par le service de mise à jour, l'utilisateur est invité à confirmer l'installation. Avant que les mises à jour s'installes sur l'appareil mobile, le stockage de l'appareil est vérifié pour un espace suffisant pour appliquer la mise à jour, et la distribution est vérifiée:

+ + + +

Les mesures de sécurité suivantes sont utilisées au cours du processus de mise à jour:

+ + + +

Des contrôles rigoureux sont en place pour veiller à ce que la mise à jour est appliquée correctement sur le téléphone mobile.

+ +
+

Remarque: Pour plus d'informations sur les mises à jour de la plate-forme, lisez Création et application de packages de mise à jour de Firefox OS.

+
-- cgit v1.2.3-54-g00ecf