capabilities − Présentation des capacités Linux.

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 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 divise les privilèges traditionnellement associés au super utilisateur en unités distinctes, appelées capacités, que l’on peut activer ou inhiber individuellement. Les capacités sont des attributs par thread.

Liste des capacités

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

CAP_AUDIT_CONTROL (depuis Linux 2.6.11)

Active et désactive l’audit du noyau ; modifie les règles de filtres d’audit ; récupère l’état d’audit et les règles de filtrage.

CAP_AUDIT_WRITE (depuis Linux 2.6.11)

Permet l’écriture des enregistrements dans le journal d’audit du noyau.

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 chmod(2), utime(2)), à l’exclusion des opérations couvertes par les CAP_DAC_OVERRIDE et CAP_DAC_READ_SEARCH ; Positionner les attributs de fichier étendus (voir chattr(1)) sur les fichiers arbitraires ; positionner les listes de contrôle d’accès ACL (Ndt : Access Control Lists) sur les fichiers arbitraires ; ignorer le bit sticky pour supprimer un fichier ; spécifier O_NOATIME dans open(2) et fcntl(2). pour les fichiers arbitraires.

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), mmap(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)). Cela inclut l’utilisation de l’ioctl KDSIGACCEPT.

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 (voir chattr(1)).

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éseau (p.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), setreuid(2), setresuid(2), setfsuid(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), umount(2), swapon(2), swapoff(2), sethostname(2), setdomainname(2), IPC_SET et IPC_RMID sur n’importe quel objet IPC Système V ; réaliser des opérations sur les attributs étendus trusted et security (voir attr(5)) ; appeler lookup_dcookie(2) ; utiliser ioprio_set(2) pour affecter les classes d’ordonnancement d’entrées-sorties IOPRIO_CLASS_RT et IOPRIO_CLASS_IDLE ; effectuer les opérations KEYCTL_CHOWN et KEYCTL_SETPERM de keyctl(2). permettre d’utiliser un faux UID pour les authentifications des sockets ; dépasser la limite /proc/sys/fs/file-max, la limite à l’échelle du système du nombre de fichiers ouverts, dans les appels système qui ouvrent les fichiers (par exemple, accept(2), execve(2), open(2), pipe(2) ; sans cette capacité, ces appels système échoueront avec l’erreur ENFILE si cette limite est atteinte) ; utiliser l’attribut CLONE_NEWNS avec clone(2) et unshare(2) ; effectuer les opérations KEYCTL_CHOWN et KEYCTL_SETPERM de keyctl(2).

CAP_SYS_BOOT

Autorise les appels reboot(2) et kexec_load(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 (voir init_module(2) et delete_module(2)).

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)) ; définit l’affinité CPU pour les processus arbitraires (sched_setaffinity(2)) ; configurer les classes d’ordonnancement d’entrées-sorties et les priorités pour des processus arbitraires (ioprio_set(2)) ; permettre que migrate_pages(2) soit appliqué à des processus arbitraires et permettre aux processus de migrer vers des noeuds arbitraires ; permettre que move_pages(2) soit appliqué à des processus arbitraires ; utiliser l’attribut MPOL_MF_MOVE_ALL avec mbind(2) et move_pages(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)) ; accède à /proc/kcore.

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), stime(2), adjtimex(2)) ; permet la modification de l’horloge temps-réel (matérielle).

CAP_SYS_TTY_CONFIG

Autorise l’appel de vhangup(2).

Ensembles de capacités

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

Autorisé :

Les capacités auxquelles le thread peut accéder (un sur-ensemble limite pour les ensembles effectif et héritable). Si un thread supprime une capacité de son ensemble autorisé, il ne peut 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).

Un enfant créé par fork(2) reçoit une copie des ensembles de capacités de son père. Voir plus loin pour une discussion sur le traitement des capacités lors de exec().

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

