1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

Lion (9)




Les éléments internes

La précédente livraison de Mac OS X se focalisait sur les modifications internes. Mon rapport avait fait la même chose, et couvert les caractéristiques du compilateur, les extensions au langage de programmation, les nouvelles bibliothèques, et d'autres détails qui étaient principalement invisibles pour les utilisateurs finaux.

Pour l'essentiel, Lion n'est à coup sûr pas une livraison centrée sur les éléments internes, mais ils sont aussi assez gros pour avoir leur part dans des changements importants du noyau de l'OS qui accompagnent des changements plus évidents, visibles par l'utilisateur. Si c'est la première fois que vous lisez un rapport d'Ars Technica sur Mac OS X, et que vous êtes arrivé(e) jusqu'ici, soyez averti(e) : cette section va être encore plus ésotérique que celles que vous avez déjà lues. Si vous voulez seulement voir les copies d'écran des applications nouvelles ou modifiées, prenez la liberté de sauter à la section suivante. Nous, les nerds, nous n'en penserons pas moins de vous.


La sécurité.

L'approche d'Apple à l'égard de la sécurité a toujours manqué un peu d'orthodoxie. Microsoft à passé plusieurs de ces dernières années à rendre la sécurité une priorité principale de Windows, et l'a fait d'une façon très publique. Aujourd'hui, Windows 7 est considéré comme beaucoup plus sécurisé que son ancêtre, Windows XP, qui avait été largement exploité. Et en dépit du fait que Microsoft distribue maintenant son propre logiciel de protection contre le malware et les virus, un marché florissant existe pour les logiciels anti-virus tiers.

Pendant ce temps, sur le Mac, Apple n'a que très récemment ajouté à Mac OS X une certaine protection de base contre le malware, et l'a fait en silence. Les mises à jours ont elles aussi été discrètes, et donné l'impression qu'Apple ne parle des virus et du malware que si on lui pose une question directe sur un élément précis, spécifique de logiciel malicieux.

Cette attitude est typique d'Apple : ne dites rien jusqu'à ce que vous ayez quelque chose de significatif à dire. Mais cela peut rendre fous les experts en sécurité, et aussi les journalistes. Et pour les utilisateurs finaux, et bien, jusqu'à ce qu'il y ait un problème de sécurité qui affecte plus qu'une petite minorité d'utilisateurs de Macs, il est difficile de trouver un exemple de la façon dont les règles et les pratiques d'Apple ont failli à protéger les utilisateurs de Macs au moins aussi bien que Microsoft protège les utilisateurs de Windows.


Le bac à sable.

Le fait qu'Apple ne fasse pas de bruit ne signifie pas qu'elle n'a pas pris de réelles mesures pour améliorer la sécurité sur le Mac. Sous Léopard, Apple avait ajouté une forme élémentaire de bac à sable au noyau. Beaucoup des processus en démon qui permettent à Mac OS X de fonctionner le font à l'intérieur de bacs à sable sous Snow Léopard. A nouveau, cela a été fait avec discrétion.

Faire tourner une application dans un bac à sable a pour but de minimiser les dommages qui pourraient être provoqués si cette application est compromise par un élément de malware. Une application en bac à sable renonce volontairement à la possibilité de faire beaucoup de choses qu'un processus normal, exécuté pas le même utilisateur, pourrait faire. A l'évidence, une application qui se comporte bien, ne fera pas cela. Mais si une application devient compromise, elle peut être forcée à faire quelque chose de destructeur.

Dans Lion, le modèle de sécurité du bac à sable a été grandement amélioré, et Apple en fait finalement la promotion pour qu'il soit utilisé par des applications tierces. Une application avec bac à sable doit maintenant comprendre une liste d'autorisations qui décrivent exactement de quelles ressources elle a besoin pour faire son travail. Lion supporte environ 30 autorisations, qui vont de choses de base comme créer une connexion au réseau, ou surveiller des connexions réseau entrantes (deux autorisations différentes) jusqu'à des tâches sophistiquées comme la capture de vidéo ou d'images fixes à partir d'une caméra interne.

