Bienvenue Gérard ! Aujourd’hui, nous allons sécuriser notre système. Nous allons pour cela utiliser systrace qui va nous permettre de surveiller les appels système effectués par les programmes, d’établir des règles et de faire plein de choses rigolotes avec tes cheveux. Ce cours utilisera l’OS à la serviette orange, mais tout ce qui est écrit ici est valide pour les adorateurs de Puffy. Il n’y a malheureusement pas de tresses pour l’OS à la petite boule rouge. Un projet de portage avait commencé, mais il n’a pas été maintenu. Mais comme dirait Vitoo, jamais 2 sans 3, alors peut-être qu’un jour le projet recommencera.

Six tresses

Pour sécuriser un système Unix, il y a plusieurs moyens, parmi lesquels : les permissions sur les fichiers (y compris les bits SUID/SGID), la délégation de pouvoirs avec calife ou sudo. Il t’est peut-être arrivé, mon petit Gérard, de t’arracher les cheveux car la granularité offerte par ces solutions n’était pas assez fine. J’ai la solution à tes problèmes : systrace(4). Grâce à cet outil, il est possible de contrôler les appels système autorisés pour chaque programme installé. Il est découpé en plusieurs parties : les politiques, un outil de génération de politiques, un wrapper pour appliquer les politiques ainsi qu’une interface d’administration. Nous allons découvrir comment sécuriser un serveur afin d’éviter qu’une faille de sécurité ne permette à un méchant pirate d’exécuter n’importe quoi sur notre belle machine, et d’empêcher nos chers utilisateurs de retourner le système ; et si jamais tu n’es pas sage je te jetterai dans une cage. Tu es prévenu. Maintenant, va te laver les cheveux avant que l’on commence.

Le shampooing

Avant toute chose, nous allons voir comment systrace(4) fonctionne. Pour qu’il puisse contrôler les appels système, il doit être utilisé comme un wrapper pour chaque commande exécutée, par exemple : Comme tu peux le remarquer, il y a un répertoire .systrace dans le home de l’utilisateur. Il contient les politiques appliquées à chaque commande que l’utilisateur lance. Bien entendu, ces politiques peuvent être centralisées par l’administrateur dans le répertoire /etc/systrace. Chaque politique se rapporte à une et une seule commande et se présente sous la forme d’un banal fichier de la forme chemin_vers_le_binaire. Regardons d’un peu plus près le contenu d’une politique : Le fichier a une structure facilement compréhensible. Tout d’abord le binaire auquel s’applique la politique, le type d’émulation qui peut être "native" pour OpenBSD, "NetBSD" ou encore "Linux". Suit la liste des appels système traités et les règles attachées. On autorise le binaire à effectuer les appels à mmap ou munmap qui concernent l’allocation de blocs mémoire (sinon, ça va marcher beaucoup moins bien), la lecture de certains fichiers (les bibliothèques auxquelles le programme fait appel par exemple), ainsi que tous les appels nécessaires à son bon fonctionnement. Je te sens un peu anxieux mon petit, tu dois te dire qu’il faut connaître la totalité des appels système et des bibliothèques utilisées par chaque programme que tu veux sécuriser, que tu vas passer des journées, des semaines, des mois à écrire tes politiques ! Relaxe-toi, respire un bon coup, lis le man de systrace(8), tu te rendras compte qu’il existe l’option magique -A qui permet de construire une politique de base que tu pourras modifier par la suite.

On rince gratis

