Nom

capabilities - Présentation des capacités Linux.

Description

Pour vérifier les permissions, les implémentations Unix traditionnelles distinguent deux catégories de processus : Les processus privilégiés (dont l'UID effectif est nul, appelés Super-Utilisateur, ou root), et et les processus non-privilégiés (dont l'UID effectif est non-nul). Les processus privilégiés contournent les vérifications de permissions du noyau, alors que les processus non-privilégiés sont soumis à une vérification complète basée sur l'identification du processus (habituellement : UID effectif, GID effectif, et liste des groupes). À partir du noyau 2.2, Linux propose un mécanisme (encore impcomplet) de capacités , qui scinde les privilèges traditionnement associés au Super-utilisateur en unités distinctes que l'on peut activer ou inhiber individuellement.

Liste des capacités

Sous Linux 2.4.20, les capacités suivantes sont implémentées :
CAP_CHOWN

Permet de modifier arbitrairement les UID et GID des fichiers (voir chown (2)).

CAP_DAC_OVERRIDE

Contourne les permissions de lecture, écriture et exécution. (DAC = "discretionary access control", contrôle d'accès à volonté).

CAP_DAC_READ_SEARCH

Contourne les permissions de lecture de fichiers et celles de lecture et exécution des répertoires.

CAP_FOWNER

Contourne les vérifications pour les opérations qui demandent que le FS-UID du processus corresponde à l'UID du fichier (par exemple utime (2)), à l'exclusion des opérations couvertes par les CAP_DAC_OVERRIDE et CAP_DAC_READ_SEARCH ; Ignorer le bit sticky pour supprimer un fichier.

CAP_FSETID

Ne pas effacer les bits Set-UID et Set-GID quand un fichier est modifié ; autoriser le positionnement du bit Set-GID sur un fichier dont le GID ne correspond à aucun GID du processus appelant.

CAP_IPC_LOCK

Permer le verrouillage de page mémoire ( mlock (2), mlockall (2), shmctl (2)).

CAP_IPC_OWNER

Contourne les vérifications pour les opérations sur les IPC Système V.

CAP_KILL

Contourne les vérifications pour l'émission de signaux (voir kill (2)).

CAP_LEASE

(Depuis Linux 2.4) Autorise la demande de bail sur n'importe quel fichier (voir fcntl (2)).

CAP_LINUX_IMMUTABLE

Autorise le positionnement des attributs étendus EXT2_APPEND_FL et EXT2_IMMUTABLE_FL du système de fichiers ext2 .

CAP_MKNOD

(Depuis Linux 2.4) Autorise la création de fichiers spéciaux avec mknod (2).

CAP_NET_ADMIN

Permet certaines opérations résaeu (par ex. obtenir des options privilégiées sur les sockets, activer le multicast, configurer les interfaces, modifier les tables de routage).

CAP_NET_BIND_SERVICE

Autorise l'attachement d'une socket sur un port réservé (numéro de port inférieur à 1024).

CAP_NET_BROADCAST

(Inutilisé) Permet le broadcast et l'écoute multicast sur les sockets.

CAP_NET_RAW

Autorise l'utilisation des sockets RAW et PACKET.

CAP_SETGID

Accès toute les manipulations des GID du processus et de la liste de groupes supplémentaires, permet l'utilisation de faux GID sur les socket Unix.

CAP_SETPCAP

Autorise le transfert de toutes capacités de l'ensemble des capacités autorisées de l'appelant à partir ou vers n'importe quel processus.

CAP_SETUID

Permer la manipulation arbitraire des UID du processus ( setuid (2)...) permet de transmettre un faux UID sur une socket dans le domaine Unix.

CAP_SYS_ADMIN

Autorise un ensemble d'opérations d'aministration système, comprenant : quotactl (2), mount (2), swapon (2) , sethostname (2), setdomainname (2), IPC_SET et IPC_RMID sur n'importe quel objet IPC Système V ; permet d'utiliser un faux UID pour les authentifications des sockets.

CAP_SYS_BOOT

Autorise l'appel reboot (2).

CAP_SYS_CHROOT

Autorise l'appel chroot (2).

CAP_SYS_MODULE

Permet le chargement ou le déchargement de modules du noyaux ; permet la modification des limitations de capacités.

CAP_SYS_NICE

Autorise la diminution de la courtoisie ( nice (2), setpriority (2)) et la modification de la valeur de courtoisie de n'importe quel processus ; autorise l'utilisation des ordonnancements temps-réel pour le processus appelant, et la modification de l'ordonnancement de n'importe quel processus. ( sched_setscheduler (2), sched_setparam (2)).

CAP_SYS_PACCT

Autorise l'appel acct (2).

CAP_SYS_PTRACE

Permet de suivre n'importe quel processus avec ptrace (2)

CAP_SYS_RAWIO

Autorise les opérations d'entrées/sorties ( iopl (2) et ioperm (2)).

CAP_SYS_RESOURCE

Permet : l'utilisation de l'espace réservé sur un système ext2 ; l'appel ioctl (2) pour configurer la journalisation ext3 ; le dépassement des quotas de disque ; l'augmentation des limites de ressources (voir setrlimit (2)); la surcharge de la limite RLIMIT_NPROC ; l'augmentation de la limite msg_qbytes pour une file de messages au-dessus de la limite dans /proc/sys/kernel/msgmnb (voir msgop (2) et msgctl (2)).

CAP_SYS_TIME

Autorise la modification de l'heure système ( settimeofday (2), adjtimex (2)) ; permet la modification de l'horloge temps-réel (matérielle).

CAP_SYS_TTY_CONFIG

Autorise l'appel de vhangup (2).

Capacités dun processus

Chaque processus a trois ensembles contenant zéro ou plus des capacités ci-dessus :
Effectif :

Les capacités utilisées par le noyau pour vérifier les permissions du processus.

Autorisé :

Les capacités auxquelles le processus peut accéder (un sur-ensemble limite pour les ensembles effectif et héritable). Si un processus supprime une capacité de son ensemble autorisé, il ne plus jamais la récupérer (sauf s'il exécute un programme Set-UID root).

Héritable :

les capacités qui sont conservées au cours d'un execve (2).

Dans l'implémentation actuelle, un processus reçoit toutes les capacités dans ses ensembles autorisé et effectif (à travers les limites décrites ci-dessous) lorsqu'il exécute un programme Set-UID-root, ou si un processus avec un UID réel nul exécute un nouveau programme.

Un enfant créé par fork (2) reçoit une copie des ensembles de capacité de son père.

En utilisant capset (2), un processus peut manipuler ses propres ensembles, ou s'il a la capacité CAP_SETPCAP , celles d'un autre processus.

Limitation des des capacités

Quand un programme est exécuté, les capacités effectives et autorisées sont filtrées par un ET binaire avec la valeur en cours de la limitation des capacités , définie dans le fichier /proc/sys/kernel/cap-bound . Ce paramètre peut servir à fixer une limite au niveau système sur les capacités disponibles pour tous les programmes exécutés ultérieurement. (Le masque de bits est exprimé comme un nombre décimal signé dans /proc/sys/kernel/cap-bound , ce qui entretient les confusion). Seul le processus init peut fixer l'ensemble des limitations ; sinon, le Super-Utilisateur peut uniquement effacer des bits dans cet ensemble. Sur un système standard, la limitation élimine toujours la capacité CAP_SETPCAP . Pour supprimer cette restriction modifiez la définition de CAP_INIT_EFF_SET dans include/linux/capability.h et recompilez le noyau.

Implémentations actuelle et à venir

Une implémentation complète des capacités réclame :
1.

que pour toutes les opérations privilégiées, le noyau vérifie que le processus dispose de la capacité nécessaire dans son ensemble effectif.

2.

que le noyau fournisse un appel-système permettant de changer et récupérer les ensembles de capacités d'un processus.

3.

le support du système de fichiers pour attacher des capacités aux fichiers exécutables, pour qu'un processus en dispose en lançant le programme.

Sous Linux 2.4.20, seules les deux premières clauses sont remplies. Il pourrait même être possible d'associer trois ensembles de capacité avec un fichier exécutable, lesquels, en conjonction avec les ensembles de capacité du procesus, déterminera les capacités dont un processus disposera après un exec :
Autorisé :

ce ensemble est combiné par un ET avec l'ensemble héritable du processus pour savoir quelles capacités seront héritées après l'appel exec().

Forcé :

les capacités automatiquement fournies au processus, quelques soient ses capacités héritables.

Effectif :

les capacités qui du nouvel ensemble autorisé seront aussi placées dans l'ensemble effectif. (F(effectif) est normalement entièrement composé de zéros ou de uns).

En attendant, comme l'implémentation actuelle ne supporte pas les ensemble de capacités sur les fichiers, au cours d'un exec :
1.

Les trois ensembles du fichier sont supposés vides.

2.

Si on exécute un programme Set-UID root, ou si l'UID réel est nul, alors les ensembles Forcé et Autorisé du fichier sont remplis de uns (toutes les capacités activées).

3.

Si un programme Set-UID root est exécuté, alors l'ensemble effectif du fichier est rempli avec des uns.

Durant un exec(), le noyau calcule les nouvelles capacités du processus en utilisant l'algorithme suivant : .in +4 .nf P'(autorisé) = (P(héritable) & F(autorisé) | (F(forcé) & cap_bset) P'(effectif) = P'(autorisé) & F(effectif) P'(héritable) = P(héritable) [inchangé] .fi .in -4 avec :
P 10

indique la valeur d'une capacité du processus avant le exec()

P' 10

indique la valeur d'une capacité du processus après le exec()

F 10

indique la valeur d'une capacité du fichier

cap_bset 10

est la valeur de la limitation de capacité.

Notes

Le paquetage libcap fournit un ensemble de routines pour écrire et lire les capacités d'un processus, de manière plus simple et moins susceptible de changer que l'interface fournie par capset (2) et capget (2).

Conformité

Il n'y a pas de véritable standard pour les capacités, mais l'implémentation Linux est basé sur une interprétation du projet POSIX 1003.1e.

Bugs

Il n'y a pas encore de support dans le système de fichiers permettant d'associer les capacités et les fichiers exécutables.

Voir aussi

capget (2), prctl (2)

Traduction

Christophe Blaess, 2003.