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>.