Livre de chevet du développeur FreeBSD
Précédent	Chapitre 6. Programmation sécurisée	Suivant

6.5. Limiter l'environnement de votre programme

La méthode traditionnelle pour restreindre l'accès d'un processus se fait avec l'appel système chroot(). Cet appel système change le répertoire racine depuis lequel tous les autres chemins sont référencés pour un processus et ses fils. Pour que cet appel réussisse, le processus doit avoir exécuté (recherché) la permission dans le répertoire référencé. Le nouvel environnement environment ne prend pas effet que lorsque vous appelez chdir() dans celui-ci. Il doit être aussi noté qu'un processus peut facilement s'échapper d'un environnement chroot s'il a les privilèges du super-utilisateur. Cela devrait être accompli en créant des fichiers spéciaux de périphérique pour la mémoire du noyau, en attachant un dévermineur à un processus depuis l'extérieur de sa "prison", ou par d'autres manières créatrices.

Le comportement de l'appel système chroot() peut être un peu contrôlé avec la commande sysctl et la variable kern.chroot_allow_open_directories. Quand cette valeur est règlée à 0, chroot() échouera avec EPERM s'il y a un répertoire d'ouvert. Si la variable est règlée sur la valeur par défaut 1, alors chroot() échouera avec EPERM s'il y a un répertoire d'ouvert et que le processus est déjà sujet à un appel chroot(). Pour toute autre valeur, la vérification des répertoires ouverts sera totalement court-circuitée.

6.5.1. La fonctionnalité "prison" de FreeBSD

Le concept de Prison ("Jail") étend chroot() en limitant les droits du super-utilisateur pour créer un véritable `serveur virtuel'. Une fois qu'une prison est mise en place, toute communication réseau doit avoir lieu au travers de l'adresse IP spécifiée, et le droit du "privilège super-utilisateur" dans cette prison est sévèrement gêné.

Tant qu'il se trouve en prison, tout test avec les droits du super-utilisateur dans le noyau au travers d'un appel à suser() échouera. Toutefois, quelques appels à suser() ont été changés par la nouvelle interface suser_xxx(). Cette fonction est responsable de fournir ou de retirer les accès aux droits du super-utilisateur pour les processus emprisonnés.

Un processus super-utilisateur dans un environnement emprisonné a le pouvoir de :

Manipuler les identitifications avec setuid, seteuid, setgid, setegid, setgroups, setreuid, setregid, setlogin
Règler les limites en ressources avec setrlimit
Modifier quelques variables du noyau par sysctl (kern.hostname)
chroot()
Règler les paramètres d'un noeud virtuel (vnode): chflags, fchflags
Règler les attributs d'un noeud virtuel comme les permissions d'un fichier, le propriétaire, le groupe, la taille, la date d'accès, et la date de modification.
Se lier à des ports privilégiés sur Internet (ports < 1024)

Jail est un outil très utile pour exécuter des applications dans un environnement sécurisé mais il a des imperfections. Actuellement, les mécanismes IPC (Inter-Process Communications) n'ont pas été convertis pour utiliser suser_xxx aussi des applications comme MySQL ne peuvent être exécutée dans une prison. L'accès super-utilisateur peut avoir un sens très limité dans une prison, mais il n'y aucune façon de spécifier exactement ce que très limité veut dire.

6.5.2. Les capacitès des processus POSIX.1e

Posix a réalisé un document de travail qui ajoute l'audit d'évènement, les listes de contrôle d'accès, les privilèges fins, l'étiquetage d'information, et le contrôle d'accès mandaté.

Il s'agit d'un travail en cours et c'est l'objectif du projet TrustedBSD. Une partie du travail initial a été intégré dans FreeBSD-current (cap_set_proc(3)).

Précédent	Sommaire	Suivant
Les problèmes liés à SetUID	Niveau supérieur	La confiance