Nous allons nous attaquer à la sécurisation d’un service réseau. Pour cela, prenons un serveur codé avec les pieds et montrons comment empêcher Jean-Kevin et ses amis de faire n’importe quoi avec. Cet exemple est factice, car, bien entendu, les programmes utilisés dans les environnements de production ne contiennent pas de failles de ce genre, hein ! Mais que se passe-t-il si une personne malveillante tente un : Catastrophe Gérard, les arguments passés au serveur ne sont pas vérifiés correctement et il est possible d’exécuter des commandes système ! Sécurisons tout ça, si tu le veux bien. Une méthode pour arriver à une politique convenable en matière à la fois de sécurité et de maintenabilité est la suivante : lancer sur le serveur l’application à partir du générateur de politique de systrace(8), exécuter un client depuis un poste distant et lui faire dérouler un scénario nominal, puis ajouter à la main les règles qui viendraient à manquer : Maintenant que nous avons notre politique de base, nous allons pouvoir empêcher que le pire n’arrive. Jetons un œil au fichier produit : Sans avoir vu le code du serveur, on peut tout de suite comprendre d’où vient la faille, le programme concatène l’entrée du client à la chaîne de caractères /bin/echo et la fait exécuter par le shell sans faire de vérification. Le générateur de politiques de systrace(8) a donc créé 2 autres politiques, stockées elles aussi dans /root/.systrace, mais nous ne les modifions pas pour l’instant, la faille ne vient pas d’elles. Pour couvrir tous les cas d’utilisation du serveur, nous allons rajouter les lignes suivantes : À noter dans ces règles la finesse des permissions, sur le binaire ainsi que sur ses arguments, mais aussi sur les mots clés ; eq signifie une égalité stricte, match une correspondance sur une partie d’une chaîne de caractères et re permet d’utiliser les expressions rationnelles. Dans notre cas, nous avons besoin d’une égalité stricte sur le binaire et une expression rationnelle est idéale pour le choix des votes. Vérifions notre politique au travers d’un test en activant systrace(8) avec écriture dans les logs de toutes les opérations interdites. On voit alors apparaître dans les logs : Lorsque nous avons généré la politique pour jardin_academy, chaque commande exécutée par le binaire s’est vue attribuer une politique par la même occasion. Comme le shell /bin/sh n’est pas la faille, nous allons modifier sa politique pour que le shell puisse utiliser librement echo. On édite le fichier de politiques bin_sh : Nous sommes prêts à affronter de nouveau Jean-Kevin, qu’il tente de nous attaquer, qu’on rigole un peu ! La même attaque que précédemment, à savoir 1; nc -l -p 31337 -e /bin/sh est bloquée. On voit dans les logs : Jean-Kevin peut alors essayer ses sploitZ sur ton serveur pendant que tu fumes ton café, il n’arrivera à rien. Nous avons réussi à combler une faille de sécurité sans appliquer de patch, sans besoin d’un IPS quelconque, bref la totale moule frite !

Bien court sur les oreilles et la nuque

Tu as sécurisé tes services réseau, c’est bien, mais tu as des utilisateurs locaux qui ont un shell sur ton serveur (sous prétexte qu’ils sont étudiants et qu’ils ont des TP à faire, la vieille ruse) et tu ne voudrais pas qu’ils se servent de ton serveur pour faire des choses inavouables... Nous allons devoir faire tourner un shell via systrace(8). Jose Nazario a même écrit un parchemin pour nous faciliter la vie : stsh [1]. Suivons les instructions disponibles sur la page écrite par Jose, compilons stsh et copions-le dans /bin. On rajoute une classe systrace dans login.conf : Puis, on ajoute un premier utilisateur pour faire nos tests en précisant la classe dans laquelle il doit être : Comme l’indique la documentation, il faut déjà des politiques en place pour que l’utilisateur puisse se connecter et exécuter des commandes. On trouve des politiques pour quelques shells et outils de base dans l’archive de stsh, politiques fonctionnelles sur OpenBSD, car elles utilisent l’émulation native. Gérard, il va falloir que tu crées tes politiques avec systrace -A pour chaque outil que tes utilisateurs devront utiliser. Nous nous concentrerons ici uniquement sur le shell utilisateur bash, shell assez répandu. Partons de la politique de base suivante : Quelques explications avant de continuer : le shell, comme tout autre programme, a besoin de bibliothèques, exécute des appels système, ici il lit aussi des fichiers de configuration dans /etc ou dans $HOME. La valeur ajoutée de ce template se situe au niveau des lignes concernant les répertoires de $PATH. Nous avons mis en place un mécanisme qu’on peut appeler TPE (Trusted Path Execution). Seuls les binaires situés dans les répertoires explicitement autorisés à être lus sont accessibles à l’utilisateur. Ici notre template est large, pour ne pas dire laxiste, les utilisateurs d’un système n’ont normalement pas besoin d’accéder aux binaires se trouvant dans /sbin, /usr/sbin ou encore /usr/local/sbin, les programmes s’y trouvant étant dédiés à root. Nous allons donc enlever les lignes concernant ces répertoires pour les appels système fsread et execve. Maintenant, si un utilisateur tente d’exécuter une commande située dans un de ces répertoires, il obtiendra un message d’erreur : La différence entre les 2 messages d’erreur s’explique par le fait que, dans le premier cas, c’est l’accès au répertoire /sbin qui est refusé alors que, dans le second cas, c’est l’exécution du binaire lui même qui est refusée. Jetons un coup d’œil à nos logs : 1ère tentative d'exécution : 2ème tentative : on a tenté de faire une complétion automatique du shell qui a échouée, la preuve avec les 2 lignes ci-dessous : On a ensuite entré le nom du binaire en toutes lettres pour l'exécuter, refus du système. Magnifique, Gérard, n’est-ce pas ? Maintenant, il te reste à faire les politiques pour les commandes que tes utilisateurs exécuteront. C’est long et dur, je ne le sais que trop bien, mais quel bonheur quand tout marche !

