CAPABILITIES
Section : Manuel de l'administrateur Linux (
7)
Mise à jour de la version anglaise : 31 juillet 2006
Index
Menu principal
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 superutilisateur, ou root),
et les processus
non privilégiés
(dont l'UID effectif n'est pas 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 superutilisateur 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 System 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 System 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 nœuds 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
execve(2).
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 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 (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
execve(2) :
- 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
execve(2).
- 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
execve(2) :
- 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
execve(2),
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
execve(2)
- P'
-
indique la valeur d'une capacité du processus après le
execve(2)
- 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
(execve(2))
un programme Set-UID root,
ou lorsqu'un processus avec un UID effectif de 0 exécute
(execve(2))
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 fichiers 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 fichiers 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(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 du projet POSIX.1e.
NOTES
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).
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)
TRADUCTION
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 24 juin 2008.
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.
Index
- NOM
-
- DESCRIPTION
-
- Liste des capacités
-
- Ensembles de capacités
-
- Limitation des capacités
-
- Implémentations actuelles et à venir
-
- Transformations des capacités lors d'un exec()
-
- Effets des modifications de l'UID sur les capacités
-
- CONFORMITÉ
-
- NOTES
-
- BOGUES
-
- VOIR AUSSI
-
- TRADUCTION
-
Dernière mise à jour : 24 juin 2008