Sécurité du système

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:

• Limiter et faire respecter la portée des ressources qui peuvent être consultés ou utilisés par une application web.
• Veiller à plusieurs couches de sécurité qui sont correctement utilisés dans le système d'exploitation.
• Limiter et contenir l'impact des vulnérabilités causées par des bogues de sécurité, de la couche Gonk.
• Les autorisations d'application Web et une caractéristique de sécurité liées à l'application sont détaillés dans  la sécurité des applications

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.

• Le processus de base de Firefox OS, b2g, a des privilèges très élevés et a accès à la plupart des périphériques matériels.
• Les applications Web fonctionnent dans un processus contenu à faible privilégié et ne communiquent avec le processus de base b2g utilisant IPC, qui est mis en œuvre à l'aide de IPDL.
• Le processus de contenu n'a pas de system de niveau d'acces aux ressources.
• Chaque API Web a un ou plusieurs fichiers de déclaration de protocole IPDL plus associés) (* .ipdl).
• Le processus de contenu de Firefox OS ne peuvent communiquer à travers le mécanisme de IPDL dèrière le processus de base, qui effectuera des actions au nom du contenu.

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

• Fuite d'informations lors de la ponte du processus de contenu de l'application Web.
• Possibilité d'accéder à des ressources système d'exploitation, et l'escalade au même niveau de privilèges que le processus de b2g.
• Contourner l'initialisation du processus de contenu.

Implémentation

Initialisation dans le processus b2g

Dans cet ordre :

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

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

• Corruption de mémoire ou les erreurs logiques dans le runtime Gecko conduisant à l'exécution de code arbitraire.
• Défauts similaires dans le système d'exploitation lui-même (en particulier, le noyau) conduisant à l'exécution de code arbitraire.
• Fuite de l'information, l'accès en lecture / écriture au système de fichiers.

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.

Implementation

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.

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. 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.

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

• L'écriture, la suppression ou la lecture de fichiers appartenant à un autre utilisateur; cela pourrait entraîner une fuite d'informations ou un comportement inattendu, comme une escalade de privilège.
• Exécution de code natif par une vulnérabilité d'application.
• Des vulnérabilités dans les programmes setuid (et donc, une escalade de privilège).

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:

Linux DAC

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

• L'utilisateur du système d'application Web n'a pas accès en écriture à un fichier.
• L'utilisation des binaires setuid est limité si nécessaire.
• Les nouveaux procédés de contenu sont lancés avec un umask sain d'esprit.

Mises à jour du système sécurisé

Risques

• Données du package de mise à jour compromise, résultant dans un package de mise à jour untrusted en cours d'installation.
• Vérification de mise à jour compromis :
  • L'utilisateur ne voit pas de nouvelles mises à jour qui sont disponibles.
  • L'utilisateur reçoit un paquet obselete comme une mise à jour, ce qui dégrade efficacement le logiciel sur le dispositif.
• L'état du système compromis ou inconnu lors de l'installation de la mise à jour; cela peut (par exemple) conduire à:
  • Éléments au cours de l'installation, dont certains peuvent avoir des correctifs de sécurité manquants.
  • Les corrections de sécurité rétrocédées par le système compromis après la mise à niveau.
• Des vulnérabilités dans la mise à jour de vérification mécanisme fonctionnant sur le dispositif.
• Le manque de mises à jour sur le suivi d'un composant logiciel avec une vulnérabilité connue.

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

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:

• Mettre à jour l'origine (vérifier le protocole de localisation de la source: domain: port de la mise à jour du système et manifeste).
• L'intégrité des fichiers (checksums de hachage cryptographique).
• signature de code (certificat de vérification contre une racine de confiance).

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

• Mozilla recommande et espère que les mises à jour sont récupérées via une connexion SSL avec un certificat de confiance.
• Vérification cryptographique forte est nécessaire avant l'installation d'un package de firmware.
• La mise à jour complète doit être téléchargé dans un endroit précis et sécurisé avant le début du processus de mise à jour.
• Le système doit être dans un état sécurisé lorsque le processus de mise à jour commence, sans applications Web en cours d'exécution.
• Les clés doivent être stockés dans un emplacement sécurisé sur le périphérique.

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