Six gels

Maintenant Gérard, tu n’es pas sans savoir que FreeBSD dispose d’un appel système particulier, jail(), qui permet de créer des machines virtuelles. L’idée de départ est de pouvoir donner les droits root à quelqu’un sur une partition du système, sans qu’il ne puisse être root du système lui-même en posant des restrictions sur la portée des requêtes. Cet appel système n’a été implémenté ni dans NetBSD ni dans OpenBSD, mais rassure-toi, des petits malins ont eu une idée : utiliser systrace(4) pour faire le boulot. Le projet a été astucieusement nommé sysjail [2]. Je te propose de monter notre petite cage et d’y accéder à distance avec OpenSSH. Tout d’abord, on récupère sur le site des auteurs le package pour son OS, que ce soit la serviette orange ou le poisson qui pique. Une fois installé, il nous reste à créer la base. Pour cela, un script shell est fourni : Le système de base installé et le rc.conf écrit, nous terminons la configuration en ajoutant une adresse IP sur l’interface externe de la machine hôte pour pouvoir joindre notre cage de l’extérieur. Enfin, on démarre notre jail pour voir la magie opérer : Notre cage se lance correctement. Pour le vérifier utilisons sjls(8) : On récupère le jail ID dans la première colonne. Cet identifiant va nous servir à passer des commandes à notre cage depuis la machine hôte, à l’aide de sysjail-cmd(8) : Dans le terminal où on a lancé la cage, on voit apparaître la sortie de la commande : Passons aux choses sérieuses : la mise en place d’un sshd(8) dans notre cage. Nous avons toujours notre alias IP et il reste à faire binder correctement le sshd(8) de la machine hôte et de notre jail. La configuration par défaut du démon le fait écouter sur INADDR_ANY, autrement dit 0.0.0.0 ou encore toutes les interfaces de ta machine, ce qui comprend évidemment notre alias IP. Corrigeons tout ça en éditant le /etc/ssh/sshd_config de la machine hôte : Ensuite, on édite le même fichier, mais dans l’arborescence de la cage. On aura pris soin auparavant d’activer sshd(8) dans le rc.conf : Enfin, avant de pouvoir goûter aux joies du ssh, il faut créer les devices nécessaires au bon fonctionnement de notre jail en lançant le script MAKEDEV. Et voilà, Gérard, nos efforts sont récompensés, nous pouvons nous enfermer dans notre cage, y faire des choses sales, le système hôte n’en souffrira pas !

Thèse, antithèse, Thérèse

C’est fini pour aujourd’hui, Gérard, j’espère te revoir bientôt dans le monde merveilleux des BSD libres, car tu le vaux bien. N’hésite pas à t’enfermer dans des cages pendant de longues heures et à te faire de belles tresses avec ta magnifique chevelure. Après tout, tu as ta liberté d’expression capillaire !

Références

[1] http://monkey.org/~jose/software/stsh/stsh-0.3.1.tar.gz [2] http://sysjail.bsd.lv/