Sécurité sous Léopard SRSDAY - Rapport

Sécurité sous Léopard SRSDAY - Rapport Julien-Pierre Avérous - Aimeric Pieters Rapport de la SRSDAY Epita 17 juin 2008

Table des matières Sécurité Système - Introduction! 3 Architecture de Sécurité sous Mac OS X : 3 Les nouvelles mesures de sécurité fournies par Léopard : 4 Mandatory-Access-Control! 5 Introduction : 5 Sandboxing: 7 Adresses aléatoires des fonctions système! 13 Introduction 13 Buffer-overflow sur la pile 13 Adresses aléatoires 16 Conclusion 16 Signature numérique d application! 17 Introduction 17 Signature 17 Création de certificat 18 Commande codesign 20 Action! 21 Conclusion 22 Cartes À Puces! 23 Introduction : 23 Fonctionnement du service : 23 Ajouter la gestion d une carte à puce dans l environnement: 25 Coupe-feu! 28 Introduction 28 Configuration : 28

Amélioration de l existant : 29 Windows : 29 Conclusion! 30 Bibliographie! 31

SÉCURITÉ SYSTÈME - INTRODUCTION I. Architecture de Sécurité sous Mac OS X : Les services de sécurité de Mac OS X sont principalement organisés autour de deux éléments, le noyau du système formé de MACH et BSD et CDSA. Pour plus de détails sur le noyau de Mac OS X se reporter à l introduction du chapitre sur Mandatory Access Control. CDSA, pour Common Data Security Architecture, est un ensemble de services de sécurité et de cryptographie. C est une architecture Open Source de sécurité qui a été adoptée comme standard par l Open Groupe. Apple a développé sa propre implémentation Open Source du CDSA. Le coeur de ce framework est le CSSM, pour Common Security Services Manager qui est composé d APIs fournissant un ensemble de services de cryptographie. D autres services de sécurité sont fournis par CDSA comme par exemple la sauvegarde sécurisée de données. Mac OS X fournit en plus de CDSA ses propres APIs de sécurité. Elles servent d intermédiaire entre les applications et le CDSA.! Voici l organisation de l architecture de sécurité sous Mac OS X :

II. Les nouvelles mesures de sécurité fournies par Léopard : Le but de ce dossier est de présenter les nouvelles mesures de sécurité fournies par Léopard. Que cela soit dans le noyau XNU ou dans le CDSA, toutes les couches de sécurité de Mac OS X sont impliquées dans la mise en place de ces nouveautés. Le système de Mandatory Access Control et l adressage aléatoire des fonctions système sont implémentés au niveau du noyau. Certaines mesures comme la signature d applications ou le système de coupe-feu interagissent avec les différentes couches de sécurités. Le système de gestion de carte à puce est, quant à lui, limité aux services de sécurité de Mac OS X (niveau trois). Tout le long du rapport des comparaisons seront effectuées avec le système d exploitation Windows de Microsoft. Les comparaisons ne prendront pas en compte Windows Vista du fait de sa très faible intégration en entreprise.

M A N D A T O R Y - A C C E S S - C O N T R O L I. Introduction : 1. Particularités de Mac OS X et de son noyau Mach : micro-noyau libre, gratuit et écrit en C. Mach est une fusion entre BSD 4.4 et Accent, un noyau développé par l université de Carnegie Mellon. BSD 4.4 apporte la portabilité et la gestion d architecture multi-processeurs (SMP). BSD : (Berkeley Software Distribution) est un noyau Linux. Tout un ensemble de systèmes d exploitation est issu de ce projet, chacun étant réputé dans un domaine précis: FreeBSD : fiabilité en tant que serveur OpenBSD : sécurité NetBSD : portabilité XNU : X is Not Unix est le noyau de Mac OS X. XNU est un noyau hybride composé du Micro Noyau Mach, d une partie du noyau BSD (plus particulièrement de FreeBSD) et d I/O Kit une API écrite en C++ utilisée pour l écriture de pilotes. Applications Services Noyau BSD µ noyau hybride Matériel