Limitation 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 confusions).

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 (dangereux !), modifiez la définition de CAP_INIT_EFF_SET dans include/linux/capability.h et recompilez le noyau.

La limitation de capacité a été introduite dans le noyau Linux 2.2.11.

Implémentations actuelles 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 thread 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 thread.

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.6.14, seules les deux premières clauses sont remplies.

Il pourrait même être possible d’associer trois ensembles de capacités avec un fichier exécutable, lesquels, en conjonction avec les ensembles de capacité du thread, déterminera les capacités dont un thread disposera après un exec() :

Héritable (précédemment connu comme autorisé) :

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

Permis (précédemment connu comme forcé) :

les capacités automatiquement fournies au thread, 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 ensembles 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 Héritable et Permis 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.

Transformations des capacités lors d’un exec()

Durant un exec(), le noyau calcule les nouvelles capacités du processus en utilisant l’algorithme suivant :

P’(permis) = (P(héritable) & F(héritable) |
             (F(permis) & cap_bset)

P’(effectif) = P’(permis) & F(effectif)

P’(héritable) = P(héritable)    [inchangé]

avec :

P

indique la valeur d’une capacité du thread avant le exec()

P’

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

F

indique la valeur d’une capacité du fichier

cap_bset

est la valeur de la limitation de capacité.

Dans l’implémentation actuelle, le résultat de cet algorithme est que lorsqu’un processus exécute (exec()) un programme Set−UID root, ou lorsqu’un processus avec un UID effectif de 0 exécute (exec()) un programme, il acquiert toutes les capacités dans ses ensembles de capacités permis et effectif exceptées celles qui sont masquées par l’ensemble limite de capacités (c’est-à -dire CAP_SETPCAP). Cela fournit une sémantique qui est la même que celle fournie par les systèmes Unix traditionnels.

Effets des modifications de l’UID sur les capacités

Le noyau effectue différents changements pour conserver la sémantique traditionnelle concernant les transitions entre l’UID 0 et les autres UID. Lorsque l’UID réel, l’UID effectif, le Set−UID sauvé et l’UID système de fichier évoluent (en utilisant setuid(2), setresuid(2), ou similaire), les changements suivants sont effectués sur l’ensemble des capacités du processus :

1.

Si un ou plus parmi l’UID réel, l’UID effectif ou le Set−UID sauvé valait précédemment 0 et qu’à la suite d’une modification tous ces UID ne sont pas nuls, toutes les capacités sont retirées des ensembles de capacités permis et effectif.

2.

Si l’UID effectif est modifié de 0 en non nul, toutes les capacités sont retirées de l’ensemble effectif.

3.

Si l’UID effectif est modifié de non nul en 0, l’ensemble permis est copié dans l’ensemble effectif.

4.

Si l’UID système de fichier est modifié de 0 en non nul (voir setfsuid(2)) les capacités suivantes sont enlevées de l’ensemble effectif : CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER et CAP_FSETID. Si l’UID système de fichier est modifié de non nul en 0, chacune de ces capacités qui sont activées dans l’ensemble permis le sont dans l’ensemble effectif.

Si un processus, qui a une valeur 0 pour l’un ou plusieurs de ses UID, veut éviter que son ensemble de capacités permis soit effacé lorsqu’il réinitialise tous ses UID à une valeur non nulle, il peut le faire en utilisant l’opération PR_SET_KEEPCAPS de prctl().

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

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

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.

capget(2), prctl(2), setfsuid(2), pthreads(7)

Ce document est une traduction réalisée par Christophe Blaess <http://www.blaess.fr/christophe/> le 25 juillet 2003 et révisée le 14 août 2006.

L’équipe de traduction a fait le maximum pour réaliser une adaptation française de qualité. La version anglaise la plus à jour de ce document est toujours consultable via la commande : « LANG=C man 7 capabilities ». N’hésitez pas à signaler à l’auteur ou au traducteur, selon le cas, toute erreur dans cette page de manuel.