Provided by:
manpages-fr_2.80.1-1_all 
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 0, appelé superutilisateur 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 propose un mécanisme (encore incomplet) de
capacités, qui scinde les privilèges traditionnellement associés au
superutilisateur en unités distinctes que l’on peut activer ou inhiber
individuellement.
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)
Activer et désactiver l’audit du noyau ; changer les règles de
filtrage d’audit ; accéder à l’état de l’audit, et aux règles de
filtrage.
CAP_AUDIT_WRITE (depuis Linux 2.6.11)
Permettre l’écriture d’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 des
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
Permet le verrouillage de pages 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’administration 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 fixer les classes d’ordonnancement d’E/S IOPRIO_CLASS_RT et
IOPRIO_CLASS_IDLE ; utiliser 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 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 échouent 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)) ; permet de définir
l’affinité CPU pour les processus arbitraires
(sched_setaffinity(2)) ; de fixer la classe et la priorité
d’ordonnancement d’E/S pour n’importe quel processus
(ioprio_set(2)) ; d’appliquer migrate_pages(2) à n’importe quel
processus et de migrer un processus vers n’importe quel nœud ;
permet à move_pages(2) d’être appliqué à des processus
arbitraires ; d’utiliser l’option MPOL_MF_MOVE_ALL de 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 surensemble
limite pour les ensembles effectif et héritable). Si un
processus supprime une capacité de son ensemble autorisé, il ne
peut plus jamais la récupérer (sauf s’il appelle execve(2) sur
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é
de son père. Le traitement des capacités lors d’un execve(2) est décrit
plus bas.
En utilisant capset(2), un thread peut manipuler ses propres ensembles,
ou s’il a la capacité CAP_SETPCAP, celles d’un thread d’un autre
processus.
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 superutilisateur 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 (attention, c’est
dangereux !), modifiez la définition de CAP_INIT_EFF_SET dans
include/linux/capability.h et recompilez le noyau.
La limitation des capacités a été ajoutée à Linux à partir du noyau
2.2.11.
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 si le
thread a la capacité requise 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.6.14, 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 processus, détermineront les capacités dont un processus
disposera après un execve(2) :
Héritable (anciennement 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 execve(2).
Autorisé (anciennement forcé) :
les capacités automatiquement fournies au thread, quelles que
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 execve(2) :
1. Les trois ensembles de capacités 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 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.
Transformation des capacités lors dâ€â€™un appel exec()
Durant un execve(2), le noyau calcule les nouvelles capacités du
processus en utilisant l’algorithme suivant :
P’(autorisé) = (P(héritable) & F(héritable) |
(F(autorisé) & cap_bset)
P’(effectif) = P’(autorisé) & F(effectif)
P’(héritable) = P(héritable) [inchangé]
où :
P indique la valeur d’un ensemble de capacités du thread avant
le execve(2)
P’ indique la valeur d’un ensemble de capacités après le
execve(2)
F indique la valeur d’un ensemble de capacités du fichier
cap_bset est la valeur de la limitation de capacités.
Dans l’implémentation actuelle, l’effet de cet algorithme est que
lorsqu’un processus lance (avec execve(2)) un programme Set-UID root,
ou lorsqu’un processus d’UID effectif nul exécute un programme, il
obtient toutes les capacités dans ses ensembles de capacités autorisé
et effectif, sauf celles qui sont interdites par la limitation de
capacités (c’est-à -dire CAP_SETPCAP). Ceci fournit une sémantique
identique à celle fournie par les systèmes Unix traditionnels.
Effet des modifications dâ€â€™UID sur les capacités
Afin de préserver la sémantique traditionnelle pour les transitions
entre des UID nul et non nul, le noyau modifie les ensembles de
capacités d’un thread de la façon suivante lors de modifications des
UID réel, effectif, sauvé et du système de fichiers (avec setuid(2),
setresuid(2) et compagnie) :
1. Si l’UID réel, effectif ou sauvé était égal à 0, et qu’à la suite
de la modification ils sont tous non nuls, toutes les capacités
sont supprimés des ensembles de capacités autorisé et effectif.
2. Si l’UID effectif était nul et devient non nul, toutes les
capacités sont supprimées de l’ensemble effectif.
3. Si l’UID effectif est modifié d’une valeur non nulle à 0,
l’ensemble autorisé est copié dans l’ensemble effectif.
4. Si le fsuid est modifié de 0 à une valeur non nulle (voir
setfsuid(2)), les capacités suivantes sont supprimées de l’ensemble
effectif : CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH,
CAP_FOWNER et CAP_FSETID. Si le fsuid devient nul, chacune de ces
capacités est activée dans l’ensemble effectif si elle faisait
partie de l’ensemble autorisé.
Si un thread dont l’un des UID vaut 0 ne veut pas que son ensemble
autorisé soit vidé lorsqu’il fixe tous ses UID à des valeurs non
nulles, il peut le faire avec l’opération PR_SET_KEEPCAPS de l’appel
système prctl(2).
CONFORMITÉ
Il n’y a pas de véritable norme pour les capacités, mais
l’implémentation Linux est basé sur une interprétation de la norme
(retirée) POSIX.1e.
NOTES
Le paquet 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).
BOGUES
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), setfsuid(2), credentials(7), pthreads(7)
COLOPHON
Cette page fait partie de la publication 2.80 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent être trouvées à l’adresse
http://www.kernel.org/doc/man-pages/.
TRADUCTION
Cette page de manuel a été traduite et mise à jour par Christophe
Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et mise Ã
disposition sur http://manpagesfr.free.fr/.
Les mises à jour et corrections de la version présente dans Debian sont
directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
francophone de traduction de Debian.
Veuillez signaler toute erreur de traduction en écrivant Ã
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document
en utilisant la commande « man -L C <section> <page_de_man> ».