2. Mandatory Access Control Mandatory Access Control (MAC) ou Contrôle d Accès Obligatoire est un framework de contrôle d accès. Il définit les droits d accès pour un sujet à un objet. Il est implémenté au niveau du noyau (XNU). Un sujet est un processus ou un thread. Un objet est un fichier, un port TCP/UDP, un segment de mémoire partagé, etc. Une opération est donc constituée d un sujet et d un objet, chacun d eux comportant des attributs de sécurité qui sont comparés à un ensemble de règles d'accès afin de déterminer la bonne politique de sécurité. À partir de cette comparaison, le système d exploitation détermine si l opération est permise et dans quel contexte ou emplacement l'exécution peut se dérouler. Ce contexte est associé à un niveau de sécurité qui détermine les restrictions associées à l'exécution du programme. Exemple de restriction : restreindre l accès à un dossier ou empêcher un processus d établir une connexion réseau. Hérité de BSD, le framework MAC est développé par le projet TrustedBSD. Un portage de ce projet pour Darwin existe et est appelé SEDarwin (Security Enhanced Darwin), mais c est une version modifiée par Apple qui est utilisée dans Mac OS X. De plus, le mécanisme de décision qui détermine quelle est la politique de sécurité à appliquer est spécifique à Darwin. Apple n a pas repris les principes du SELinux policy qui a été porté pour le projet SEDarwin et a défini ses propres politiques. Ce mécanisme de décision est appelé Seatbelt et l extension du noyau qui lui est associé peut être trouvé à l emplacement suivant : /System/Library/Extensions/seatbelt.kext. Le framework est composé de modules, chacun dédié à une politique de sécurité, le tout associé à un environnement de sécurité multi-niveaux. Une application ou un processus est associé à un module, et donc à une politique de sécurité, par l intermédiaire de labels. MAC est implémenté au niveau du noyau, néanmoins ce mécanisme est disponible pour l utilisateur lambda : c est le Sandboxing ou principe du bac à sable.

II. Sandboxing: 1. Description Sandboxing ou bac à sable est une application de MAC. Il permet de restreindre les possibilités d'accès d une application. Cela limite, par exemple, les possibilités d action d un pirate en cas de prise de contrôle d un logiciel. Un processus hérite de la sandbox de son parent et est donc limité aux mêmes restrictions que celui-ci. Le Sandboxing de Léopard n est donc pas de type DAC (Discretionary Access Control) apparenté à des droits Unixiens sur des exécutables ou des fichiers précis. C est bien une implémentation qui utilise le MAC au niveau du noyau, ce qui est une protection beaucoup plus forte. Un processus, même root, qui est sandboxé ne pourra pas passer outre les restrictions qui lui sont appliquées. Léopard fournit donc à l utilisateur tout un panel d outils lui permettant de mettre en place une sandbox. 2. Outils sandbox-exec : sandbox-exec [-f profile-file] [-n profile-name] [-p profile-string] command Cette commande crée une sandbox à partir d un profile spécifique. Il exécute ensuite la commande command dans le contexte d exécution qui lui a été attribué. Les différentes options sont autant de manières possibles pour définir la politique de sécurité: -f : lit la description du profile à partir du fichier profile-file. -n : utilise le profile prédéfini profile-name. -p : spécifie le profile utilisé en ligne de commande. Le système possède des profiles de base, ils sont installés à l emplacement suivant : /usr/share/sandbox.

sandbox_init : int sandbox_init(const char *profile, uint64_t flags, char **errorbuf); void sandbox_free_error(char *errorbuf); sandbox_init est une fonction C qui place le processus courant dans une sandbox : profile spécifie le nom du profile utilisé, celui-ci peut prendre les valeurs suivantes: ksbxprofilenointernet : les communications TCP/IP sont prohibées. ksbxprofilenonetwork : toute utilisation de sockets réseau est interdite. ksbxprofilenowrite : l écriture de fichier est interdite. ksbxprofilenowriteexcepttemporary : l écriture de fichier est limitée au dossier temporaire /var/tmp et au dossier spécifié par la fonction confstr. Cette fonction initialise la variable _CS_DARWIN_USER_TEMP_DIR. ksbxprofilepurecomputation : l utilisation des processus du système d exploitation est interdite. flags : SANDBOX_NAMED. errorbuf : contient le statut de l erreur. Si l utilisation de sanbox_init est un succès, alors la valeur de retour de la fonction est 1 et errobuf vaut 0. Sinon la valeur de retour est -1 et errobuf contient la description de l erreur. Ce pointeur doit être passé en paramètre de la fonction sandbox_free_error afin de libérer la mémoire qui lui est allouée.

sandbox-compilerd : sandbox-compilerd [-d] [-N] Ce programme compile les profiles de sandbox et étend ainsi la sandbox du noyau : -d : debug, enregistre des informations supplémentaires dans les fichiers de log par l intermédiaire de la fonction asl_log. -n : le profile de la sandbox n est pas mis en cache. 3. Exemples Utilisation de sandbox_init : Dans l exemple qui suit, le programme est confiné dans une sandbox. La politique de sécurité utilisée est une politique prédéfinie par Apple : ksbxprofilenowrite. Elle empêche le processus d écrire un fichier. Après avoir initialisé la sandbox, le programme essaye d ouvrir un fichier et d effectuer les opérations suivantes : lecture : qui devrait être autorisée par le système. écriture : qui devrait être interdite par le système.

