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 :
shaddai@booyaka:~$ systrace /bin/ls -a . .ssh stsh-0.3.1 .. .systrace stsh-0.3.1.tar.gz
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 :
Policy: /bin/ls, Emulation: netbsd
netbsd-mmap: permit
netbsd-fsread: filename eq "/etc/ld.so.conf" then permit
netbsd-__fstat13: permit
netbsd-close: permit
netbsd-munmap: permit
netbsd-fsread: filename eq "/lib/libc.so.12.128.2" then permit
netbsd-issetugid: permit
netbsd-ioctl: permit
netbsd-getuid: permit
netbsd-__sysctl: permit
netbsd-fsread: filename eq "/etc/malloc.conf" then permit
netbsd-break: permit
netbsd-fsread: filename eq "/home/shaddai/." then permit
netbsd-fcntl: permit
netbsd-fchdir: permit
netbsd-fstatvfs1: permit
netbsd-lseek: permit
netbsd-getdents: permit
netbsd-write: permit
netbsd-exit: permit
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 !
client@gentil:~$ nc 172.20.0.2 4242
Qui doit partir du jardin ? Votez !
1. hotbox
2. shaddai
3. pinpin
4. obiwan kenobi
1
Votre vote a été pris en compte, merci.
Mais que se passe-t-il si une personne malveillante tente un :
LordZofDarkness@www.fbi.gov:~$ nc 172.20.0.2 4242
Qui doit partir du jardin ? Votez !
1. hotbox
2. shaddai
3. pinpin
4. obiwan kenobi
1; nc -l -p 31337 -e /bin/sh
Votre vote a été pris en compte, merci.
LordZofDarkness@www.fbi.gov:~$ nc 172.20.0.2 31337
uname -a;
NetBSD booyaka 3.1 NetBSD 3.1 (GENERIC) #0: Tue Oct 31 04:27:07 UTC 2006 builds@b0.netbsd.org:/home/builds/ab/netbsd-3-1-RELEASE/i386/200610302053Z-obj/home/builds/ab/netbsd-3-1-RELEASE/src/sys/arch/i386/compile/GENERIC i386
id;
uid=0(root) gid=0(wheel) groups=0(wheel),2(kmem),3(sys),4(tty),5(operator),20(staff),31(guest)
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 :
coté serveur :
# systrace -A /usr/local/bin/jardin_academy
côté client :
client@gentil:~$ nc 172.20.0.2 4242
Qui doit partir du jardin ? Votez !
1. hotbox
2. shaddai
3. pinpin
4. obiwan kenobi
1
Maintenant que nous avons notre politique de base, nous allons pouvoir empêcher que le pire n’arrive. Jetons un œil au fichier produit :
Policy: /usr/local/bin/jardin_academy, Emulation: netbsd
netbsd-mmap: permit
netbsd-fsread: filename eq "/etc/ld.so.conf" then permit
netbsd-__fstat13: permit
netbsd-close: permit
netbsd-munmap: permit
netbsd-fsread: filename eq "/lib/libc.so.12.128.2" then permit
netbsd-__sysctl: permit
netbsd-fsread: filename eq "/etc/malloc.conf" then permit
netbsd-break: permit
netbsd-socket: sockdom eq "AF_INET" and socktype eq "SOCK_STREAM"
then permit
netbsd-setsockopt: permit
netbsd-bind: sockaddr eq "inet-[0.0.0.0]:4242" then permit
netbsd-listen: permit
netbsd-accept: permit
netbsd-write: permit
netbsd-read: permit
netbsd-ioctl: permit
netbsd-__sigaction_sigtramp: permit
netbsd-__sigprocmask14: permit
netbsd-__vfork14: permit
netbsd-execve: filename eq "/bin/sh" and argv eq "sh -c /bin/echo 1
>> /tmp/votes" then permit
netbsd-wait4: permit
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 :
netbsd-execve: filename eq "/bin/sh" and argv re "sh -c /bin/echo [1-4] >> /tmp/votes" then permit netbsd-exit: permit
À 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.
côté serveur # systrace -a /usr/local/bin/jardin_academy
côté client :
Qui doit partir du jardin ? Votez !
1. hotbox
2. shaddai
3. pinpin
4. obiwan kenobi
2
Votre vote a été pris en compte, merci.
On voit alors apparaître dans les logs :
Feb 25 10:51:40 booyaka systrace: deny user: root, prog: /bin/sh, pid: 621(1)[574], policy: /bin/sh, filters: 27, syscall: netbsd-execve(59), filename: /bin/echo, argv: /bin/echo 2
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 :
netbsd-execve: filename eq "/bin/echo" then permit
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 :
Feb 25 11:04:22 booyaka systrace: deny user: root, prog: /usr/local/bin/jardin_academy, pid: 603(0)[653], policy: /usr/local/bin/jardin_academy, filters: 22, syscall: netbsd-execve(59), filename: /bin/sh, argv: sh -c /bin/echo 1;nc -l -p 31337 -e /bin/sh >> /tmp/votes
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 :
systrace:\
:shell=/bin/stsh:\
:tc=default:
default:
Puis, on ajoute un premier utilisateur pour faire nos tests en précisant la classe dans laquelle il doit être :
# useradd -L systrace gerard
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 :
Policy: /usr/pkg/bin/bash, Emulation: netbsd
netbsd-mmap: permit
netbsd-fsread: filename eq "/etc/ld.so.conf" then permit
netbsd-__fstat13: permit
netbsd-close: permit
netbsd-munmap: permit
netbsd-fsread: filename eq "/usr/pkg/lib/libreadline.so.5.0.2"
then permit
netbsd-fsread: filename eq "/usr/pkg/lib/libhistory.so.5.0.2"
then permit
netbsd-fsread: filename eq "/usr/pkg/lib/libtermcap.so.0" then
permit
netbsd-fsread: filename eq "/usr/lib/libtermcap.so.0" then
permit
netbsd-fsread: filename eq "/usr/pkg/lib/libintl.so.0" then
permit
netbsd-fsread: filename eq "/usr/lib/libintl.so.0" then permit
netbsd-fsread: filename eq "/usr/pkg/lib/libc.so.12" then
permit
netbsd-fsread: filename eq "/usr/lib/libc.so.12" then permit
netbsd-__sigprocmask14: permit
netbsd-fswrite: filename eq "/dev/tty" then permit
netbsd-issetugid: permit
netbsd-__sysctl: permit
netbsd-break: permit
netbsd-getuid: permit
netbsd-getgid: permit
netbsd-geteuid: permit
netbsd-getegid: permit
netbsd-getgroups: permit
netbsd-gettimeofday: permit
netbsd-ioctl: permit
netbsd-__sigaction_sigtramp: permit
netbsd-fsread: filename eq "/etc/nsswitch.conf" then permit
netbsd-read: permit
netbsd-fsread: filename eq "/usr/pkg/lib/nss_compat.so.0" then
permit
netbsd-fsread: filename eq "/usr/lib/nss_compat.so.0" then
permit
netbsd-fsread: filename eq "/usr/pkg/lib/nss_nis.so.0" then
permit
netbsd-fsread: filename eq "/usr/lib/nss_nis.so.0" then permit
netbsd-fsread: filename eq "/usr/pkg/lib/nss_files.so.0" then
permit
netbsd-fsread: filename eq "/usr/lib/nss_files.so.0" then
permit
netbsd-fsread: filename eq "/usr/pkg/lib/nss_dns.so.0" then
permit
netbsd-fsread: filename eq "/usr/lib/nss_dns.so.0" then permit
netbsd-fsread: filename eq "/etc/pwd.db" then permit
netbsd-fsread: filename eq "/etc/spwd.db" then permit
netbsd-fsread: filename match "/usr/share/*" then permit
netbsd-fcntl: permit
netbsd-pread: permit
netbsd-__getcwd: permit
netbsd-getpid: permit
netbsd-getppid: permit
netbsd-getpgrp: permit
netbsd-dup: permit
netbsd-getrlimit: permit
netbsd-dup2: permit
netbsd-pipe: permit
netbsd-fsread: filename eq "/usr/share/misc/termcap.db" then
permit
netbsd-fsread: filename eq "/etc/inputrc" then permit
netbsd-fsread: filename eq "/etc/profile" then permit
netbsd-fsread: filename eq "$HOME" then permit
netbsd-fsread: filename match "$HOME/*" then permit
netbsd-fsread: filename eq "/var/mail/$USER" then permit
netbsd-write: permit
netbsd-fsread: filename eq "/" then permit
netbsd-fstatvfs1: permit
netbsd-lseek: permit
netbsd-getdents: permit
netbsd-fsread: filename match "$HOME/bin/*" then permit
netbsd-fsread: filename match "/bin/*" then permit
netbsd-fsread: filename match "/sbin/*" then permit
netbsd-fsread: filename match "/usr/bin/*" then permit
netbsd-fsread: filename match "/usr/sbin/*" then permit
netbsd-fsread: filename match "/usr/pkg/bin/*" then permit
netbsd-fsread: filename match "/usr/X11R6/bin/*" then permit
netbsd-fsread: filename match "/usr/local/bin/*" then permit
netbsd-fsread: filename match "/usr/local/sbin/*" then permit
netbsd-execve: filename match "$HOME/bin/*" then permit
netbsd-execve: filename match "/bin" then permit
netbsd-execve: filename match "/sbin/*" then permit
netbsd-execve: filename match "/usr/bin/*" then permit
netbsd-execve: filename match "/usr/sbin/*" then permit
netbsd-execve: filename match "/usr/pkg/bin/*" then permit
netbsd-execve: filename match "/usr/X11R6/bin/*" then permit
netbsd-execve: filename match "/usr/local/bin/*" then permit
netbsd-fork: permit
netbsd-setpgid: permit
netbsd-setpgid: permit
netbsd-wait4: permit
netbsd-compat_16___sigreturn14: permit
netbsd-fswrite: filename eq "$HOME/.bash_history" then permit
netbsd-fswrite: filename eq "$HOME/.bash_logout" then permit
netbsd-exit: permit
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 :
bash-2.05b$ ifconfig bash: ifconfig: command not found bash-2.05b$ /sbin/ifconfig bash: /sbin/ifconfig: Operation not permitted bash-2.05b$
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 :
Mar 4 18:05:42 booyaka systrace: deny user: gerard, prog: /usr/pkg/bin/bash, pid: 471(0)[0], policy: /usr/pkg/bin/bash, filters: 79, syscall: netbsd-fsread(278), filename: /<non-existent filename>: /home/gerard/bin/ifconfig Mar 4 18:05:42 booyaka systrace: deny user: gerard, prog: /usr/pkg/bin/bash, pid: 471(0)[0], policy: /usr/pkg/bin/bash, filters: 79, syscall: netbsd-fsread(278), filename: /sbin/ifconfig Mar 4 18:05:42 booyaka systrace: deny user: gerard, prog: /usr/pkg/bin/bash, pid: 471(0)[0], policy: /usr/pkg/bin/bash, filters: 79, syscall: netbsd-fsread(278), filename: /usr/sbin/ifconfig Mar 4 18:05:42 booyaka systrace: deny user: gerard, prog: /usr/pkg/bin/bash, pid: 471(0)[0], policy: /usr/pkg/bin/bash, filters: 79, syscall: netbsd-fsread(278), filename: /usr/pkg/sbin/ifconfig Mar 4 18:05:43 booyaka systrace: deny user: gerard, prog: /usr/pkg/bin/bash, pid: 471(0)[0], policy: /usr/pkg/bin/bash, filters: 79, syscall: netbsd-fsread(278), filename: /usr/games/ifconfig Mar 4 18:05:43 booyaka systrace: deny user: gerard, prog: /usr/pkg/bin/bash, pid: 471(0)[0], policy: /usr/pkg/bin/bash, filters: 79, syscall: netbsd-fsread(278), filename: /usr/local/sbin/ifconfig
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 :
Mar 4 18:07:06 booyaka systrace: deny user: gerard, prog: /usr/pkg/bin/bash, pid: 471(0)[0], policy: /usr/pkg/bin/bash, filters: 79, syscall: netbsd-fsread(278), filename: /sbin Mar 4 18:07:06 booyaka systrace: deny user: gerard, prog: /usr/pkg/bin/bash, pid: 471(0)[0], policy: /usr/pkg/bin/bash, filters: 79, syscall: netbsd-fsread(278), filename: /sbin
On a ensuite entré le nom du binaire en toutes lettres pour l'exécuter, refus du système.
Mar 4 18:07:09 booyaka systrace: deny user: gerard, prog: /usr/pkg/bin/bash, pid: 505(0)[471], policy: /usr/pkg/bin/bash, filters: 79, syscall: netbsd-execve(59), filename: /sbin/ifconfig, argv: /sbin/ifconfig Mar 4 18:07:09 booyaka systrace: deny user: gerard, prog: /usr/pkg/bin/bash, pid: 505(0)[471], policy: /usr/pkg/bin/bash, filters: 79, syscall: netbsd-fsread(278), filename: /sbin/ifconfig Mar 4 18:07:09 booyaka systrace: deny user: gerard, prog: /usr/pkg/bin/bash, pid: 505(0)[471], policy: /usr/pkg/bin/bash, filters: 79, syscall: netbsd-fsread(278), filename: /sbin/ifconfig
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 :
# mksysjail-base -s ftp.fr.netbsd.org\ /pub/NetBSD/NetBSD-`uname -r`/`uname -m`/binary/sets /usr/jails/jail1
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 :
booyaka# sysjail --cmd-enable -i /usr/jails/jail1 cage 172.20.0.3 /bin/sh /etc/rc 700796917 Sun Mar 4 11:50:19 UTC 2007 Checking for botched superblock upgrades: done. Starting file system checks: mount: /: unknown special file or file system. Setting tty flags. ttyflags: open /dev/console: No such file or directory Setting sysctl variables: Starting network. route: socket: Protocol not supported ifconfig: SIOCGIFFLAGS lo0: Operation not permitted route: socket: Protocol not supported ifconfig: SIOCGIFFLAGS ne2: Operation not permitted ifconfig: SIOCGIFFLAGS lo0: Operation not permitted Configuring network interfaces:. Building databases... install: /var/run/utmp: chflags: Operation not permitted install: /var/run/utmpx: chflags: Operation not permitted Starting syslogd. Checking for core dump... savecore: /netbsd: kvm_openfiles: /dev/mem: No such file or directory Mounting all filesystems... Clearing /tmp. Creating a.out runtime link editor directory cache. Checking quotas: done. Starting virecover. Starting local daemons:. Updating motd. sendmail: /etc/mail/aliases.db not present, generating WARNING: local host name (cage) is not qualified; see cf/README: WHO AM I? /etc/mail/aliases: 22 aliases, longest 10 bytes, 246 bytes total Starting sendmail. Starting inetd. Starting cron. Sun Mar 4 11:50:22 UTC 2007
Notre cage se lance correctement. Pour le vérifier utilisons sjls(8) :
booyaka# sjls
JID IP Address Hostname Path
700796917 172.20.0.3 cage /usr/jails/jail1
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) :
booyaka# sysjail-cmd -p /var/run/sj-700796917 exec ps ax Started child: 1310.
Dans le terminal où on a lancé la cage, on voit apparaître la sortie de la commande :
PID TTY STAT TIME COMMAND 1177 ? Sxs 0:00.03 sendmail: accepting connections 1469 ? Ixs 0:00.01 /usr/sbin/inetd -l 1565 ? Ixs 0:00.01 /usr/sbin/syslogd -s 1788 ? Ixs 0:00.01 /usr/sbin/cron 1310 pts/0 Rx+ 0:00.08 ps ax
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 :
ListenAddress 172.20.0.3 # pas de listen sur le loopback, il est partagé avec 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 :
ListenAddress 172.20.0.3 # pas de listen sur le loopback, il est partagé avec la machine hôte !
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/
