.\" -*- coding: UTF-8 -*- .\" Copyright (c) 2002 by Michael Kerrisk .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" 6 Aug 2002 - Initial Creation .\" Modified 2003-05-23, Michael Kerrisk, .\" Modified 2004-05-27, Michael Kerrisk, .\" 2004-12-08, mtk Added O_NOATIME for CAP_FOWNER .\" 2005-08-16, mtk, Added CAP_AUDIT_CONTROL and CAP_AUDIT_WRITE .\" 2008-07-15, Serge Hallyn .\" Document file capabilities, per-process capability .\" bounding set, changed semantics for CAP_SETPCAP, .\" and other changes in Linux 2.6.2[45]. .\" Add CAP_MAC_ADMIN, CAP_MAC_OVERRIDE, CAP_SETFCAP. .\" 2008-07-15, mtk .\" Add text describing circumstances in which CAP_SETPCAP .\" (theoretically) permits a thread to change the .\" capability sets of another thread. .\" Add section describing rules for programmatically .\" adjusting thread capability sets. .\" Describe rationale for capability bounding set. .\" Document "securebits" flags. .\" Add text noting that if we set the effective flag for one file .\" capability, then we must also set the effective flag for all .\" other capabilities where the permitted or inheritable bit is set. .\" 2011-09-07, mtk/Serge hallyn: Add CAP_SYSLOG .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH Capacités 7 "3 mai 2023" "Pages du manuel de Linux 6.05.01" .SH NOM capabilities –\ Présentation des capacités Linux .SH DESCRIPTION Pour vérifier les permissions, les implémentations UNIX traditionnelles distinguent deux catégories de processus\ : les processus \fIprivilégiés\fP (dont l'UID effectif est\ 0, appelé superutilisateur ou root) et les processus \fInon privilégiés\fP (dont les UID effectifs sont différents de zéro). Les processus privilégiés contournent toutes 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 additionnels). .PP .\" À partir de Linux\ 2.2, Linux scinde les privilèges traditionnellement associés au superutilisateur en unités distinctes, connues sous le nom de \fIcapabilities\fP (capacités) que l'on peut activer ou inhiber individuellement. Les capacités sont des attributs individuels à chaque thread. .SS "Liste des capacités" La liste suivante indique les capacités implémentées sous Linux et les opérations ou comportements que chaque capacité permet\ : .TP \fBCAP_AUDIT_CONTROL\fP (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. .TP \fBCAP_AUDIT_READ\fP (depuis Linux\ 3.16) .\" commit a29b694aa1739f9d76538e34ae25524f9c549d59 .\" commit 3a101b8de0d39403b2c7e5c23fd0b005668acf48 Autoriser la lecture du journal d'audit au moyen d'un socket netlink multidiffusion. .TP \fBCAP_AUDIT_WRITE\fP (depuis Linux\ 2.6.11) .\" FIXME Add FAN_ENABLE_AUDIT Écrire des enregistrements dans le journal d'audit du noyau. .TP \fBCAP_BLOCK_SUSPEND\fP (depuis Linux\ 3.5) Utiliser des fonctionnalités qui peuvent bloquer la mise en veille du système (\fBepoll\fP(7) \fBEPOLLWAKEUP\fP, \fI/proc/sys/wake_lock\fP). .TP \fBCAP_BPF\fP (depuis Linux\ 5.8) Utiliser des opérations BPF privilégiées\ ; consultez \fBbpf\fP(2) et \fBbpf\-helpers\fP(7). .IP Cette capacité a été ajoutée dans Linux\ 5.8 pour séparer la fonctionnalité BPF de la capacité \fBCAP_SYS_ADMIN\fP surchargée. .TP \fBCAP_CHECKPOINT_RESTORE\fP (depuis Linux\ 5.9) .\" commit 124ea650d3072b005457faed69909221c2905a1f .PD 0 .RS .IP \- 3 Mettre à jour \fI/proc/sys/kernel/ns_last_pid\fP (consultez \fBpid_namespaces\fP(7))\ ; .IP \- .\" FIXME There is also some use case relating to .\" prctl_set_mm_exe_file(); in the 5.9 sources, see .\" prctl_set_mm_map(). Utiliser la fonction \fIset_tid\fP de \fBclone3\fP(2)\ ; .IP \- Lire le contenu des liens symboliques dans \fI/proc/\fPpid\fI/map_files\fP pour les autres processus. .RE .PD .IP Cette capacité a été ajoutée dans Linux\ 5.9 pour séparer la fonctionnalité checkpoint/restore de la capacité \fBCAP_SYS_ADMIN\fP surchargée. .TP \fBCAP_CHOWN\fP Effectuer toute modification des UID et GID de fichiers (consultez \fBchown\fP(2)). .TP \fBCAP_DAC_OVERRIDE\fP Contourner les vérifications des permissions de lecture, écriture et exécution. (DAC est l'abréviation de «\ discretionary access control\ », contrôle d'accès à volonté). .TP \fBCAP_DAC_READ_SEARCH\fP .PD 0 .RS .IP \- 3 Contourner les vérifications des permissions de lecture de fichiers et celles de lecture et d'exécution des répertoires\ ; .IP \- invoquer \fBopen_by_handle_at\fP(2)\ ; .IP \- utiliser l'attribut \fBAT_EMPTY_PATH\fP de \fBlinkat\fP(2) pour créer un lien vers un fichier visé par un descripteur de fichier. .RE .PD .TP \fBCAP_FOWNER\fP .PD 0 .RS .IP \- 3 Contourner les vérifications pour les opérations qui demandent que l'UID de système de fichiers du processus corresponde à l'UID du fichier (par exemple \fBchmod\fP(2), \fButime\fP(2)), à l'exclusion des opérations couvertes par \fBCAP_DAC_OVERRIDE\fP et \fBCAP_DAC_READ_SEARCH\fP\ ; .IP \- positionner les attributs d'inœuds (consultez \fBioctl_iflags\fP(2)) pour n'importe quel fichier\ ; .IP \- positionner les listes de contrôle d'accès ACL («\ Access Control Lists\ ») pour n'importe quel fichier\ ; .IP \- ignorer le «\ sticky bit\ » des répertoires pour les suppressions de fichier\ ; .IP \- modifier les attributs étendus \fIuser\fP sur un répertoire avec le sticky bit défini, appartenant à n'importe quel utilisateur\ ; .IP \- spécifier \fBO_NOATIME\fP dans \fBopen\fP(2) et \fBfcntl\fP(2) pour n'importe quel fichier. .RE .PD .TP \fBCAP_FSETID\fP .PD 0 .RS .IP \- 3 Ne pas effacer les bits de mode set\-user\-ID et set\-group\-ID lors de la modification d'un fichier\ ; .IP \- positionner le bit Set\-group\-ID sur un fichier dont le GID ne correspond pas au système de fichiers ni à aucun GID additionnel du processus appelant. .RE .PD .TP \fBCAP_IPC_LOCK\fP .\" FIXME . As at Linux 3.2, there are some strange uses of this capability .\" in other places; they probably should be replaced with something else. .PD 0 .RS .IP \- 3 Verrouiller des pages mémoire (\fBmlock\fP(2), \fBmlockall\fP(2), \fBmmap\fP(2), \fBshmctl\fP(2))\ ; .IP \- allouer des pages mémoire utilisant des pages larges (\fBmemfd_create\fP(2), \fBmmap\fP(2), \fBshmctl\fP(2)). .RE .PD .TP \fBCAP_IPC_OWNER\fP Contourner les vérifications de permission pour les opérations sur les objets IPC System\ V. .TP \fBCAP_KILL\fP .\" FIXME . CAP_KILL also has an effect for threads + setting child .\" termination signal to other than SIGCHLD: without this .\" capability, the termination signal reverts to SIGCHLD .\" if the child does an exec(). What is the rationale .\" for this? Contourner les vérifications de permission pour l'émission de signaux (consultez \fBkill\fP(2)). Cette capacité inclut l'utilisation de l'opération \fBKDSIGACCEPT\fP d'\fBioctl\fP(2). .TP \fBCAP_LEASE\fP (depuis Linux\ 2.4) Demander des baux (leases) sur n'importe quel fichier (consultez \fBfcntl\fP(2)). .TP \fBCAP_LINUX_IMMUTABLE\fP Positionner les attributs d'inœuds \fBFS_APPEND_FL\fP et \fBFS_IMMUTABLE_FL\fP (consultez \fBioctl_iflags\fP(2)). .TP \fBCAP_MAC_ADMIN\fP (depuis Linux\ 2.6.25) Permettre les modifications de la configuration ou des états MAC. Implémentée pour le module LSM (Smack Linux Security Module). .TP \fBCAP_MAC_OVERRIDE\fP (depuis Linux\ 2.6.25) Surcharger les contrôles d'accès MAC («\ Mandatory Access Control\ »). Implémentée pour le module Smack LSM. .TP \fBCAP_MKNOD\fP (depuis Linux\ 2.4) Créer des fichiers spéciaux avec \fBmknod\fP(2). .TP \fBCAP_NET_ADMIN\fP Effectuer diverses opérations liées au réseau\ : .PD 0 .RS .IP \- 3 configuration des interfaces\ ; .IP \- administration du pare\-feu, de la traduction d'adresse IP («\ masquerading\ ») et collection de données sur le trafic réseau («\ accounting\ »)\ ; .IP \- modification des tables de routages\ ; .IP \- attachement à n'importe quelle adresse pour un service mandataire transparent\ ; .IP \- sélection du type de service («\ TOS\ »)\ ; .IP \- effacement des statistiques du pilote\ ; .IP \- sélection du mode «\ promiscuité\ »\ ; .IP \- activation de la diffusion multipoint («\ multicast\ »)\ ; .IP \- utilisation de \fBsetsockopt\fP(2) pour définir les options de sockets suivantes\ : \fBSO_DEBUG\fP, \fBSO_MARK\fP, \fBSO_PRIORITY\fP (pour une priorité en dehors des valeurs de\ 0 à\ 6), \fBSO_RCVBUFFORCE\fP et \fBSO_SNDBUFFORCE\fP. .RE .PD .TP \fBCAP_NET_BIND_SERVICE\fP Attacher un socket à un port privilégié du domaine de l'Internet (numéro de port inférieur à 1024). .TP \fBCAP_NET_BROADCAST\fP .\" FIXME Since Linux 4.2, there are use cases for netlink sockets .\" commit 59324cf35aba5336b611074028777838a963d03b (Inutilisé) diffusion par socket et écoute de multidiffusion. .TP \fBCAP_NET_RAW\fP .PD 0 .RS .IP \- 3 Utiliser des sockets RAW et PACKET\ ; .IP \- attacher à n'importe quelle adresse pour un service mandataire transparent. .RE .PD .\" Also various IP options and setsockopt(SO_BINDTODEVICE) .TP \fBCAP_PERFMON\fP (depuis Linux\ 5.8) Utiliser divers mécanismes de suivi des performances dont\ : .RS .IP \- 3 .PD 0 appeler \fBperf_event_open\fP(2)\ ; .IP \- utiliser diverses opérations BPF qui ont des incidences sur les performances. .RE .PD .IP Cette capacité a été ajoutée dans Linux\ 5.8 pour séparer la fonctionnalité de suivi des performances de la capacité \fBCAP_SYS_ADMIN\fP surchargée. Consultez aussi le fichier source du noyau \fIDocumentation/admin\-guide/perf\-security.rst\fP. .TP \fBCAP_SETGID\fP .RS .PD 0 .IP \- 3 Faire des manipulations arbitraires des GID et de la liste de GID additionnels des processus\ ; .IP \- simuler des GID lors du passage de références de sockets au moyen de sockets de domaine UNIX\ ; .IP \- écrire une projection de GID dans un espace de noms utilisateur (consultez \fBuser_namespaces\fP(7)). .PD .RE .TP \fBCAP_SETFCAP\fP (depuis Linux\ 2.6.24) Définir des capacités arbitraires sur un fichier .IP .\" commit db2e718a47984b9d71ed890eb2ea36ecf150de18 Depuis Linux\ 5.12, cette capacité est aussi nécessaire pour projeter l'UID\ 0 dans un nouvel espace de noms utilisateur\ ; pour en savoir plus consultez \fBuser_namespaces\fP(7). .TP \fBCAP_SETPCAP\fP Si les capacités de fichier sont prises en charge (c'est\-à\-dire depuis Linux\ 2.6.24)\ : ajouter toute capacité de l'ensemble de limitation de capacités du thread appelant à son ensemble hérité\ ; supprimer les capacités de l'ensemble de limitation de capacités (avec \fBprctl\fP(2) \fBPR_CAPBSET_DROP\fP)\ ; modifier les attributs \fIsecurebits\fP. .IP Si les capacités de fichier ne sont pas prises en charge (c'est\-à\-dire avec les noyaux antérieurs à Linux\ 2.6.24)\ : accorder ou interdire toute capacité dans l'ensemble des capacités permises de l'appelant vers ou depuis tout autre processus (cette propriété de \fBCAP_SETPCAP\fP n'est pas disponible quand le noyau est configuré pour prendre en charge les capacités de fichiers, puisque \fBCAP_SETPCAP\fP a une toute autre sémantique pour ces noyaux). .TP \fBCAP_SETUID\fP .RS .PD 0 .IP \- 3 Faire des manipulations arbitraires des UID de processus (\fBsetuid\fP(2), \fBsetreuid\fP(2), \fBsetresuid\fP(2), \fBsetfsuid\fP(2))\ ; .IP \- simuler des UID lors du passage de références de sockets au moyen de sockets de domaine UNIX\ ; .IP \- écrire une projection de l'UID dans un espace de noms utilisateur (consultez \fBuser_namespaces\fP(7)). .PD .RE .\" FIXME CAP_SETUID also an effect in exec(); document this. .TP \fBCAP_SYS_ADMIN\fP \fIRemarque\fP\ : cette capacité est surchargée\ : voir les \fINotes pour les développeurs du noyau\fP ci\-dessous. .IP .PD 0 .RS .IP \- 3 Effectuer certaines opérations d'administration système comme\ : \fBquotactl\fP(2), \fBmount\fP(2), \fBumount\fP(2), \fBpivot_root\fP(2), \fBswapon\fP(2), \fBswapoff\fP(2), \fBsethostname\fP(2) et \fBsetdomainname\fP(2)\ ; .IP \- effectuer des opérations \fBsyslog\fP(2) nécessitant des droits (depuis Linux\ 2.6.37, \fBCAP_SYSLOG\fP doit être utilisée pour permettre de telles opérations)\ ; .IP \- effectuer une commande \fBVM86_REQUEST_IRQ\fP \fBvm86\fP(2)\ ; .IP \- accéder à la même fonctionnalité checkpoint/restore qui est contrôlée par \fBCAP_CHECKPOINT_RESTORE\fP (mais cette dernière capacité plus faible est préférée pour accéder à cette fonctionnalité)\ ; .IP \- effectuer les mêmes opérations BPF que celles contrôlées par \fBCAP_BPF\fP (mais cette dernière capacité plus faible est préférée pour accéder à cette fonctionnalité)\ ; .IP \- utiliser les mêmes mécanismes de suivi des performances qui sont contrôlés par \fBCAP_PERFMON\fP (mais cette dernière capacité plus faible est préférée pour accéder à cette fonctionnalité)\ ; .IP \- effectuer des opérations \fBIPC_SET\fP et \fBIPC_RMID\fP sur n'importe quel objet IPC System\ V\ ; .IP \- ne pas tenir compte de la limite de ressource \fBRLIMIT_NPROC\fP\ ; .IP \- effectuer des opérations sur les attributs étendus \fItrusted\fP et \fIsecurity\fP (consultez \fBxattr\fP(7))\ ; .IP \- utiliser \fBlookup_dcookie\fP(2)\ ; .IP \- utiliser \fBioprio_set\fP(2) pour configurer une classe d'ordonnancement d'E/S \fBIOPRIO_CLASS_RT\fP et (avant Linux\ 2.6.25) \fBIOPRIO_CLASS_IDLE\fP\ ; .IP \- simuler des PID lors du passage de références de sockets au moyen de sockets de domaine UNIX\ ; .IP \- dépasser \fI/proc/sys/fs/file\-max\fP, la limite système du nombre de fichiers ouverts dans les appels système qui ouvrent des fichiers (par exemple \fBaccept\fP(2), \fBexecve\fP(2), \fBopen\fP(2) et \fBpipe\fP(2))\ ; .IP \- utiliser les attributs \fBCLONE_*\fP qui créent de nouveaux espaces de noms avec \fBclone\fP(2) et \fBunshare\fP(2) (mais, depuis Linux 3.8, la création d'espaces de noms utilisateur ne nécessite aucune capacité)\ ; .IP \- accéder aux informations d'événements \fIperf\fP nécessitant des droits\ ; .IP \- appeler \fBsetns\fP(2) (nécessite la capacité \fBCAP_SYS_ADMIN\fP dans l'espace de noms \fItarget\fP\ ; .IP \- appeler \fBfanotify_init\fP(2)\ ; .IP \- effectuer des opérations \fBKEYCTL_CHOWN\fP et \fBKEYCTL_SETPERM\fP de \fBkeyctl\fP(2) nécessitant des droits\ ; .IP \- effectuer une opération \fBmadvise\fP(2) \fBMADV_HWPOISON\fP\ ; .IP \- utiliser la commande \fBTIOCSTI\fP de \fBioctl\fP(2) pour insérer des caractères dans la file d'entrées d'un terminal autre que le terminal de contrôle de l'appelant\ ; .IP \- utiliser l'appel système obsolète \fBnfsservctl\fP(2)\ ; .IP \- utiliser l'appel système obsolète \fBbdflush\fP(2)\ ; .IP \- effectuer diverses opérations \fBioctl\fP(2) sur des périphériques bloc nécessitant des droits\ ; .IP \- effectuer diverses opérations \fBioctl\fP(2) sur des systèmes de fichiers nécessitant des droits\ ; .IP \- effectuer des opérations \fBioctl\fP(2) nécessitant des droits sur le périphérique \fI/dev/random\fP (consultez \fBrandom\fP(4))\ ; .IP \- installer un filtre \fBseccomp\fP(2) sans avoir à définir d'abord l'attribut de thread \fIno_new_privs\fP\ ; .IP \- modifier les règles d'autorisation ou d'interdiction pour les groupes de contrôle de périphérique\ ; .IP \- utiliser l'opération \fBPTRACE_SECCOMP_GET_FILTER\fP de \fBptrace\fP(2) pour vider les filtres seccomp de l'observé\ ; .IP \- utiliser l'opération \fBPTRACE_SETOPTIONS\fP de \fBptrace\fP(2) pour suspendre les protections seccomp de l'observé (c'est\-à\-dire l'attribut \fBPTRACE_O_SUSPEND_SECCOMP\fP)\ ; .IP \- effectuer des opérations d'administration sur de nombreux pilotes de périphériques\ ; .IP \- modifier les valeurs de courtoisie de l'autogroupe en écrivant dans \fI/proc/\fPpid\fI/autogroup\fP (consultez \fBsched\fP(7)). .RE .PD .TP \fBCAP_SYS_BOOT\fP Utiliser \fBreboot\fP(2) et \fBkexec_load\fP(2). .TP \fBCAP_SYS_CHROOT\fP .RS .PD 0 .IP \- 3 Utiliser \fBchroot\fP(2)\ ; .IP \- modifier l'espace de noms montage en utilisant \fBsetns\fP(2). .PD .RE .TP \fBCAP_SYS_MODULE\fP .RS .PD 0 .IP \- 3 Charger ou décharger des modules noyaux (consultez \fBinit_module\fP(2) et \fBdelete_module\fP(2))\ ; .IP \- avant Linux\ 2.6.25\ : enlever des capacités de l'ensemble de limitation de capacités au niveau du système. .PD .RE .TP \fBCAP_SYS_NICE\fP .PD 0 .RS .IP \- 3 Baisser la valeur de courtoisie («\ nice\ ») (\fBnice\fP(2), \fBsetpriority\fP(2)) et changer la courtoisie de n'importe quel processus\ ; .IP \- définir les politiques d'ordonnancement temps réel pour le processus appelant et les politiques d'ordonnancement et les priorités de n'importe quel processus (\fBsched_setscheduler\fP(2), \fBsched_setparam\fP(2), \fBsched_setattr\fP(2))\ ; .IP \- définir l'affinité CPU pour n'importe quel processus (\fBsched_setaffinity\fP(2))\ ; .IP \- définir la classe et la priorité d'ordonnancement d'entrées/sorties pour n'importe quel processus (\fBioprio_set\fP(2))\ ; .IP \- .\" FIXME CAP_SYS_NICE also has the following effect for .\" migrate_pages(2): .\" do_migrate_pages(mm, &old, &new, .\" capable(CAP_SYS_NICE) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE); .\" .\" Document this. appliquer \fBmigrate_pages\fP(2) à n'importe quel processus et migrer un processus vers n'importe quel nœud\ ; .IP \- appliquer \fBmove_pages\fP(2) pour n'importe quel processus\ ; .IP \- utiliser l'attribut \fBMPOL_MF_MOVE_ALL\fP avec \fBmbind\fP(2) et \fBmove_pages\fP(2). .RE .PD .TP \fBCAP_SYS_PACCT\fP Utiliser \fBacct\fP(2). .TP \fBCAP_SYS_PTRACE\fP .PD 0 .RS .IP \- 3 Suivre n'importe quel processus avec \fBptrace\fP(2)\ ; .IP \- appliquer \fBget_robust_list\fP(2) à n'importe quel processus\ ; .IP \- transférer les données depuis ou vers la mémoire de n'importe quel processus au moyen de \fBprocess_vm_readv\fP(2) et de \fBprocess_vm_writev\fP(2)\ ; .IP \- examiner les processus avec \fBkcmp\fP(2). .RE .PD .TP \fBCAP_SYS_RAWIO\fP .PD 0 .RS .IP \- 3 Effectuer des opérations d'entrées\-sorties (\fBiopl\fP(2) et \fBioperm\fP(2))\ ; .IP \- accéder à \fI/proc/kcore\fP\ ; .IP \- utiliser l'opération \fBFIBMAP\fP de \fBioctl\fP(2)\ ; .IP \- ouvrir les périphériques pour accéder aux registres spécifiques au modèle (MSR, consultez \fBmsr\fP(4)) d'un processeur x86\ ; .IP \- mettre à jour \fI/proc/sys/vm/mmap_min_addr\fP\ ; .IP \- créer des projections en mémoire aux adresses inférieures à la valeur indiquée par \fI/proc/sys/vm/mmap_min_addr\fP\ ; .IP \- projeter les fichiers dans \fI/proc/bus/pci\fP\ ; .IP \- ouvrir \fI/dev/mem\fP et \fI/dev/kmem\fP\ ; .IP \- effectuer diverses commandes de périphérique SCSI\ ; .IP \- effectuer certaines opérations sur les périphériques \fBhpsa\fP(4) et \fBcciss\fP(4)\ ; .IP \- effectuer certaines opérations spécifiques à un périphérique sur d'autres périphériques. .RE .PD .TP \fBCAP_SYS_RESOURCE\fP .PD 0 .RS .IP \- 3 Utiliser de l'espace réservé sur des systèmes de fichiers ext2\ ; .IP \- effectuer des appels \fBioctl\fP(2) pour contrôler la journalisation ext3\ ; .IP \- ne pas tenir compte des limites de quota disque\ ; .IP \- augmenter les limites de ressources (consultez \fBsetrlimit\fP(2))\ ; .IP \- ne pas tenir compte de la limite de ressource \fBRLIMIT_NPROC\fP\ ; .IP \- ne pas tenir compte du nombre maximal de consoles sur l'allocation de console\ ; .IP \- ne pas tenir compte du nombre maximal de dispositions de clavier\ ; .IP \- permettre des interruptions à plus de 64\ Hz depuis l'horloge temps réel\ ; .IP \- augmenter la limite \fImsg_qbytes\fP pour la file de messages System\ V au\-dessus de la limite \fI/proc/sys/kernel/msgmnb\fP (consultez \fBmsgop\fP(2) et \fBmsgctl\fP(2))\ ; .IP \- permettre le contournement de la limite de ressource \fBRLIMIT_NOFILE\fP sur le nombre de descripteurs de fichiers «\ en cours\ » lors de leur transmission à un autre processus au moyen d'un socket de domaine UNIX (consultez \fBunix\fP(7))\ ; .IP \- ne pas tenir compte de la limite \fI/proc/sys/fs/pipe\-size\-max\fP lors du réglage de la capacité d'un tube avec la commande \fBfcntl\fP(2) avec l'argument \fBF_SETPIPE_SZ\fP\ ; .IP \- utiliser \fBF_SETPIPE_SZ\fP pour augmenter la capacité d'un tube au\-dessus de la limite spécifiée par \fI/proc/sys/fs/pipe\-max\-size\fP\ ; .IP \- ne pas tenir compte des limites \fI/proc/sys/fs/mqueue/queues_max\fP, \fI/proc/sys/fs/mqueue/msg_max\fP et \fI/proc/sys/fs/mqueue/msgsize_max\fP lors de la création de files de messages POSIX (consultez \fBmq_overview\fP(7))\ ; .IP \- utiliser l'opération \fBPR_SET_MM\fP de \fBprctl\fP(2)\ ; .IP \- affecter à \fI/proc/\fPpid\fI/oom_score_adj\fP une valeur inférieure à la dernière valeur affectée par un processus avec \fBCAP_SYS_RESOURCE\fP. .RE .PD .TP \fBCAP_SYS_TIME\fP Modifier l'heure système (\fBsettimeofday\fP(2), \fBstime\fP(2), \fBadjtimex\fP(2))\ ; modifier l'horloge temps réel (matérielle). .TP \fBCAP_SYS_TTY_CONFIG\fP Utiliser \fBvhangup\fP(2)\ ; employer diverses opérations \fBioctl\fP(2) nécessitant des droits sur des terminaux virtuels. .TP \fBCAP_SYSLOG\fP (depuis Linux\ 2.6.37) .RS .PD 0 .IP \- 3 Effectuer des opérations \fBsyslog\fP(2) nécessitant des droits. Consultez \fBsyslog\fP(2) pour savoir quelles opérations nécessitent des droits. .IP \- Inspecter les adresses du noyau exposées par \fI/proc\fP et d'autres interfaces lorsque \fI/proc/sys/kernel/kptr_restrict\fP a la valeur\ 1. (Voir la discussion sur \fIkptr_restrict\fP dans \fBproc\fP(5).) .PD .RE .TP \fBCAP_WAKE_ALARM\fP (depuis Linux\ 3.0) .\" Déclencher quelque chose qui réveillera le système (réglage des alarmes \fBCLOCK_REALTIME_ALARM\fP et \fBCLOCK_BOOTTIME_ALARM\fP). .SS "Implémentations passées et actuelles" Une implémentation complète des capacités nécessite que\ : .IP \- 3 pour toutes les opérations privilégiées, le noyau doit vérifier si le thread a la capacité requise dans son ensemble effectif\ ; .IP \- le noyau doit fournir des appels système permettant de changer et récupérer les ensembles de capacités d'un thread\ ; .IP \- le système de fichiers doit permettre d'attacher des capacités aux fichiers exécutables pour qu'un processus en dispose quand le fichier est exécuté. .PP .\" Avant Linux\ 2.6.24, seules les deux premières exigences sont remplies\ ; depuis Linux\ 2.6.24, ces trois exigences sont remplies. .SS "Remarques pour les développeurs du noyau" Lors de l'ajout d'une nouvelle fonctionnalité du noyau qui pourrait être contrôlée par une capacité, veuillez prendre en considération les points suivants\ : .IP \- 3 Le but des capacités est de découper le pouvoir du superutilisateur en plusieurs aptitudes de telle sorte que si un programme qui a une ou plusieurs capacités est compromis, son pouvoir d'endommager le système soit moindre que si le programme est exécuté avec les privilèges du superutilisateur. .IP \- Vous pouvez choisir de créer une nouvelle capacité pour votre nouvelle fonctionnalité, ou d'associer la fonctionnalité à l'une des capacités existantes. Afin que l'ensemble des capacités garde une taille gérable, la seconde solution est préférable, à moins qu'il y ait des raisons convaincantes de choisir la première option (il existe aussi une limite technique\ : la taille des ensembles de capacités est actuellement limitée à 64\ bits). .IP \- Pour déterminer parmi les capacités existantes laquelle est la mieux adaptée pour être associée à la nouvelle fonctionnalité, examinez la liste de capacités ci\-dessus pour trouver un «\ silo\ » dans lequel la nouvelle capacité est la mieux adaptée. Une des options est de déterminer s'il y a d'autres fonctionnalités exigeant des capacités qui seront toujours utilisées avec la nouvelle fonctionnalité. Si la nouvelle fonctionnalité ne sert à rien sans les autres fonctions, vous devriez utiliser la même capacité que ces autres fonctions. .IP \- \fINe choisissez pas\fP \fBCAP_SYS_ADMIN\fP si vous pouvez l'éviter\ ! Une forte proportion de vérifications de capacités existantes lui sont associée (voir une liste partielle plus haut). Elle pourrait plausiblement être appelée «\ la nouvelle racine\ », dans la mesure où d'une part, elle confère une large palette de pouvoirs, et d'autre part, sa vaste portée signifie que c'est la capacité qui est requise par de nombreux programmes privilégiés. Ne rendez pas le problème encore plus compliqué. Les seules nouvelles fonctionnalités qui pourraient être associées à \fBCAP_SYS_ADMIN\fP sont celles qui correspondent de façon \fIétroite\fP aux usages existants dans ce silo. .IP \- .\" Si vous avez établi qu'il était réellement nécessaire de créer une nouvelle capacité pour votre fonctionnalité, ne la créez pas ou ne la nommez pas comme une capacité «\ à usage unique\ ». Par conséquent, par exemple, l'ajout de la capacité très spécifique \fBCAP_SYS_PACCT\fP était probablement une erreur. Essayez plutôt d'identifier et de nommer votre nouvelle capacité comme un silo plus général dans lequel d'autres futures cas d'usage semblable pourraient s'intégrer. .SS "Ensembles de capacités des threads" Chaque thread a les ensembles de capacités suivants contenant zéro ou plus des capacités ci\-dessus\ : .TP \fIPermitted\fP (permis) Il s'agit d'un surensemble limitant les capacités effectives que le thread peut prendre. Il limite également les capacités qui peuvent être ajoutées à l'ensemble héritable par un thread qui n'a pas la capacité \fBCAP_SETPCAP\fP dans son ensemble effectif. .IP Si un processus supprime une capacité de son ensemble de capacités permises, il ne peut plus jamais la récupérer (sauf s'il appelle \fBexecve\fP(2) sur un programme set\-user\-ID\-root ou un programme dont les capacités associées au fichier accordent cette capacité). .TP \fIInheritable\fP (héritable) Il s'agit d'un ensemble de capacités préservées au travers d'un \fBexecve\fP(2). Les capacités héritables restent héritables lors de l'exécution d'un programme et les capacités héritables sont ajoutées à l'ensemble de capacités permises lors de l'exécution d'un programme qui a les bits correspondant activés dans l'ensemble héritable du fichier. .IP Parce que les capacités héritables ne sont généralement pas préservées au travers d'un \fBexecve\fP(2) lors d'une exécution en tant qu'utilisateur ordinaire, les applications qui souhaitent exécuter des programmes d'assistance avec des capacités plus élevées devraient envisager d'utiliser les capacités ambiantes, décrites ci\-dessous. .TP \fIEffective\fP (effectif) Il s'agit de l'ensemble des capacités utilisées par le noyau pour vérifier les permissions du thread. .TP \fIBounding\fP (limitation) (par processus depuis Linux 2.6.25) L’ensemble de limitation des capacités («\ capability bounding set\ ») est un mécanisme qui peut être utilisé pour limiter les capacités qui peuvent être obtenues lors d'un \fBexecve\fP(2). .IP Depuis Linux\ 2.6.25, c'est un ensemble de capacités par thread. Dans les noyaux plus anciens, la limitation des capacités était un attribut pour l'ensemble du système, partagé par tous les threads du système. .IP Pour plus de détails, voir \fIEnsemble de limitation des capacités\fP, ci\-dessous. .TP \fIAmbient\fP (ambiant) (depuis Linux 4.3) .\" commit 58319057b7847667f0c9585b9de0e8932b0fdb08 Il s'agit d'un ensemble de capacités préservées au travers d'un \fBexecve\fP(2) d'un programme non privilégié. L'ensemble de capacités ambiantes obéit à la règle invariable qu'aucune capacité ne peut être ambiante si elle n'est pas à la fois permise et héritable. .IP L'ensemble de capacités ambiantes peut être directement modifié avec \fBprctl\fP(2). Les capacités ambiantes sont automatiquement diminuées si une capacités soit permises soit héritables correspondantes sont diminuées. .IP L'exécution d'un programme qui change l'UID ou le GID à cause des bits set\-user\-ID ou set\-group\-ID, ou l'exécution d'un programme qui a un ensemble de capacités de fichier supprimera l'ensemble ambiant. Les capacités ambiantes sont ajoutées à l'ensemble des capacités permises et assignées à l'ensemble des capacités effectives quand \fBexecve\fP(2) est appelé. Si les capacités ambiantes font que les capacités permises et ambiantes d'un processus sont accrues durant un \fBexecve\fP(2), cela ne déclenche pas le mode «\ secure\-execution\ » décrit dans \fBld.so\fP(8). .PP Un enfant créé par \fBfork\fP(2) hérite d'une copie des ensembles de capacités de son parent. Pour des détails sur la façon dont \fBexecve\fP(2) affecte les capacités, voir \fITransformation des capacités lors d'un appel execve()\fP plus bas. .PP En utilisant \fBcapset\fP(2), un thread peut manipuler ses propres ensembles de capacités\ ; voir \fIAjuster les ensembles de capacités par programmation\fP ci\-dessous). .PP .\" commit 73efc0394e148d0e15583e13712637831f926720 .\" À partir de Linux\ 3.2, le fichier \fI/proc/sys/kernel/cap_last_cap\fP contient la valeur numérique de la capacité la plus élevée qui soit acceptée par le noyau en cours d'exécution\ ; cette valeur peut être utilisée pour déterminer le bit le plus élevé qui puisse être défini dans un ensemble de capacités. .SS "Capacités de fichier" Depuis Linux\ 2.6.24, le noyau prend en charge l'association d'ensembles de capacités avec un fichier exécutable à l'aide de \fBsetcap\fP(8). Les ensembles de capacités du fichier sont stockés dans un attribut étendu (consultez \fBsetxattr\fP(2) et \fBxattr\fP(7)) appelé \fIsecurity.capability\fP. Écrire dans cet attribut étendu nécessite la capacité \fBCAP_SETFCAP\fP. Les ensembles de capacités d'un fichier, combinés avec les ensembles de capacités du thread, déterminent les capacités d'un thread après un \fBexecve\fP(2). .PP Les trois ensembles de capacités de fichier sont\ : .TP \fIPermitted\fP (anciennement \fIforced\fP (forcé))\ : Ces capacités sont automatiquement permises au thread, quelles que soient ses capacités héritables. .TP \fIInheritable\fP (anciennement \fIallowed\fP (autorisé))\ : Cet ensemble est combiné par un ET avec l'ensemble héritable du thread pour savoir quelles capacités de l'ensemble des capacités héritables sont permises dans l’ensemble permis du thread après l'appel à \fBexecve\fP(2). .TP \fIEffective\fP (effectif)\ : Il ne s'agit pas d'un ensemble, mais plutôt d'un unique bit. Si le bit est positionné, alors, lors d'un \fBexecve\fP(2), toutes les nouvelles capacités permises pour le thread sont également positionnées dans l'ensemble effectif. Si ce bit n'est pas positionné, alors, après un \fBexecve\fP(2), aucune des nouvelles capacités permises ne se trouvera dans le nouvel ensemble effectif. .IP .\" Activer le bit des capacités effectives d'un fichier implique que toute capacité de fichier permise ou héritable qui permet à un thread d'obtenir les capacités permises correspondantes lors d'un \fBexecve\fP(2) (consultez \fITransformation des capacités lors d'un appel execve()\fP ci\-dessous) fera que ce fichier aura aussi cette capacité dans son ensemble effectif. Ainsi, lors de l'ajout de capacités à un fichier (\fBsetcap\fP(8), \fBcap_set_file\fP(3), \fBcap_set_fd\fP(3)), si l’attribut effectif pour une des capacités est activé, alors l'attribut effectif doit également être activé pour toutes les autres capacités dont l’attribut permis ou héritable correspondant est activé. .SS "Versionnage d'attributs étendus de capacité de fichier" Pour permettre l'extensibilité, le noyau prend en charge un système pour coder un numéro de version dans l'attribut étendu \fIsecurity.capability\fP qui est utilisé pour implémenter les capacités de fichier. Ces numéros de version sont intégrés à l'implémentation et pas directement visibles aux applications de l'espace utilisateur. À ce jour, les versions suivantes sont prise en charge\ : .TP \fBVFS_CAP_REVISION_1\fP C'était l'implémentation d'origine de la capacité de fichier qui prenait en charge les masques 32\ bits pour les capacités de fichier. .TP \fBVFS_CAP_REVISION_2\fP (depuis Linux\ 2.6.25) .\" commit e338d263a76af78fe8f38a72131188b58fceb591 Cette version permet des masques de capacité de fichier d'une taille de 64\ bits, ce qui était nécessaire, car le nombre de capacités prises en charge dépassait\ 32. Le noyau continue de façon transparente à prendre en charge l'exécution de fichiers qui ont des masques de capacité version\ 1 32\ bits, mais lors de l'ajout de capacités à des fichiers qui n'avaient pas encore de capacités ou lors de la modification des capacités de fichiers existants, il utilise automatiquement le système de la version\ 2 (ou éventuellement la version\ 3, comme décrit plus bas). .TP \fBVFS_CAP_REVISION_3\fP (depuis Linux\ 4.14) .\" commit 8db6c34f1dbc8e06aa016a9b829b06902c3e1340 Les capacités de fichier version\ 3 sont fournies pour prendre en charge les capacités de fichier mises dans un espace de noms (décrites plus bas). .IP Comme avec les capacités de fichier version\ 2, les masques de capacité version\ 3 ont une longueur de 64\ bits. Mais en complément, l'UID root de l'espace de noms est codé dans l'attribut étendu \fIsecurity.capability\fP (un UID root d'espace de noms est la valeur à laquelle l'UID\ 0 dans cet espace de noms correspond dans l'espace de noms utilisateur initial). .IP Les capacités de fichier version\ 3 sont conçues pour coexister avec les capacités version\ 2\ ; c'est\-à\-dire que, sur un système Linux moderne, il peut y avoir certains fichiers avec des capacités version\ 2 tandis que d'autres ont des capacités version\ 3. .PP Avant Linux\ 4.14, le seul type d'attribut étendu de capacité de fichier qui pouvait être attaché à un fichier était un attribut \fBVFS_CAP_REVISION_2\fP. Depuis Linux\ 4.14, la version de l'attribut étendu \fIsecurity.capability\fP attaché à un fichier dépend des circonstances dans lesquelles l'attribut a été créé. .PP À partir de Linux\ 4.14, un attribut étendu \fIsecurity.capability\fP est créé automatiquement (ou converti) en attribut version\ 3 (\fBVFS_CAP_REVISION_3\fP) si les deux conditions suivantes sont vraies\ : .IP \- 3 Le thread qui écrit l'attribut réside dans un espace de noms utilisateur non initial (plus précisément, le thread réside dans un espace de noms utilisateur autre que celui à partir duquel le système de fichiers sous\-jacent a été monté). .IP \- Le thread a la capacité \fBCAP_SETFCAP\fP sur l'inœud du fichier, ce qui veut dire que (a) le thread a la capacité \fBCAP_SETFCAP\fP dans son propre espace de noms utilisateur et (b) l'UID et le GID de l'inœud du fichier a des correspondances dans l'espace de noms utilisateur de celui qui écrit. .PP Quand un attribut étendu \fIsecurity.capability\fP \fBVFS_CAP_REVISION_3\fP est créé, l'UID root de l'espace de noms utilisateur du thread qui crée l'attribut est enregistré dans l'attribut étendu. .PP Par contre, la création ou la modification d'un attribut étendu \fIsecurity.capability\fP à partir d'un thread privilégié (\fBCAP_SETFCAP\fP) qui réside dans l'espace de noms où le système de fichiers sous\-jacent a été monté (ce qui correspond normalement à l'espace de noms utilisateur initial) a automatiquement pour conséquence la création d'un attribut version\ 2 (\fBVFS_CAP_REVISION_2\fP). .PP Veuillez noter que la création d'un attribut étendu \fIsecurity.capability\fP version\ 3 est automatique. C'est\-à\-dire que losrsqu'une application de l'espace utilisateur écrit (\fBsetxattr\fP(2)) un attribut \fIsecurity.capability\fP au format de la version\ 2, le noyau créera automatiquement un attribut version\ 3 si l'attribut est créé dans les conditions décrites plus haut. En parallèle, quand un attribut \fIsecurity.capability\fP version\ 3 est récupéré (\fBgetxattr\fP(2)) par un processus qui réside dans un espace de noms utilisateur qui a été créé par l'UID root (ou un descendant de cet espace de noms utilisateur), l'attribut renvoyé est (automatiquement) simplifié pour apparaître comme un attribut version\ 2 (c'est\-à\-dire que la valeur renvoyée est la taille de l'attribut version\ 2 et n'inclut pas l'UID root). Ces transpositions automatiques signifient qu'aucune modification n'est requise pour les outils de l'espace utilisateur (par exemple \fBsetcap\fP(1) \fBgetcap\fP(1)) pour que ces outils soient utilisés pour créer et récupérer des attributs \fIsecurity.capability\fP version\ 3. .PP .\" Veuillez noter qu'un fichier peut se voir associé un attribut étendu \fIsecurity.capability\fP version\ 2 ou version\ 3, mais pas les deux à la fois\ : la création ou la modification de l'attribut étendu \fIsecurity.capability\fP modifiera automatiquement la version selon les conditions dans lesquelles l'attribut étendu est créé ou modifié. .SS "Transformation des capacités lors d'un appel execve()" Durant un \fBexecve\fP(2), le noyau calcule les nouvelles capacités du processus en utilisant l'algorithme suivant\ : .PP .in +4n .EX P'(ambient) = (le fichier est privilégié) ? 0 : P(ambient) \& P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding)) | P'(ambient) \& P'(effective) = F(effective) ? P'(permitted) : P'(ambient) \& P'(inheritable) = P(inheritable) [c'est\-à\-dire inchangé] \& P'(bounding) = P(bounding) [c'est\-à\-dire inchangé] .EE .in .PP où\ : .RS 4 .TP P() indique la valeur d'un ensemble de capacités du thread avant le \fBexecve\fP(2) .TP P'() indique la valeur d'un ensemble de capacités du thread après le \fBexecve\fP(2) .TP F() indique la valeur d'un ensemble de capacités du fichier .RE .PP Veuillez noter les détails suivants concernant les règles de transformation de capacités ci\-dessus\ : .IP \- 3 L'ensemble de capacités ambiantes est présent seulement depuis Linux\ 4.3. Lors de la détermination de la transformation de l'ensemble ambiant durant un \fBexecve\fP(2), un fichier privilégié est un fichier qui a des capacités ou le bit set\-user\-ID ou le bit set\-group\-ID positionné. .IP \- Avant Linux\ 2.6.25, l'ensemble de limitation de capacités était un attribut au niveau du système, partagé par tous les threads. Cette valeur au niveau du système était employée pour calculer le nouvel ensemble de capacités permises durant un \fBexecve\fP(2) de la même manière que cela est montré plus haut pour \fIP(bounding)\fP. .PP \fINote\fP\ : durant les transitions de capacité décrite plus haut, les capacités de fichier peuvent être ignorées (traitées comme si elles étaient vides) pour les mêmes raisons que les bits set\-user\-ID et set\-group\-ID sont ignorés\ ; voir \fBexecve\fP(2). Les capacités de fichier sont ignorées de la même manière si le noyau a été lancé avec l'option \fIno_file_caps\fP. .PP .\" \fINote\fP\ : conformément aux règles ci\-dessus, si un processus avec des UID différents de zéro exécutent un \fBexecve\fP(2), alors toutes les capacités présentes dans son ensemble de capacités permises et effectives seront supprimées. Pour le traitement de capacités quand un processus avec un UID de zéro exécute un \fBexecve\fP(2), consultez ci\-dessous \fICapacités et exécution de programmes par le superutilisateur\fP. .SS "Vérification de sécurité pour les binaires passives aux capacités" Un binaire passif aux capacités est une application qui a été marquée pour avoir des capacités de fichier, mais n'a pas été convertie pour utiliser l'API \fBlibcap\fP(3) pour manipuler ses capacités (en d'autres mots, c'est un programme set\-user\-iD\-root traditionnel qui a été modifié pour utiliser des capacités de fichier, mais dont le code n'a pas été modifié pour comprendre les capacités). Pour ce type d'application, le bit de capacité effective est défini sur le fichier, de telle sorte que les capacités de fichier permises soient activées automatiquement dans l'ensemble de capacités effectives du processus lors de l'exécution du fichier. Le noyau reconnaît un fichier qui a un bit de capacité effective défini comme passif aux capacités en vue de la vérification décrite ici. .PP .\" Lors de l'exécution d'un binaire passif aux capacités, le noyau vérifie si le processus a obtenu toutes les capacités permises qui sont spécifiées dans l'ensemble de capacités permises de fichier, après que les transformations de capacité décrites plus haut ont été exécutées (la raison habituelle pour laquelle cela pourrait \fIne pas\fP se produire est que l'ensemble de limitation de capacités a interdit certaines des capacités dans l'ensemble de capacités permises de fichier). Si le processus n'obtient pas l'ensemble complet de capacités permises de fichier, alors l'\fBexecve\fP(2) échoue avec l'erreur \fBEPERM\fP. Cela évite de possibles risques de sécurité qui pourraient survenir quand une application passive aux capacités est exécutée avec moins de privilèges que nécessaire. Notez que, par définition, l'application ne pourrait pas reconnaître elle\-même ce problème, dans la mesure où elle n'emploie pas l'API \fBlibcap\fP(3). .SS "Capacités et exécution de programmes par le superutilisateur" .\" See cap_bprm_set_creds(), bprm_caps_from_vfs_cap() and .\" handle_privileged_root() in security/commoncap.c (Linux 5.0 source) Afin de refléter les sémantiques traditionnelles d'UNIX, le noyau effectue un traitement particulier des capacités de fichier quand un processus avec l'UID\ 0 (superutilisateur) exécute un programme et quand un programme set\-user\-ID\-root est exécuté. .PP Après avoir réalisé toutes les modifications de l'ID effectif du processus qui ont été déclenchées par le bit de mode set\-user\-ID du binaire (par exemple, le changement de l'UID à\ 0 (superutilisateur) parce qu'un programme set\-user\-ID\-root a été exécuté), le noyau calcule les ensembles de capacités de fichier comme suit\ : .IP (1) 5 Si l'UID réel ou effectif du processus est\ 0 (superutilisateur), alors les ensembles de capacités héritables et permises de fichier sont ignorés\ ; ils sont plutôt considérés théoriquement comme remplis de uns (c'est\-à\-dire, toutes les capacités activées). Il y a une exception à ce comportement, décrite ci\-dessous dans la section \fIProgrammes set\-user\-ID\-root qui ont des capacités de fichier\fP. .IP (2) Si l'UID effectif du processus est\ 0 (superutilisateur) ou le bit des capacités effectives du fichier est en fait activé, alors le bit des capacités effectives du fichier est théoriquement défini à un (activé). .PP Ces valeurs théoriques pour les ensembles de capacités de fichier sont alors utilisées comme décrites ci\-dessus pour calculer la transformation des capacités du processus durant l'\fBexecve\fP(2). .PP Alors, quand un processus avec des UID différents de zéro appelle \fBexecve\fP(2) sur un programme set\-user\-ID\-root qui n'a pas de capacités attachées ou quand un processus dont les UID réel et effectif sont zéro applique \fBexecve\fP(2) sur un programme, le calcul des nouvelles capacités permises du processus est simplifié à\ : .PP .in +4n .EX P'(permitted) = P(inheritable) | P(bounding) \& P'(effective) = P'(permitted) .EE .in .PP En conséquence, le processus obtient toutes les capacités dans ses ensembles de capacités permises et effectives, à l'exception de celles supprimées par l'ensemble de limitation de capacités (dans le calcul de P'(permitted), le terme P'(ambient) peut être simplifié parce qu'il est par définition un sous\-ensemble propre de P(inheritable)). .PP .\" .\" Les traitements particuliers de l'UID\ 0 (superutilisateur) décrits dans cette sous\-section peuvent être désactivés en utilisant le mécanisme de «\ securebits\ » décrit plus bas. .SS "Les programmes set\-user\-ID\-root qui ont des capacités de fichier" Il y a une exception au comportement décrit dans \fICapacités et exécution de programmes par le superutilisateur\fP ci\-dessus. Si (a) le binaire qui est en cours d'exécution a des capacités attachées, (b) l'UID réelle du processus \fIn'est\fP pas\ 0 (supertutilisateur) et (c) l'UID effectif du processus \fIest\fP\ 0 (superutilisateur), alors les bits de capacité de fichier sont honorés (c'est\-à\-dire qu'ils ne sont pas théoriquement considérés comme remplis de uns). La circonstance habituelle dans laquelle cette situation peut se produire est lors de l'exécution d'un programme set\-user\-ID\-root qui a aussi les capacités de fichier. Quand un programme de ce type est exécuté, le processus obtient simplement les capacités accordées par le programme (c'est\-à\-dire pas toutes les capacités comme cela pourrait se produire lors de l'exécution d'un programme set\-user\-ID\-root qui ne possède aucune capacité de fichier associée). .PP .\" Notez qu'il est possible d'assigner un ensemble de capacités vide à un fichier de programme et donc qu'il est possible de créer un programme set\-user\-ID\-root qui modifie en\ 0 le set\-user\-ID effectif et sauvegardé du processus qui exécute le programme, mais ne confère aucune capacité à ce processus. .SS "Ensemble de limitation des capacités" L’ensemble de limitation des capacités («\ capability bounding set\ ») est un mécanisme de sécurité qui peut être utilisé pour limiter les capacités qui peuvent être obtenues lors d'un \fBexecve\fP(2). L’ensemble de limitation de capacités est utilisé de cette façon\ : .IP \- 3 Lors d'un \fBexecve\fP(2), l’ensemble de limitation de capacités est combinée par un ET binaire avec l'ensemble des capacités autorisées du fichier, et le résultat de cette opération est placé dans l'ensemble des capacités autorisées du thread. L’ensemble de limitation de capacités permet donc de limiter les capacités permises qui peuvent être accordées par un fichier exécutable. .IP \- (Depuis Linux\ 2.6.25) L’ensemble de limitation de capacités agit comme un surensemble limitant les capacités qu'un thread peut ajouter à son ensemble de capacités héritables en utilisant \fBcapset\fP(2). Cela signifie que si une capacité ne se trouve pas dans l'ensemble de limitation des capacités, alors un thread ne peut ajouter cette capacité dans son ensemble de capacités héritables, même si elle se trouvait dans son ensemble de capacités permises, et ne peut donc pas conserver cette capacité dans son ensemble de capacités permises lorsqu'il exécute avec \fBexecve\fP(2) un fichier qui a cette capacité dans son ensemble de capacités héritables. .PP Notez que l’ensemble de limitation de capacités masque les capacités permises du fichier, mais pas les capacités héritées. Si un thread conserve une capacité dans son ensemble de capacités héritées et que cette capacité ne se trouve pas dans l'ensemble de limitation des capacités, alors il peut toujours obtenir cette capacité dans son ensemble de capacités permises en exécutant un fichier qui a la capacité dans son ensemble de capacités héritées. .PP Suivant la version du noyau, l’ensemble de limitation de capacités est un attribut au niveau du système ou un attribut par processus. .PP \fBEnsemble de limitation de capacités après Linux\ 2.6.25\fP .PP Depuis Linux\ 2.6.25, l’\fIensemble de limitation de capacités\fP est un attribut par thread. (L'ensemble de limitation de capacités au niveau du système décrite ci\-dessous n'existe plus.) .PP L’ensemble de limitation est hérité du parent du thread au travers d'un \fBfork\fP(2) et est préservé au travers d'un \fBexecve\fP(2). .PP Un thread peut enlever des capacités de son ensemble de limitation de capacités en utilisant l'opération \fBPR_CAPBSET_DROP\fP de \fBprctl\fP(2), à condition qu'il possède la capacité \fBCAP_SETPCAP\fP. Une fois qu'une capacité a été supprimée de l'ensemble de limitation, elle ne peut y être remise. Un thread peut déterminer si une capacité est dans son ensemble de limitation de capacités en utilisant l'opération \fBPR_CAPBSET_READ\fP de \fBprctl\fP(2). .PP .\" commit b3a222e52e4d4be77cc4520a57af1a4a0d8222d1 La suppression de capacités dans l'ensemble de limitation des capacités n'est prise en charge que si les capacités de fichier sont compilées dans le noyau. Avant Linux\ 2.6.33, les capacités de fichier étaient une fonctionnalité optionnelle configurable ua moyen de l'option \fBCONFIG_SECURITY_FILE_CAPABILITIES\fP. Depuis Linux\ 2.6.33, l'option de configuration a été supprimée et les capacités de fichier font maintenant toujours partie du noyau. Quand les capacités de fichier sont compilées dans le noyau, le processus \fBinit\fP (l'ancêtre de tous les processus) démarre avec un ensemble de limitation complet. Si les capacités de fichier ne sont pas compilées dans le noyau, \fBinit\fP démarre alors avec un ensemble de limitation complet, à l'exception de \fBCAP_SETPCAP\fP, parce que cette capacité a une autre signification quand il n'y a pas de capacités de fichier. .PP Supprimer une capacité de l’ensemble de limitation de capacités ne la supprime pas de l'ensemble héritable d'un thread. Cependant, il empêche de rajouter la capacité dans l'ensemble héritable du thread par la suite. .PP \fBEnsemble de limitation de capacités avant Linux\ 2.6.25\fP .PP Avant Linux\ 2.6.25, l’ensemble de limitation de capacités est un attribut au niveau du système qui affecte tous les threads. L’ensemble de limitation de capacités est accessible par le fichier \fI/proc/sys/kernel/cap\-bound\fP (le masque de bits est exprimé comme un nombre décimal signé dans \fI/proc/sys/kernel/cap\-bound\fP, ce qui entretient les confusions). .PP Seul le processus \fBinit\fP peut configurer des capacités dans l'ensemble de limitation de capacités\ ; en dehors de cela, le superutilisateur (plus précisément\ : un processus avec la capacité \fBCAP_SYS_MODULE\fP) peut uniquement supprimer des capacités de cet ensemble. .PP Sur un système standard, l’ensemble de limitation élimine toujours la capacité \fBCAP_SETPCAP\fP. Pour supprimer cette restriction (attention, c'est dangereux\ !), modifiez la définition de \fBCAP_INIT_EFF_SET\fP dans \fIinclude/linux/capability.h\fP et recompilez le noyau. .PP .\" .\" .\" L’ensemble de limitation de capacités pour tout le système a été ajoutée à Linux\ 2.2.11. .SS "Effet des modifications d'UID sur les capacités" Afin de préserver la sémantique traditionnelle pour les transitions entre des UID\ 0 et des UID différents de zéro, le noyau modifie les ensembles de capacités d'un thread de la façon suivante lors de modifications des UID réel, effectif, sauvegardé et du système de fichiers (avec \fBsetuid\fP(2), \fBsetresuid\fP(2) et compagnie)\ : .IP \- 3 Si un ou plus des UID réels, effectifs ou sauvés étaient égal à\ 0, et qu'à la suite de la modification d'UID, tous ces ID ont une valeur différente de zéro, et toutes les capacités sont supprimées des ensembles de capacités permises, effectives et ambiantes. .IP \- Si l'UID effectif était\ 0 et devient différent de zéro, toutes les capacités sont supprimées de l'ensemble effectif. .IP \- Si l'UID effectif est modifié d'une valeur différente de zéro à\ 0, l'ensemble des capacités permises est copié dans l'ensemble des capacités effectives. .IP \- Si l’UID du système de fichiers est modifié de\ 0 à une valeur différente de zéro (consultez \fBsetfsuid\fP(2)), les capacités suivantes sont supprimées de l'ensemble effectif\ : \fBCAP_CHOWN\fP, \fBCAP_DAC_OVERRIDE\fP, \fBCAP_DAC_READ_SEARCH\fP, \fBCAP_FOWNER\fP, \fBCAP_FSETID\fP, \fBCAP_LINUX_IMMUTABLE\fP (depuis Linux\ 2.6.30), \fBCAP_MAC_OVERRIDE\fP et \fBCAP_MKNOD\fP (depuis Linux\ 2.6.30). Si l’UID du système de fichiers devient\ 0, chacune de ces capacités est activée dans l'ensemble des capacités effectives si elle faisait partie de l'ensemble des capacités permises. .PP .\" Si un thread qui a une valeur\ 0 pour un ou plus de ses UID ne veut pas que son ensemble de capacités permises soit vidé lorsqu'il redéfinit tous ses UID à des valeurs non nulles, il peut le faire avec l'attribut «\ securebits\ » de \fBSECBIT_KEEP_CAPS\fP décrit ci\-dessous. .SS "Ajuster les ensembles de capacités par programmation" Un thread peut obtenir ou modifier ses ensembles de capacités permises, effectives et héritées en utilisant les appels système \fBcapget\fP(2) et \fBcapset\fP(2). Cependant, il faut leur préférer l'utilisation de \fBcap_get_proc\fP(3) et \fBcap_set_proc\fP(3), toutes deux fournies par le paquet \fIlibcap\fP. Les règles suivantes gouvernent les modifications des ensembles de capacités d'un thread\ : .IP \- 3 Si l'appelant n'a pas la capacité \fBCAP_SETPCAP\fP, le nouvel ensemble des capacités héritables doit être un sous\-ensemble de l'union des ensembles de capacités héritables et des capacités permises. .IP \- (Depuis Linux\ 2.6.25) Le nouvel ensemble héritable doit être un sous\-ensemble de l'ensemble héritable existant et de l'ensemble de limitation de capacités. .IP \- Le nouvel ensemble des capacités permises doit être un sous\-ensemble de l'ensemble des capacités permises existant (c'est\-à\-dire qu'il n'est pas possible d'obtenir des capacités permises que le thread n'a pas actuellement). .IP \- Le nouvel ensemble effectif doit être un sous\-ensemble du nouvel ensemble des capacités permises. .SS "Les attributs «\ securebits\ »\ : configuration d'un environnement restreint aux capacités de fichier." .\" For some background: .\" see http://lwn.net/Articles/280279/ and .\" http://article.gmane.org/gmane.linux.kernel.lsm/5476/ À partir de Linux\ 2.6.26, si les capacités de fichier sont activées dans le noyau, Linux implémente un ensemble d'attributs \fIsecurebits\fP par thread qui peuvent être utilisés pour désactiver la gestion particulière des capacités pour l'UID\ 0 (\fIroot\fP). Ces attributs sont les suivants\ : .TP \fBSECBIT_KEEP_CAPS\fP Activer cet attribut permet à un thread qui a un UID (ou plus) égal à\ 0 de conserver ses capacités dans son ensemble des capacités permises quand il change tous ses UID et que plus aucun n'est zéro. Si cet attribut est désactivé, alors ces changements d'UID feront perdre au thread toutes ses capacités permises. Cet attribut est toujours désactivé lors d'un \fBexecve\fP(2). .IP Notez que même quand l'attribut \fBSECBIT_KEEP_CAPS\fP est actif, les capacités effectives d'un thread sont supprimées quand il change son UID effectif pour une valeur différente de zéro. Néanmoins, si le thread a activé cet attribut et que son UID effectif est déjà différent de zéro et si le thread change ensuite tous les autres UID pour des valeurs différentes de zéro, alors, les capacités effectives ne seront pas supprimées. .IP L'activation de l'attribut \fBSECBIT_KEEP_CAPS\fP est ignorée si l'attribut \fBSECBIT_NO_SETUID_FIXUP\fP est actif (ce dernier attribut fournit un surensemble des effets de l'attribut précédent). .IP Cet attribut fournit la même fonctionnalité que l'ancienne opération \fBPR_SET_KEEPCAPS\fP de \fBprctl\fP(2). .TP \fBSECBIT_NO_SETUID_FIXUP\fP Activer cet attribut stoppe l'ajustement des ensembles de capacités permises, effectives et ambiantes du processus par le noyau lorsque les UID effectifs et du système de fichiers du thread passent d'une valeur zéro à une valeur différente de zéro. Consultez \fIEffet des modifications d'UID sur les capacités\fP plus haut. .TP \fBSECBIT_NOROOT\fP Si cet attribut est activé, alors le noyau n'accorde pas les capacités lorsqu'un programme set\-user\-ID\-root est exécuté ou lorsqu'un processus dont l'UID effectif ou réel est zéro appelle \fBexecve\fP(2) (consultez \fICapacités et exécution de programmes par le superutilisateur\fP ci\-dessus). .TP \fBSECBIT_NO_CAP_AMBIENT_RAISE\fP Activer cet attribut désactive l'élévation des capacités ambiantes au moyen de l'opération \fBPR_CAP_AMBIENT_RAISE\fP de \fBprctl\fP(2). .PP Chacun des attributs de «\ base\ » ci\-dessus a un attribut compagnon «\ verrouillé\ ». L'activation d'un attribut «\ verrouillé\ » est irréversible et permet d'éviter toute modification ultérieure de l'attribut de «\ base\ » correspondant. Les attributs «\ verrouillé\ » sont\ : \fBSECBIT_KEEP_CAPS_LOCKED\fP, \fBSECBIT_NO_SETUID_FIXUP_LOCKED\fP, \fBSECBIT_NOROOT_LOCKED\fP et \fBSECBIT_NO_CAP_AMBIENT_RAISE_LOCKED\fP. .PP Les attributs \fIsecurebits\fP peuvent être modifiés et récupérés en utilisant les opérations \fBPR_SET_SECUREBITS\fP et \fBPR_GET_SECUREBITS\fP de \fBprctl\fP(2). La capacité \fBCAP_SETPCAP\fP est nécessaire pour modifier ces attributs. Notez que les constantes \fBSECBIT_*\fP ne sont disponibles qu'après l'inclusion du fichier d'en\-tête \fI\fP. .PP Les attributs \fIsecurebits\fP sont hérités par les processus enfants. Lors d'un \fBexecve\fP(2), tous les attributs sont conservés, à l'exception de \fBSECBIT_KEEP_CAPS\fP qui est toujours désactivé. .PP Une application peut utiliser l'appel suivant pour se verrouiller elle\-même, ainsi que tous ses descendants, dans un environnement où la seule façon d'obtenir des capacités est d'exécuter un programme avec les capacités de fichiers associées\ : .PP .in +4n .EX prctl(PR_SET_SECUREBITS, /* SECBIT_KEEP_CAPS désactivé */ SECBIT_KEEP_CAPS_LOCKED | SECBIT_NO_SETUID_FIXUP | SECBIT_NO_SETUID_FIXUP_LOCKED | SECBIT_NOROOT | SECBIT_NOROOT_LOCKED); /* Activation/verrouillage de SECBIT_NO_CAP_AMBIENT_RAISE non requis */ .EE .in .\" .\" .SS "Programmes «\ set\-user_ID\-root\ » par espace de noms utilisateur" Un programme set\-user\-ID dont l'UID correspond à l'UID qui a créé par un espace de noms utilisateur donnera des capacités dans les ensembles de capacités permises et effectives du processus lorsqu'il était utilisé par un processus dans l'espace de noms ou tout espace de noms utilisateur qui en est issu. .PP .\" .\" Les règles de transformation des capacités du processus pendant un \fBexecve\fP(2) sont exactement comme décrites dans \fITransformation des capacités lors d'un appel execve()\fP et \fICapacités et exécution de programmes par le superutilisateur\fP ci\-dessus;à la différence que, dans la seconde sous\-section, «\ root\ » est l'UID du créateur de l'espace de noms utilisateur. .SS "Capacités de fichier mises dans un espace de noms" .\" commit 8db6c34f1dbc8e06aa016a9b829b06902c3e1340 Les capacités de fichier traditionnelles (c'est\-à\-dire version\ 2) n'associent qu'un ensemble de masques de capacité à un fichier binaire exécutable. Quand un processus exécute un binaire avec des capacités de ce type, il obtient les capacités associées (dans son espace de noms utilisateur) comme pour les règles décrites ci\-dessus dans \fITransformation des capacités lors d'un appel execve()\fP. .PP Étant donné que les capacités de fichier version\ 2 confèrent des capacités pour l'exécution de processus quel que soit l'espace de noms utilisateur dans lequel il réside, seuls les processus privilégiés ont le droit d'associer des capacités avec un fichier. Ici, «\ privilégié\ » veut dire un processus qui a la capacité \fBCAP_SETFCAP\fP dans l'espace de noms utilisateur où le système de fichiers a été monté (normalement, l'espace de noms initial de l'utilisateur). Cette limitation rend les capacités de fichier inutiles dans certains cas d'usage. Par exemple, dans les conteneurs d'un espace de noms utilisateur, il peut être souhaitable de pouvoir créer un binaire qui confère des capacités uniquement au processus exécuté dans ce conteneur, mais pas aux processus exécutés en dehors du conteneur. .PP Linux\ 4.14 a ajouté des capacités de fichier appelées «\ mises dans un espace de noms\ » pour gérer ce genre de cas d'usage. Les capacités de fichier mises dans un espace de noms sont enregistrées en tant qu'attribut étendu \fIsecurity.capability\fP version\ 3 (c'est\-à\-dire \fBVFS_CAP_REVISION_3\fP). Un attribut de ce type est créé automatiquement dans les circonstances décrites ci\-dessus dans \fIVersionnage d'attributs étendus de capacité de fichier\fP. Quand un attribut étendu \fIsecurity.capability\fP version\ 3 est créé, le noyau n'enregistre pas que les masques de capacité dans l'attribut étendu, mais aussi l'UID root de l'espace de noms. .PP .\" .\" Comme c'est le cas avec un binaire qui possède des capacités de fichier \fBVFS_CAP_REVISION_2\fP, un binaire avec des capacités de fichier \fBVFS_CAP_REVISION_3\fP confère des capacités à un processus durant un \fBexecve\fP(). Néanmoins, ces capacités ne sont conférées que si le processus est exécuté par un processus qui réside dans un espace de noms utilisateur dont l'UID\ 0 correspond à l'UID root qui est sauvegardé dans l'attribut étendu, ou quand il est exécuté par un processus qui réside dans un descendant de ce type d'espace de noms. .SS "Interaction avec les espaces de noms" Pour en savoir plus sur les interactions entre les capacités et les espaces de noms utilisateur, consultez \fBuser_namespaces\fP(7). .SH STANDARDS Il n'y a pas de véritable norme pour les capacités, mais l'implémentation de Linux est basée sur une interprétation de l’avant\-projet de norme (retiré) POSIX.1e .UR https://archive.org\:/details\:/posix_1003.1e\-990310 .UE . .SH NOTES Quand vous tentez de suivre avec \fBstrace\fP(1) des binaires qui ont des capacités (ou des binaires set\-user\-UID\-root), vous pouvez trouver l'option \fI\-u \fP. Quelque chose comme ceci\ : .PP .in +4n .EX $ \fBsudo strace \-o trace.log \-u ceci ./mon_prog_privé\fP .EE .in .PP .\" commit 5915eb53861c5776cfec33ca4fcc1fd20d66dd27 removed .\" CONFIG_SECURITY_CAPABILITIES De Linux\ 2.5.27 à Linux\ 2.6.26, les capacités étaient un composant optionnel du noyau et pouvaient être activées ou désactivées avec l'option de configuration \fBCONFIG_SECURITY_CAPABILITIES\fP du noyau. .PP .\" 7b9a7ec565505699f503b4fcf61500dceb36e744 Le fichier \fI/proc/\fPpid\fI/task/TID/status\fP peut être utilisé pour voir les ensembles de capacités d'un thread. Le fichier \fI/proc/\fPpid\fI/status\fP indique les ensembles de capacités du thread principal d'un processus. Avant Linux\ 3.8, les capacités inexistantes étaient vues comme activées\ (1) dans ces ensembles. Depuis Linux\ 3.8, toutes les capacités inexistantes (supérieures à la valeur de \fBCAP_LAST_CAP\fP) sont vues comme désactivées\ (0). .PP Le paquet \fIlibcap\fP fournit un ensemble de routines pour écrire et connaître les capacités d'un processus de manière plus simple et moins susceptible de changer que l'interface fournie par \fBcapset\fP(2) et \fBcapget\fP(2). Ce paquet fournit également les programmes \fBsetcap\fP(8) et \fBgetcap\fP(8). Il peut être trouvé à l'adresse\ : .br .UR https://git.kernel.org\:/pub\:/scm\:/libs\:/libcap\:/libcap.git\:/refs/ .UE . .PP Avant Linux\ 2.6.24, et de Linux\ 2.6.24 à Linux\ 2.6.32, si les capacités de fichier ne sont pas activées, un thread avec la capacité \fBCAP_SETPCAP\fP peut manipuler les capacités des autres threads. Cependant, ce n'est possible qu'en théorie puisqu'aucun thread n'a la capacité \fBCAP_SETPCAP\fP dans un des cas suivants\ : .IP \- 3 Dans l'implémentation antérieure au noyau\ 2.6.25, l'ensemble de limitation de capacités du système, \fI/proc/sys/kernel/cap\-bound\fP, masque toujours la capacité \fBCAP_SETPCAP\fP et cela ne peut pas être changé sans modifier les sources du noyau et le recompiler. .IP \- Si les capacités de fichier sont désactivées (c'est\-à\-dire si l'option \fBCONFIG_SECURITY_FILE_CAPABILITIES\fP du noyau est désactivée), alors \fBinit\fP démarre sans la capacité \fBCAP_SETPCAP\fP dans l'ensemble de limitation de capacités par processus, et cet ensemble de limitation de capacité est hérité par tous les processus créés sur le système. .SH "VOIR AUSSI" .\" from libcap-ng .\" from libcap-ng .\" from libcap-ng .\" from libcap-ng \fBcapsh\fP(1), \fBsetpriv\fP(1), \fBprctl\fP(2), \fBsetfsuid\fP(2), \fBcap_clear\fP(3), \fBcap_copy_ext\fP(3), \fBcap_from_text\fP(3), \fBcap_get_file\fP(3), \fBcap_get_proc\fP(3), \fBcap_init\fP(3), \fBcapgetp\fP(3), \fBcapsetp\fP(3), \fBlibcap\fP(3), \fBproc\fP(5), \fBcredentials\fP(7), \fBpthreads\fP(7), \fBuser_namespaces\fP(7), \fBcaptest\fP(8), \fBfilecap\fP(8), \fBgetcap\fP(8), \fBgetpcaps\fP(8), \fBnetcap\fP(8), \fBpscap\fP(8), \fBsetcap\fP(8) .PP \fIinclude/linux/capability.h\fP dans les sources du noyau Linux .PP .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot , Cédric Boutillier , Frédéric Hantrais et Jean-Pierre Giraud . .PP Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. .PP Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à .MT debian-l10n-french@lists.debian.org .ME .