#include <sandbox.h> #include <unistd.h> #include <stdio.h> #include <fcntl.h> #include <string.h> int main (int argc, { char *argv[]) int ret, fd; char **errbuf; char buf[50], buf2[] = "blah blah\n"; ret = sandbox_init(ksbxprofilenowrite, SANDBOX_NAMED, errbuf); if (ret!= 0) { printf("error initializing sandbox: %s\n", *errbuf); sandbox_free_error(errbuf); } return 1; } fd = open("temp", O_RDONLY); if (fd < 0) perror("error reading temp"); else { read(fd, buf, 50); close(fd); } fd = open("temp", O_WRONLY); if (fd < 0) perror("error writing temp"); else { write(fd, buf2, strlen(buf)); close(fd); } return ret; Après compilation le résultat de l'exécution du programme est le suivant : Error writing temp: Operation not permitted La lecture du fichier temp a donc été effectuée, mais l écriture a échoué.

Utilisation de sandbox-exec : sandbox-exec permet d'exécuter un programme en lui assignant une politique de sécurité afin de lui restreindre son accès au système. Cet utilitaire permet d employer des politiques existantes, mais pour cet exemple, une politique est créée. Voici le fichier qui la décrit. Les explications sont mises en commentaire. ;; Test seatbelt sandbox policy (version 1) ;; Active le debugging, ce qui permet d avoir une ;; trace des refus d accès dans le fichier ;; /var/log/system.log (debug deny) ;; Importe la politique de sécurité du fichier ;; bsd.sb qui fournit des règles de bases (import "/usr/share/sandbox/bsd.sb") ;; Autoriser la création de nouveaux processus (fork/exec) (allow process*) ;; Permet la lecture des bibliothèques dynamique (dyld) (allow file-read-data (regex "^/private/var/db/dyld/dyld_shared_cache_i386$")) ;; Permet de lire les sysctls (allow sysctl-read) ;; Permet la lecture du fichier de test temp (allow file-read-data (regex "^/Users/papywarrior/tmp/temp")) Ce fichier décrit donc une politique de sécurité établie pour une sandbox. Ce genre de fichier prend l extension.sb, sb pour sandbox. Cette politique sera appliquée au programme décrit précédemment. Celui-ci reste inchangé hormis l appel à sandbox-init qui est retiré. L'exécution de la commande sandbox-exec s effectue de la façon suivante : sandbox-exec -f politique.sb./test_sandbox_exec

test_sandbox_exec est le nom programme compilé et politique.sb correspond au fichier décrit précédemment. Pour faire appel à une politique existante, if faut utilisé l option -n suivie du nom de la politique. Après exécution de cette commande, une vérification dans le fichier de log system.log peut-être faite. 4. Critiques L utilisation des sandbox par le système d exploitation reste, pour le moment, assez marginale. Cette nouvelle fonctionnalité apportée par Léopard est surtout utile pour les développeurs qui veulent sécuriser l environnement autour d une application pouvant présenter des failles. 5. Et Windows? Microsoft n'intègre pas dans son système d exploitation la notion de Sandboxing. Il est possible de mettre en place des Sandbox par l intermédiaire d application comme Sandboxie ou lors d un développement d une application en associant des objets de celle-ci à des processus au contrôle d'accès restreint. La sécurité d une Sandbox créée par ce type de méthode est discutable.

ADRESSES ALÉATOIRES DES FONCTIONS SYSTÈME I. Introduction Un des plus gros problèmes de sécurité dans les langages de bas niveau (C-C++-Assembleur) est le contrôle des accès utilisateur sur les buffers. Effectivement, les buffers mémoires utilisés pour traiter des données utilisateur ne sont pas sur des îlots au milieu de nulle part. Ils ne sont pas barricadés dans un milieu confiné, protégés de l extérieur. Autour d une donnée en mémoire, il y a d autres données. Et ces données peuvent être parfois sensibles. Quand un mémoire est utilisé pour traiter des données utilisateur, si la taille des données manipulées n est pas vérifiée, rien n empêche l utilisateur de s arranger pour que les données qu il envoie deviennent trop grandes pour passer dans l espace qui était prévu pour les traiter. Il peut donc aller écrire sur de la mémoire qui ne lui est pas réservée, et potentiellement sur de la mémoire qui contient des informations importantes. C est un buffer-overflow : un dépassement de buffer. II. Buffer-overflow sur la pile La mémoire est répartie en plusieurs zones logiques. Parmi celles-ci, il y a la pile et le tas. Le tas est utilisé pour les allocations dynamiques, et la pile pour stocker des informations sur le fil d exécution : variables locales, paramètres de fonction, pointeur de retour, allocation sur pile (avec alloca() ), etc. Cette partie traitera donc les buffers-overflow.