Il pourrait sembler que toute application Mac quelque peu importante basée sur un document, ait besoin, à tout le moins, de déclarer une autorisation pour lui permettre de lire dans n'importe quel dossier possédé par l'utilisateur courant, et d'écrire dedans. Après tout, comment un utilisateur pourrait-il ouvrir ou enregistrer des documents autrement ? Et dans ce cas, est-ce que cela ne va pas anéantir l'intérêt du bac à sable ?

Apple a choisi de résoudre ce problème en fournissant des autorisations plus élevées à certaines classes d'action : celles qui sont lancées explicitement par l'utilisateur. Lion inclut un processus démon sécurisé appelé Powerbox pboxd dont la tâche est de présenter et de contrôler les boîtes de dialogue Ouvrir/Enregistrer pour le compte des applications avec bac à sable. Après que l'utilisateur ait sélectionné un fichier ou un répertoire, dans lequel un ficher doit être enregistré, Powerbox fait un trou dans le bac à sable de l'application, qui lui permet d'exécuter l'action spécifique.

Un mécanisme similaire est utilisé pour permettre l'accès à des fichiers récemment ouverts dans le menu "Ouvrir l'élément récent", pour restaurer des documents préalablement ouverts quand une application est relancée, pour gérer le glisser-déposer, et d'autres. Le but est d'empêcher les applications d'avoir à réclamer des autorisations pour permettre la lecture ou l'écriture de fichiers de donnés. Oh, et pour le cas où cela va sans dire, toutes les applications en bac à sable doivent être signées.

Voici quelques exemples de processus en bac à sable dans Lion, montrés par l'application Moniteur d'activité, avec la colonne "Bac à sable" visible.

figure

Les processus en bac à sable dans Lion

Précédemment, le Mac App Store était proposé comme un moyen pour Apple d'accélérer l'adoption des nouvelles technologies de Lion. Dans le cas du bac à sable, c'est ce qui est déjà arrivé. Apple a décrété que toutes les applications soumises au Mac App Store devaient être en bac à sable à partir de Novembre.


La séparation des privilèges.

Une des limitations du bac à sable est que les autorisations s'appliquent à un processus complet. Une application en bac à sable doit en conséquence posséder le sur-ensemble de toutes les autorisations nécessaires pour chaque caractéristique qu'elle fournit. Comme nous l'avons vu, l'utilisation du processus démon Powerbox empêche les applications de réclamer un accès arbitraire au système de fichiers, en déléguant des autorisations à un autre processus externe. C'est un cas particulier d'un principe général appelé la séparation de privilège.

L'idée est de casser une applications complexe en processus individuels, dont chacun n'exige que quelques autorisations pour accomplir un sous-ensemble spécifique des possibilités totales de l'application. Par exemple, considérez une application qui a besoin de jouer de la vidéo. Le décodage vidéo est un processus complexe et sensible du point de vue de la performance, qui a conduit dans le passé à une protection inadéquate contre les dépassements de tampons et d'autres problèmes de sécurité. Une application qui doit afficher de la vidéo le fera vraisemblablement en utilisant des bibliothèques fournies par le système, ce qui signifie qu'il n'y a pas beaucoup de choses qu'un développeur peut faire pour corriger des vulnérabilités quand elles interviennent.

Ce que le développeur peut faire à la place, c'est d'isoler la tâche de décodage vidéo dans son propre processus avec des privilèges sévèrement réduits. Un processus qui décode de la vidéo n'a sans doute pas besoin d'un quelconque accès au système de fichiers, au réseau, à la caméra intégrée, au micro, et ainsi de suite. Il a seulement besoin d'accepter un flux d'octets de son processus parent, (qui à son tour, a probablement utilisé Powerbox pour avoir la possibilité de lire ces octets sur le disque au départ) et à retourner le flux des octets décodés. En dehors de cette simple connexion à son parent, le décodeur peut être complètement isolé du reste du système. Maintenant, si un exploit est trouvé dans le codec vidéo, un hacker malintentionné se retrouvera à contrôler un processus qui a si peu de privilèges qu'il y a peu de dommages qu'il puisse faire au système ou aux données de l'utilisateur.

