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.
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.
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 |
Ce document, ainsi que d'autres peut être téléchargé sur ftp.FreeBSD.org/pub/FreeBSD/doc/.
Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.