Prenons l exemple du code suivant en C : int main(int argc, char *argv[]) { if (argc == 2) test_fonction(argv[1]); return 0; } void test_fonction(char *text) { unsigned int i, cnt = strlen(text); char buffer[4]; for (i = 0; i < cnt; i++) } buffer[i] = text[i]; Voici l état de la pile au moment de l exécution de la fonction test_function() : 0xFFFFFFFF Sauvegarde registre %ebp Adresse pointeur text Adresse retour dans main ( return 0 ) Sauvegarde registre %ebp Variable i de test_fonction %ebp 0x00000000 Variable cnt de test_fonction Variable buffer de test_fonction... %esp Il est supposé que le compilateur n aura fait utilisation d aucun registre pour l optimisation, avec une convention d'appel stdcall. Si l utilisateur passe en paramètre de notre application un texte plus petit que 5 caractères, alors tout est écrit dans buffer : il n y a pas de problème. Toutefois si l utilisateur passe un texte plus grand, il va d abord écrire sur cnt, puis i, puis la sauvegarde du registre esp, puis l adresse de retour dans la fonction main.

Supposons que l utilisateur mette de bonnes valeurs pour i et cnt pour que la boucle ne se termine pas prématurément, il peut alors changer l adresse de retour de la fonction, et écrire dans la suite de la pile. En écrivant ainsi dans l adresse de retour, l utilisateur peut contrôler le flux d exécution de notre programme, et demander au processeur d aller exécuter des instructions à un endroit précis en mémoire. Il suffit qu il mette une adresse où il y a des instructions dans celle de retour. Pour expliquer ce détournement du flux d exécution, il est nécessaire d expliquer ce que fait la fonction test_fonction quand elle a fini la boucle : - Elle met la valeur du registre %ebp dans le registre %esp; - Elle remet la valeur de %ebp sauvegardée dans la pile dans le registre %ebp; - Elle fait un appel à l instruction ret qui va lire l adresse dans la pile (l adresse de retour dans main pour notre cas) et demande au processeur de continuer à cette adresse (via l utilisation du registre %eip). Partant de cette possibilité pour l utilisateur de demander au processeur d aller exécuter du code à une adresse quelconque, il a deux possibilités : - Mettre du code exécutable dans la pile, et aller faire exécuter ce code dans la pile par le processeur. - Aller exécuter une fonction système, en mettant son adresse. Le premier choix n est plus possible : l espace mémoire utilisé pour la pile est accessible en lecture et écriture, mais pas en exécution. Si le processeur se retrouve sur l espace mémoire de la pile, il va lever une interruption. Mac OS X la récupère, et provoque la fin prématurée de l application. Ceci peut servir à faire une attaque de type DoS (Denial of Service), mais rien de plus. Le deuxième choix était possible, pour la simple et bonne raison que les fonctions système étaient toujours à la même adresse, sur tous les ordinateurs. Ainsi la fonction système la plus utilisée était system() qui permet d exécuter du code shell. Ce type d attaque est appelé return to libc : lorsque la fonction victime du buffer-overflow a fini son exécution, le processeur se retrouve dans une fonction de la libc.

III. Adresses aléatoires C est donc de là que vient l idée d adresses aléatoires : contrer l attaque return to libc. Le principe est très simple : lors de l installation du système ou lors de la mise à jour du prebinding des bibliothèques (typiquement lors des mises à jour système, ou lors de l exécution de la commande suivante dans un shell update_dyld_shared_cache -force ), les adresses des différentes bibliothèques système (et donc des fonctions qu elles contiennent) sont placées à des adresses aléatoires. Ainsi, il n est plus possible de faire l attaque return to libc pour la simple raison que les adresses système ne sont pas les mêmes entre différents ordinateurs. Lorsque Mac OS X Léopard charge un binaire en mémoire, il corrige alors toutes les adresses système en modifiant la table de saut : segment IMPORT, section jump_table. IV. Conclusion Du fait de la complexité croissante des applications, les attaques par buffer-overflow sont les plus courantes actuellement, car les plus difficiles à entièrement contrôler. Léopard, avec les adresses aléatoires, a enfin résolu un gros problème de sécurité très simple à mettre en œuvre. Hélas, ceci n empêche pas de faire des DoS ou de faire de l exécution aléatoire de fonctions au sein de l application. Il manque encore pour cela que les applications soient compilées par défaut avec la gestion avancée d un canari ou que Mac OS X positionne aléatoirement le binaire dans la mémoire virtuelle du processus fraîchement créé pour exécuter le binaire. Pour ce qui est de Windows, la randomisation de bibliothèque (Address Space Layout Randomization) n existe pas sous Windows XP de manière native, mais a été ajoutée dans Windows Vista.