Bien que ce n'était qu'un exemple, l'application QuickTime Player de Lion, délègue en fait le décodage vidéo à un processus externe, en bac à sable, avec des privilèges très bas, appelé VTDecoderXPCService.

figure

QuickTime Player, avec son processus de décodage vidéo associé en bac à sable.

Un autre exemple tiré de Lion est l'application Aperçu, qui isole complètement le code d'analyse syntaxique PDF (une autre source historique d' exploits) de tous les accès au système de fichiers.

Si on met de côté les avantages de sécurité de cette approche pour le moment, la gestion et la communication à l'aide de processus externes est une forme de souffrance pour les développeurs. Elle est certainement moins facile que l'approche traditionnelle, avec tout le code dans un seul exécutable, et aucune fonctionnalité de plus qu'un appel de fonction.

Une fois encore, dans Lion, Apple a fourni un nouvel ensemble d'APIs pour encourager l'adoption de ce qu'elle considère comme une bonne pratique. Le framework XPC Services est utilisé pour gérer ces processus externes, et communiquer avec. Les exécutables de XPC Service sont contenus dans le paquetage de l'application. Il n'y a aucun processus d'installation, et ils ne sont jamais copiés ou déplacés. Ils doivent faire partie de la signature cryptographique de l'application pour empêcher la corruption.

Le framework XPC service va lancer un processus externe approprié sur demande, surveiller son activité, et décider quand il termine le processus après que le travail ait été fait. La communication est bidirectionnelle et asynchrone, avec la délivrance d'un message FIFO et l'environnement du processus par défaut XPC est extrêmement restrictif. Il n'hérite pas des autorisations du bac à sable du processus parent, des qualifications de Keychain, ou de tout autre privilège.

La récompense de la séparation d'une application en une collection d'éléments de moindres privilèges n'est pas seulement un accroissement de la sécurité. Cela signifie aussi qu'un crash dans l'un de ces processus externes ne va pas faire tomber toute l'application.

Nous avons vu ce genre de séparation des privilèges avec une grande efficacité dans les butineurs web de plusieurs plateformes différentes, y compris Safari sous Mac OS X. Lion a pour ambition d'étendre ces avantages à touts les applications. il rend aussi la séparation des privilèges de Safari encore plus granulaire.

Safari sous Lion est basé sur le WebKit2, la dernière et la plus importante itération du moteur de rendu qui actionne Safari, Chrome, et plusieurs autres butineurs d'ordinateurs de bureau ou de mobiles. Safari, dans Snow Léopard, séparait déjà les greffons comme Flash en ses propres processus. ( Adobe ne devrait pas considérer cela comme une insulte ; Apple fait la même chose avec son propre greffon de navigation dans QuickTime). Et pour allez plus loin sur le sujet, le Webkit2 sépare toute la tâche de rendu d'une page web en un processus externe. Le nombre d'occasion de plantage de l'application Safari décroît rapidement.

Comme le note le site web du WebKit2, le butineur Chrome de Google utilise une approche similaire pour isoler le WebKit (version 1) du reste de l'application. Le WebKit2 établit la séparation directement dans le framework lui-même, et permet aux clients WebKit2 d'en tirer parti sans avoir besoin du code personnalisé que Google a du écrire pour Chrome. (Voyez les diagrammes d'architecture des processus sur le site de WebKit2 pour des comparaisons plus détaillées entre le WebKit antérieur à Lion de Mac OS X et l'utilisation du WebKit par Chrome).