Le SandBoxing sur Mac OS X.
Le terme «SandBox» est particulièrement utilisé dans le monde Linux. Il se traduit par «bac à sable» et décrit un type de protection lors de l’exécution d’un logiciel.
Voir la page WIKI : http://fr.wikipedia.org/wiki/Sandbox_(sécurité_informatique)
Imaginons un logiciel qui fonctionne sur un Mac, par défaut ce logiciel a les droits en écriture et lecture qui sont ceux de l’utilisateur qui a lancé le programme. Toujours par défaut, un utilisateur sur Mac peut écrire à volonté dans son dossier personnel (la petit maison blanche) mais dès qu’il veut modifier le contenu d’un répertoire hors de ce dossier il lui faut montrer pâte blanche et indiquer un mot de passe.
Cette approche par «compartiments» fait la force des systèmes Unix et participe à leur réputation. Dans le monde Windows les choses sont beaucoup moins claires.
Revenons sur notre exemple, notre application fonctionne sur votre Mac et un personnage mal intentionné a réussi à utiliser une faille de ce programme et le contrôle maintenant de l’extérieur. Il peut à cet instant détruire les fichiers auxquelles votre application et plus directement votre compte ont accès.
Ce genre d’attaque existe bien, certes elle ne s’applique pas en particulier aux applications lancées sur un ordinateur mais plutôt à des fonctions de» serveur» comme le serveur Internet Apache qui est livré avec Mac OS.
Une première réponse à ce type d’attaque est bien sur l’utilisation d’un «firewall», qui empêcherait l’accès de l’extérieur à ce programme. Mais quand vous mettez en place un serveur, c’est en général pour qu’il soit accessible de l’extérieur. Donc cette réponse n’est pas la plus appropriée.
Une autre solution consiste à «isoler» l’application, c’est à dire qu’elle s’exécute, mais n’a pas accès à certaines ressources de la machine. Prenons de nouveau notre exemple, cette fois imaginons que nous avons un moyen technique qui nous permet d’interdire à l’application toute écriture dans le dossier personnel de l’utilisateur ou dans une autre zone du système. Dans ce cas de figure, peut importe celui qui lance l’application, celle-ci ne peut plus écrire n’importe ou.
Ainsi donc un assaillant ayant pris possession du programme ne peut écrire et donc être nuisible. Cette technique est celle du «bac à sable» parce que l’application ou le serveur ne peut pas accéder au dehors de la zone de sécurité et ceci peu importe celui qui lance le service ou l’application.
Si les SandBox sont très communs sur Linux ou BSD, ils étaient très complexes à mettre en place sur Mac… Sauf depuis Leopard, Apple propose un solution qu’elle appelle ironiquement «SeatBelt» ou «ceinture de sécurité» (ils sont toujours très poétiques à cupertino).
Le problème de cette solution est qu’elle n’est pas documentée et Apple a raison sur ce sujet. Moins ils en diront et moins de personne tenteront de la contourner.
La solution d’Apple n’est pas inconnue des Unixiens, il s’agit de l’utilisation du framework de TrustedBSD et SELinux pour les distributions linux. A une époque Apple a essayé une version dite «SEDarwin» compatible SELinux mais a renoncé à ce projet pour se consacrer à «Seatbelt».
En pratique comment ça marche sur Mac OS X :
les applications qu’Apple a placé dans un Bac à sable sont listées dans le dossier suivant :
/usr/share/sandbox. pour en explorer le contenu dans le terminal lancez cette commande :
$ cd /usr/share/sandbox
puis
$ ls
Une partie de la liste devrait être la suivante :
bsd.sb ntpd.sb
cvmsCompAgent.sb portmap.sb
cvmsServer.sb quicklookd-job-creation.sb
fontmover.sb quicklookd.sb
kadmind.sb sshd.sb
krb5kdc.sb syslogd.sb
mDNSResponder.sb xgridagentd.sb
mds.sb xgridagentd_task_nobody.sb
mdworker.sb xgridagentd_task_somebody.sb
named.sb xgridcontrollerd.sb
Tous les fichiers portent l’extension «.sb». SURTOUT ne modifiez ni ne supprimez ces fichiers. Pour en voir le contenu tapez la commande suivante :
$ cat fontmover.sb
Ce qui affichera le contenu du fichier «fontmover.sb». Ce fichier est divisé en sections :
Dont une section du nom de « (allo file-read* «, celle-ci détermine l’espace ou le chemin dans lequel l’application peut lire de fichiers. Une autre section du nom de « (allow file-write*» précise les dossiers où peuvent être écrits des informations par l’application «fontmover.» et ainsi de suite, le bac à sable est ainsi défini.
Vous pouvez vous interroger sur l’intérêt de cette technologie pour un utilisateur, prenons un programme qui voudrait communiquer avec l’extérieur (comme «Adobe»), il n’est pas possible de leur interdire l’accès au réseau. ( Pour être honnête, il existe une solution avec le firewall IPFW embarqué dans Mac OS, mais là n’est pas le sujet).
Il est possible grâce à ce mécanisme «SeatBelt» et de« SandBoxing » de lui interdire par exemple le réseau . Pour cela l’opération est simple, j’ai pris comme exemple d’interdire à l’Utilitaire Réseau » d’accéder au réseau :
Premièrement nous allons créer un profil, c’est un simple fichier texte. Dans un éditeur de texte «texedit» ou «Bean» tapez ces trois lignes :
(version 1)
(debug deny)
(deny network*)
(allow default)
La ligne (deny Network*) indique qu’aucun accès au réseau n’est permis à l’application. Vous pouvez ajouter une ligne (deny file-write*) qui interdit l’écriture de fichiers. Vous l’aurez compris l’astérixe signifie «tout».
Enregistrez le tout sous le nom «noreseau.sb» dans votre dossier personnel.
Lancez cette commande :
$ sudo
Puis après avoir saisi votre mot de passe :
$ sandbox-exec -f ~/noreseau.sb /Applications/Utilities/Network\ Utility.app/Contents/MacOS/Network\ Utility
Il faut, si vous souhaiter placer dans un sandbox une application, récupérer son exécutable qui se trouve dans le paquet de l’application. Dans le cas de l’utilitaire réseau le chemin ets : « /Applications/Utilities/Network\ Utility.app/Contents/MacOS/Network\ Utility » .

L’application sera ouverte automatique et ne pourra accéder au réseau. Vous avez là un moyen simple d’empêcher une application d’écrire dans des fichiers ou d’accéder au réseau comme par exemple «Adobe»…
Le fait d’être dans un bac à sable ne dure que le temps ou l’application est ouverte, après sa fermeture elle redémarre hors du « sandbox ».
Le principe du Sandbox n’est pas courant, mais il semble que Google Chrome l’utilise, ceci afin de prévenir des composants qui pourraient être néfastes pour les utilisateurs de ce Butineur.
Henri Dominique Rapin