SIGNATURE NUMÉRIQUE D APPLICATION I. Introduction Il y a un constat simple : l élément le plus dangereux du système informatique, l élément actif, à savoir le binaire contenant du code exécutable par le processeur, était jusqu à présent sans contrôle sérieux possible. Ainsi : - N importe quelle application pouvait se faire passer pour une autre et ainsi accéder à des informations potentiellement privées de cette dernière. - Il n y avait pas de consistance entre différentes versions d une même application : le système devait redemander à chaque mise à jour de l application si celle-ci était bien toujours la même. Le seul moyen de vérification était le nom et l identifiant de l application. - Il était impossible de gérer facilement les droits d accès utilisateur aux différentes applications : se baser simplement sur le nom et l identifiant n est pas une solution sûre. La signature numérique d application (connut sous le nom de code signing en Anglais) a donc fait son apparition pour régler ces problèmes, ainsi que pour apporter de nouvelles solutions dans la gestion et la vérification de code exécutable. II. Signature La signature d une application permet d'accomplir les éléments suivants : - Assurer l intégrité d un code exécutable, c est-à-dire assurer que le code n a pas été modifié après que la signature a été faite; - Identifier le code exécutable comme venant d une source précise et nominative avec certitude (le développeur ou le signataire); - Déterminer si le code exécutable est reconnu comme ayant le droit de faire certaines actions spécifiques, par exemple accéder à un élément du trousseau d accès de Mac OS X. Attention, il est assez courant que la signature numérique soit mal comprise. Effectivement, la signature d une application ne permet PAS d accomplir les éléments suivants : - Garantir que le code exécutable ne souffre d aucune vulnérabilité de sécurité

- Garantir que le programme n aille pas charger du code exécutable altéré ou non-sécurisé (comme un plug-in quelconque par exemple) - Faire un travail de Digital Rights Management (DRM) : la signature de code permet de vérifier la signature et l intégrité, mais ne permet pas d empêcher quelqu un de lancer votre application (typiquement sur un système antérieur où la signature de code n est pas reconnue, elle est simplement ignorée). La signature de code sous Mac OS X est effectuée à l aide d un certificat numérique, celui-ci peut-être : - Auto-signé : il prouvera alors que la source de la signature d un code est toujours la même, mais pas l'identité de la personne signataire. - Signé par une autorité de certification. Le certificat pourra alors prouver véritablement l identité de la personne, des démarches administratives de vérification étant faites dans ce cas. III. Création de certificat De base, tout est prévu dans Mac OS X Léopard pour générer des certificats, notamment pour la signature d application. Pour cela il faut se rendre dans l application Keychain Access Puis dans le menu Keychain Access > Certificate Assistant > Create a Certificate

La fenêtre suivante apparaît: Premier champ à remplir : le nom de notre certificat, typiquement le nom du développeur, de la société éditrice du logiciel, le nom de l entité qui met à disposition l application signée. Dans le panneau suivant, l utilisateur est invité à donner une période de validité du certificat. Typiquement, les certificats sont valides pour une année. Le type de certificat choisi est Code Signing. Puis l application demande des informations contextuelles sur le possesseur du certificat : email, localité, etc. Pour les panneaux suivants, une simple validation des informations par défaut suffit. Le certificat (qui est auto-signé) est alors créé, et une référence est mise dans la catégorie Certificates de l application Keychain Access. Un certificat peut-être créé à l aide d une autorité de certification reconnue (par exemple VerySign) en passant par le menu Request a Certificate From a Certificate Authority du menu Certificate Assistant. La génération des certificats par l utilitaire d Apple est assurée par l architecture CDSA, et plus précisément par le plug-in dédié aux certificats AppleX509CL.

IV. Commande codesign Une fois le certificat créé, il faut utiliser la commande intégrée à Mac OS X Léopard codesign pour gérer tout ce qui est signature de binaire exécutable, bundle exécutable, applications, frameworks, Usage: codesign -s identity [-fv*] [-o flags] [-r reqs] [-i ident] path... # sign codesign -v [-v*] [-R testreq] path pid... # verify codesign -d [options] path... # display contents codesign -h pid... # display hosting paths La commande codesign se base sur trois informations pour signer l application : - Un identifiant unique, qui peut être utilisé pour identifier le code ou déterminer à quel groupe ou catégorie le code exécutable appartient. Cette information peut être prise du fichier Info.plist ou spécifiée explicitement. Typiquement, cet identifiant sera du genre com.apple.pages ; - Un scellé, qui sera une collection de sommes de contrôle (checksum) ou hachages des différentes parties du programme, comme l identifiant, le fichier Info.plist, l exécutable principal, les fichiers ressources, etc. Ce scellé sera utilisé pour détecter les altérations d une ou plusieurs parties du programme; - Une signature numérique utilisée pour signer le scellé, ceci afin d en garantir l intégrité. Cette signature sera utilisée pour vérifier qui a signé et accessoirement si la signature est valide (dans le cas d une signature avec un certificat généré par une autorité de certification). Pour signer un code, dans le cas d un bundle, il suffit simplement d utiliser la commande suivante (ici l exemple avec le certificat généré plus haut) : codesign -s Julien-Pierre Avérous /Dev/MonApp/build/Release/MonApp.app La commande codesign utilise le fichier Info.plist pour obtenir les informations non spécifiées par la ligne de commande. Pour les binaires exécutables sans bundle, il est possible d ajouter un fichier Info.plist directement dans leurs structures Mach-O. Il faut ajouter la commande suivante au lieur de code ( ld par défaut) : -sectcreate TEXT info_plist /path/to/my/info.plist

Il est possible de créer des pré-requis pour le code signé. Par exemple pour spécifier que les bibliothèques utilisées par le binaire doivent être signées par Apple, l option suivante sera passée à codesign : -r="library => anchor apple" Quand codesign passe sur un bundle exécutable, il crée un fichier CodeResources et modifie le binaire exécutable principal du bundle. Quand il passe sur un simple binaire exécutable, il ne modifie que le binaire en question. Le fichier CodeResources contient le hash de tous les éléments du bundle (sauf le binaire exécutable principal) : c est une partie du scellé. Le binaire exécutable se voit ajouter une commande de chargement (ou Load Command) dans son header Mach-O : LC_CODE_SIGNATURE. Cette commande pointe sur une zone de données qui contient le hash du code exécutable pour la plate-forme concernée, des informations clef sur le certificat qui a servi à signer (notamment la clef publique) et l ensemble des pré-requis, s il y en a. La signature du code est locale à un ensemble Mach-O, et non globale à un fichier Fat. V. Action! Quand Mac OS X Léopard charge un exécutable, s il trouve une commande de chargement LC_CODE_SIGNATURE, il va faire un certain nombre de traitements : - Vérification de la légalité d exécution du binaire en fonction des pré-requis, des droits parentaux, d une éventuelle sandbox paramétrée en fonction du certificat, etc. - Vérification de l intégrité des scellés (déchiffrement avec la clef publique des scellés chiffrés avec la clef privée et comparaison des hash). Ensuite au fil de l exécution, les différents composants système vont utiliser ces informations de signature pour autoriser ou non certaines actions. Par exemple Keychain Access (via CDSA) pour autoriser ou non la restitution d un mot de passe, sans gêner l utilisateur avec un message pour lui demander l autorisation,.

VI. Conclusion La signature de code apporte une grande avancée dans la chaîne de sécurité de Mac OS X. Il permet d avoir une vraie traçabilité des applications, un contrôle plus fin sur ce qu elles ont le droit de faire et une meilleure consistance entre les différentes versions d une même application. Qui plus est, Mac OS X permet à n importe quel développeur de faire ça extrêmement facilement : il peut générer un certificat en trois clics et signer son application avec une simple commande, rien de plus compliqué. Finalement, la signature ne pose aucun problème sur les anciennes versions de MacOS X : elle y est tout simplement ignorée. Il n y a donc aucune raison de ne pas la mettre. Pour ce qui est de Windows, la signature de code est implémentée tant sous Windows XP que sous Windows Vista, sous le nom de Authenticode. C est une technologie native du système et notamment utilisée par Internet Explorer pour permettre ou non l installation d un logiciel ainsi que pour autoriser les drivers reconnus comme fiables.

CARTES À PUCES I. Introduction : Les cartes à puces peuvent servir à stocker des éléments d authentification comme des mots de passe, des certificats... Reliées à l ordinateur elles permettent à l utilisateur de ne pas avoir à saisir son mot de passe pour s authentifier sur sa machine, sur son client mail... Outre un gain de temps, les cartes à puces permettent de ne pas stocker ses mots de passe sur l ordinateur. Elles contiennent généralement un système d authentification interne, comme une empreinte digitale, permettant ainsi de sécuriser l accès à la carte elle-même. Les données stockées sont bien entendu chiffrées. Léopard intègre maintenant des services liés à l utilisation de telles cartes. Apple a mis en place un kit de développement permettant l implémentation de pilotes pour les lecteurs de cartes à puces. Le groupe de travail PC/SC (Personal Computer/Smart Card) a établi un standard pour le développement de ceux-ci. Une implémentation Open Source de ce standard existe. Elle s appelle MUSCLE pour Movement for the use of Smart Cards in Linux. Le support de cartes à puces d Apple est basé sur celle-ci. Le framework relatif à PC/SC se trouve à l emplacement suivant : /System/Library/Framework/PCSC.framework. II. Fonctionnement du service : 1. Pcscd : Le fonctionnement du service est basé sur le démon pcscd. Il coordonne la communication entre les lecteurs de cartes à puces et les applications nécessitant une authentification. Cette communication est transparente pour l application et l utilisateur. Il charge également les pilotes et les plugins nécessaires. C est par son intermédiaire que les frameworks pcsc-lite et musclecard fonctionnent. pcsc-lite est une API qui permet d effectuer la migration de logiciel PC/SC Windows vers un environnement Unix. 2. Identification : Une carte à puce est identifiée à partir de son ATR (Answer To Reset). Cet identifiant permet de charger les pilotes nécessaires qui sont situés à l emplacement suivant : /usr/libexec/ SmartCardServices/pilotes

3. Pilotes : La liste des pilotes que pcscd doit charger est fournie par le fichier /etc/reader.conf. Pour spécifier un autre fichier de configuration, le démon doit être lancé avec l option -c suivie de l'emplacement du fichier de remplacement. Le script de démarrage est situé à l emplacement suivant : /System/Library/StartupItems/SmartCardServices. Le fichier /etc/reader.conf doit respecter la syntaxe suivante : # Commentaires FRIENDLYNAME <Nom descriptif du lecteur de cartes> DEVICENAME <Nom du matériel, par défaut GEN_SMART_RDR> LIBPATH <Localisation de la bibliothèque partagée associée au pilote> CHANNELID <L identifiant hexadécimal de la fréquence de la carte, nécessaire pour les cartes à port série> Exemple : FRIENDLYNAME "My Smartcard Reader" DEVICENAME GEN_SMART_RDR LIBPATH /usr/libexec/smartcardservices/pilotes/my_reader.so CHANNELID 0x0103F8 Les pilotes sont principalement constitués d un fichier XML qui contient les informations nécessaires à l identification du vendeur et du fabricant de la carte. Des pilotes sont disponibles sur le site du projet MUSCLE : http://www.musclecard.com/pilotes.html. 4. Types de cartes : Il existe différents types de cartes à puces, à chacune de celles-ci correspond un plugin utilisé par les frameworks cités plus haut. Ces plugins sont disponibles à l emplacement suivant: /usr/libexec/smartcardservices/services. D'autres sont récupérables sur le site du projet MUSCLE.

III. Ajouter la gestion d une carte à puce dans l environnement: Pctools est ub utilitaire qui permet d ajouter la prise en charge d une nouvelle carte à puce. Sous condition que le plugin nécessaire soit disponible à l emplacement cité plus haut. Voici la démarche à suivre pour l installation d une nouvelle carte : L utilitaire pcsctool est exécuté dans un terminal. Il liste alors les différents plugins disponibles. Par exemple : Select the approprate token driver: ----------------------------------- 1. commonaccesscard.bundle 2. GSCISPlugin.bundle 3. mscmusclecard.bundle 4. slbcryptoflex.bundle ----------------------------------- Enter the number: Après avoir sélectionné le plugin correspondant à la carte, celle-ci est insérée dans le lecteur pour qu elle soit détectée. Un message informe ensuite du succès ou de l échec de la prise en charge du matériel. Si tout s est bien passé, le système est alors configuré pour utiliser la carte. IV. Obtenir des informations sur une carte à puce : 1. Introduction : Un utilitaire, pcsctest, permet de récupérer les informations relatives à une carte à puce, sous réserve que celle-ci soit prise en charge par le système. 2. Utilisation : L utilitaire est exécuté dans un terminal. pcsctest liste les différents lecteurs de cartes connectés au système et demande à l'utilisateur d en choisir un. Exemple :

MUSCLE PC/SC Lite Test Program Testing SCardEstablishContext : Command successful. Testing SCardGetStatusChange Please insert a working reader : Command successful. Testing SCardListReaders : Command successful. Reader 01: SCM SCR-331 CCID 0 0 Enter the reader number : 1 Si aucun lecteur n est connecté : MUSCLE PC/SC Lite Test Program Testing SCardEstablishContext Testing SCardGetStatusChange : Command successful. Ensuite, la carte est insérée dans le lecteur et si tout se passe bien, l utilitaire affiche les informations relatives à celle-ci. Par exemple : Waiting for card insertion : Command successful. Testing SCardConnect : Command successful. Testing SCardStatus : Command successful. Current Reader Name : CCID USB Reader 0 0 Current Reader State : 34 Current Reader Protocol : 0 Current Reader ATR Size : 9 Current Reader ATR Value : 3B E2 00 00 04 03 00 Testing SCardDisconnect : Command successful. Testing SCardReleaseContext : Command successful.

V. Critiques : La prise en charge des cartes à puces n est pas une nouveauté en soi, elle comble un manque de la version précédente du système d exploitation d Apple et lui permet d associer un argument supplémentaire pour l intégration de Léopard en entreprise. Toutefois, une interface graphique pour mettre en place la gestion des cartes à puces aurait été préférable à passage par le terminal. VI. Windows et les cartes à puces : De par sa plus forte intégration en entreprise le système de Redmond a depuis longtemps intégré le support des cartes à puces. Ainsi, depuis Windows 2000, le système de Microsoft reconnaît nativement les lecteurs de cartes à puces. Comme Mac OS X il permet l authentification système par le biais des cartes à puces, les applications Windows peuvent également utiliser la souplesse d authentification offerte par celle-ci.

COUPE-FEU I. Introduction Dans les versions précédentes de Mac OS X, le système de coupe-feu était basé sur ipfirewall, package Open Source hérité de FreeBSD. Dorénavant, Léopard a adopté un système propriétaire de coupe-feu dédié aux applications. Ce système de coupe-feu par application permet de spécifier des règles de filtrages d accès réseau propres à chaque programme. Traditionnellement, un système de coupe-feu met en place des règles de filtrage au niveau des ports réseaux, c est ce que fait ipfirewall. II. Configuration : La configuration du coupe-feu s effectue à l aide d une interface graphique. Il suffit pour cela d aller dans Préférences Système, puis dans le panneau Sécurité/Security et enfin dans l onglet Coupe-feu/Firewall

Trois modes de protection sont ensuite proposés: 1. Permettre toutes les connexions entrantes. Aucune restriction, toutes les connexions entrantes sont autorisées. 2. Permettre les connexions entrantes seulement pour les services essentiels. Seules les connexions des services suivants sont autorisées: configd, qui implémente les configurations réseau de la machine mdnsresponder, qui implémente Bonjour racoon, qui implémente IPSec. 3. Définir l accès de certains services ou applications. C est le mode de configuration le plus flexible. Les applications ou les services sur lesquels des règles d accès sont appliquées sont à sélectionner. Une fois une application ajoutée dans la liste les connexions entrantes peuvent soit être autorisées soit les bloquer. Chaque application rajoutée dans la liste est automatiquement signée. Ainsi en cas de modification de l application, l utilisateur en est informé, il lui est alors proposé de mettre à jour ses règles de filtrage. Les types de configurations 2 et 3 contiennent deux options supplémentaires qui permettent respectivement d activer la conservation de l historique des actions du coupe-feu et d activer le mode furtif qui empêche tout trafic indésirable de recevoir des réponses ou un accusé de réception pouvant indiquer la simple existence de l ordinateur. III. Amélioration de l existant : Les versions précédentes de Mac OS X incluaient ipfirewall. Avec Léopard il est toujours présent dans le système : son utilisation peut ainsi être couplée avec le système existant. Les règles définies par ipfirewall sont prioritaires par rapport à celles de coupe-feu dédiés aux applications. Malgré tout, ipfirewall n est configurable que par le terminal, il est donc recommandé d installer des applications graphiques comme WaterRoof afin de se passer du terminal. IV. Windows : Depuis Windows Xp et notamment son service pack 2, Microsoft intègre un système de parefeu proche de celui qui à été présenté.

CONCLUSION Mac OS X Léopard a fait beaucoup de progrès en terme de sécurité système et utilisateurs, ce qui lui permet de conforter son image de système sûr et à la pointe des dernières technologies. Ainsi, il peut devenir un choix possible pour des sociétés où la sécurité du système d informations dépend de celui des postes présents (voire des serveurs avec Mac OS X Léopard Server). Le choix du système d exploitation majoritaire dépendra donc de la sécurité de celuici. Il ne faut pourtant pas oublier que si Mac OS X Léopard apporte bon nombre de nouvelles techniques de sécurité, il s agit essentiellement de résorber des lacunes des versions antérieures de Mac OS X. Ces nouvelles techniques sont, depuis un certain temps déjà, présentes dans les autres systèmes du marché.

BIBLIOGRAPHIE Apple Inc., «Code Signing Guide». Cupertino : Apple Inc., 15-05-2007. Apple Inc., «Mac OS X Security». Cupertino : Apple Inc., Novembre 2007. Apple Inc., «Security Overview». Cupertino : Apple Inc., 08-02-2008. http://www.usefulsecurity.com/, Sandboxes». c-had : 08-11-2007. «Apple http://www.318.com/techjournal/, «A brief introduction to Mac OS X Sandbox Technology». 318, Inc. : 17-04-2007. http://www.trustedbsd.org/mac.html, «TrustedBSD Mandatory Access Control Framework». FreeBSD foundation. http://www.sedarwin.org/, «SEDarwin : Security Ehanced Darwin». Sparta, Inc. http://www.freebsd.org/doc/en/books/h andbook/index.html, «FreeBSD Handbook». FreeBSD Foundation. http://www.osxbook.com/, «Mac OS X Internals, A Systems Approach». Amit Singh.