capabilities

CAPABILITIES(7)           Manuel du programmeur Linux          CAPABILITIES(7)



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. Les capacités sont des attributs individuels
       Ã  chaque thread.

   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 :

       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)
              Ãcrire des enregistrements dans le journal d'audit du noyau.

       CAP_BLOCK_SUSPEND (depuis Linux 3.5)
              Utiliser des fonctionnalités qui peuvent bloquer la mise en
              veille du système (epoll(7) EPOLLWAKEUP, /proc/sys/wake_lock).

       CAP_CHOWN
              Effectuer toute modification des UID et GID de fichiers
              (consultez chown(2)).

       CAP_DAC_OVERRIDE
              Contourne les permissions de lecture, écriture et exécution.
              (DAC est l'abréviation de « 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 ;
              * Invoque open_by_handle_at(2).


       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 CAP_DAC_OVERRIDE et
                CAP_DAC_READ_SEARCH ;
              * positionner les attributs de fichier étendus (consultez
                chattr(1)) pour n'importe quel fichier ;
              * positionner les listes de contrôle d'accès ACL (« Access
                Control Lists ») pour n'importe quel fichier ;
              * ignorer le bit sticky des répertoires pour les suppressions
                de fichier ;
              * spécifier O_NOATIME dans open(2) et fcntl(2) pour n'importe
                quel fichier.

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

       CAP_IPC_LOCK
              Verrouiller des 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
              System V.

       CAP_KILL
              Contourne les vérifications pour l'émission de signaux
              (consultez kill(2)). Cela inclut l'utilisation de l'ioctl(2)
              KDSIGACCEPT.

       CAP_LEASE (depuis Linux 2.4)
              Demander des baux sur n'importe quel fichier (consultez
              fcntl(2)).

       CAP_LINUX_IMMUTABLE
              Positionner les attributs d'inÅuds FS_APPEND_FL et
              FS_IMMUTABLE_FL (consultez chattr(1)).

       CAP_MAC_ADMIN (depuis Linux 2.6.25)
              Surcharger les contrôles d'accès MAC (« Mandatory Access
              Control »). Implémentée pour le module de sécurité (LSM :
              « Linux Security Module ») Smack.

       CAP_MAC_OVERRIDE (depuis Linux 2.6.25)
              Permettre les modifications de la configuration ou des états
              MAC. Implémentée pour le LSM Smack.

       CAP_MKNOD (depuis Linux 2.4)
              Créer des fichiers spéciaux avec mknod(2).

       CAP_NET_ADMIN
              Effectuer diverses opérations liées au réseau :
              * configuration des interfaces ;
              * administration du pare-feu, de la traduction d'adresse IP
                (« masquerading ») et collection de données sur le trafic
                réseau (« accounting ») ;
              * modification des tables de routages ;
              * attachement à n'importe quelle adresse pour un service
                mandataire transparent ;
              * sélection du type de service (« TOS ») ;
              * effacement des statistiques du pilote ;
              * sélection du mode « promiscuité » ;
              * activation de la diffusion multipoint (« multicast ») ;
              * utiliser setsockopt(2) pour définir les options de sockets
                suivantes : SO_DEBUG, SO_MARK, SO_PRIORITY (pour une priorité
                en dehors des valeurs de 0 Ã  6), SO_RCVBUFFORCE et
                SO_SNDBUFFORCE.

       CAP_NET_BIND_SERVICE
              Attacher une socket sur un port privilégié (numéro de port
              inférieur à 1024).

       CAP_NET_BROADCAST
              (Inutilisé) Broadcaster et écouter en multicast avec des
              sockets.

       CAP_NET_RAW
              * utiliser des sockets RAW et PACKET ;
              * attacher à n'importe quelle adresse pour un service
                mandataire transparent.

       CAP_SETGID
              Effectuer toute manipulation des GID du processus et de la liste
              de groupes supplémentaires, utiliser de faux GID sur les socket
              UNIX.

       CAP_SETFCAP (depuis Linux 2.6.24)
              Définir des capacités de fichier

       CAP_SETPCAP
              Si les capacités de fichier sont prises en charge : autoriser
              ou interdire toute capacité dans l'ensemble des capacités
              permises à l'appelant vers ou depuis tout autre processus.
              (Cette propriété de CAP_SETPCAP n'est pas disponible quand le
              noyau est configuré pour prendre en charge les capacité de
              fichiers, puisque CAP_SETPCAP a une toute autre sémantique pour
              ces noyaux)

              Si les capacités de fichier sont prises en charge : 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
              prctl(2) PR_CAPBSET_DROP) ; modifier l'attribut securebits.

       CAP_SETUID
              Effectuer toute manipulation des UID de processus (setuid(2),
              setreuid(2), setresuid(2), setfsuid(2)) ; transmettre un faux
              UID sur une socket dans le domaine UNIX.

       CAP_SYS_ADMIN
              * Effectuer certaines opérations d'administration comme :
                quotactl(2), mount(2), umount(2), swapon(2), swapoff(2),
                sethostname(2) et setdomainname(2) ;
              * effectuer des opérations syslog(2) nécessitant des droits
                (depuis Linux 2.6.37, CAP_SYSLOG doit être utilisée pour
                permettre de telles opérations) ;
              * effectuer une commande VM86_REQUEST_IRQ vm86(2) ;
              * effectuer des opérations IPC_SET et IPC_RMID sur n'importe
                quel objet IPC System V ;
              * ne pas tenir compte de la limite de ressource RLIMIT_NPROC ;
              * effectuer des opérations sur les attributs étendus trusted
                et security (consultez attr(5)) ;
              * utiliser lookup_dcookie(2) ;
              * utiliser ioprio_set(2) pour configurer une classe
                d'ordonnancement IOPRIO_CLASS_RT (avant Linux 2.6.25) et
                IOPRIO_CLASS_IDLE ;
              * forger des identifiants d'utilisateur lors du passage de
                références de sockets ;
              * dépasser /proc/sys/fs/file-max, la limite système du nombre
                de fichiers ouverts, dans les appels système qui ouvrent des
                fichiers (c'est-Ã -dire accept(2), execve(2), open(2) et
                pipe(2)) ;
              * utiliser les attributs CLONE_* qui créent de nouveaux espaces
                de nom avec clone(2) et unshare(2) ;
              * appeler perf_event_open(2) ;
              * accéder aux informations d'événements perf nécessitant des
                droits ;
              * appeler setns(2) ;
              * appeler fanotify_init(2) ;
              * effectuer des opérations keyctl(2) KEYCTL_CHOWN et
                KEYCTL_SETPERM ;
              * effectuer une opération madvise(2) MADV_HWPOISON ;
              * utiliser la commande TIOCSTI de ioctl(2) pour insérer des
                caractère dans la file d'entrée d'un terminal autre que le
                terminal de contrôle de l'appelant ;
              * utiliser l'appel système obsolète nfsservctl(2) ;
              * utiliser l'appel système obsolète bdflush(2) ;
              * effectuer diverses opérations ioctl(2) sur des
                périphériques bloc nécessitant des droits ;
              * effectuer diverses opérations ioctl(2) sur des systèmes de
                fichiers nécessitant des droits ;
              * effectuer des opérations d'administration sur de nombreux
                pilotes de périphériques.

       CAP_SYS_BOOT
              Utiliser reboot(2) et kexec_load(2).

       CAP_SYS_CHROOT
              Utiliser chroot(2).

       CAP_SYS_MODULE
              Charger ou décharger des modules noyaux (consultez
              init_module(2) et delete_module(2)) ; dans les noyaux
              antérieurs à 2.6.25 : enlever des capacités de l'ensemble
              système de limitation de capacités.

       CAP_SYS_NICE
              * Augmenter la valeur de courtoisie (« nice ») (nice(2),
                setpriority(2)) et changer la courtoisie de n'importe quel
                processus ;
              * utiliser 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),
                sched_setattr(2)) ;
              * définir l'affinité CPU pour n'importe quel processus
                (sched_setaffinity(2)) ;
              * définir la classe et la priorité d'ordonnancement
                d'entrées/sorties pour n'importe quel processus
                (ioprio_set(2)) ;
              * appliquer migrate_pages(2) Ã  n'importe quel processus et
                migrer un processus vers n'importe quel nÅud ;
              * appliquer move_pages(2) pour n'importe quel processus ;
              * utiliser l'attribut MPOL_MF_MOVE_ALL avec mbind(2) et
                move_pages(2).

       CAP_SYS_PACCT
              Utiliser acct(2).

       CAP_SYS_PTRACE
              *  Suivre n'importe quel processus avec ptrace(2) ;
              *  appliquer get_robust_list(2) Ã  n'importe quel processus ;
              *  transférer les données depuis ou vers la mémoire de
                 n'importe quel processus au moyen de process_vm_readv(2)  et
                 de process_vm_writev(2).
              *  examiner les processus avec kcmp(2).

       CAP_SYS_RAWIO
              * Effectuer des opérations d'entrées-sorties (iopl(2) et
                ioperm(2)) ;
              * accéder à /proc/kcore ;
              * utiliser l'opération FIBMAP de ioctl(2) ;
              * ouvrir les périphériques pour accéder aux registres
                spécifiques au modèle (MSR, consultez msr(4)) d'un
                processeur x86 ;
              * mettre à jour /proc/sys/vm/mmap_min_addr ;
              * créer des projections en mémoire aux adresses inférieures
                à la valeur indiquée par /proc/sys/vm/mmap_min_addr ;
              * projeter les fichiers dans /proc/bus/pci ;
              * ouvrir /dev/mem et /dev/kmem ;
              * effectuer diverses commandes de périphérique SCSI ;
              * effectuer certaines opérations sur les périphériques
                hpsa(4) et cciss(4) ;
              * effectuer certaines opérations spécifiques à d'autres types
                de périphériques.

       CAP_SYS_RESOURCE
              * Utiliser de l'espace réservé sur des systèmes de fichiers
                ext2 ;
              * effectuer des appels ioctl(2) pour contrôler la
                journalisation ext3 ;
              * ne pas tenir compte des limites définies par les quota
                disque ;
              * augmenter les limites de ressources (consultez setrlimit(2)) ;
              * ne pas tenir compte de la limite de ressource RLIMIT_NPROC ;
              * ne pas tenir compte du nombre maximal de consoles sur
                l'allocation de console ;
              * ne pas tenir compte du nombre maximal de dispositions de
                clavier ;
              * permettre des interruptions à plus de 64 Hz depuis l'horloge
                temps réel ;
              * augmenter la limite msg_qbytes pour la file de messages
                System V au dessus de la limite /proc/sys/kernel/msgmnb
                (consultez msgop(2) et msgctl(2)) ;
              * ne pas tenir compte la limite /proc/sys/fs/pipe-size-max lors
                du réglage de la capacité d'un tube avec la commande
                fcntl(2) avec l'argument F_SETPIPE_SZ ;
              * utiliser F_SETPIPE_SZ pour augmenter la capacité d'un tube
                au-dessus de la limite spécifiée par
                /proc/sys/fs/pipe-max-size ;
              * ne pas tenir compte de la limite
                /proc/sys/fs/mqueue/queues_max lors de la création de files
                de messages POSIX (consultez mq_overview(7)) ;
              * utiliser l'opération PR_SET_MM de prctl(2) ;
              * affecter à  /proc/PID/oom_score_adj une valeur inférieure Ã
                la dernière valeur affectée par un processus avec
                CAP_SYS_RESOURCE.

       CAP_SYS_TIME
              Modifier l'heure système (settimeofday(2), stime(2),
              adjtimex(2)) ; modifier l'horloge temps réel (matérielle).

       CAP_SYS_TTY_CONFIG
              Utiliser vhangup(2) ; employer diverses opérations ioctl(2)
              nécessitant des droits sur des terminaux virtuels.

       CAP_SYSLOG (depuis Linux 2.6.37)
              *  Effectuer des opérations syslog(2) nécessitant des droits.
                 Consultez syslog(2) pour savoir quelles opérations
                 nécessitent des droits.
              *  Inspecter les adresses du noyau exposées par /proc et
                 d'autres interfaces lorsque /proc/sys/kernel/kptr_restrict a
                 la valeur 1. (Voir la discussion sur kptr_restrict dans
                 proc(5).)

       CAP_WAKE_ALARM (depuis Linux 3.0)
              Déclencher quelque chose qui réveillera le système (réglage
              des alarmes CLOCK_REALTIME_ALARM et CLOCK_BOOTTIME_ALARM).

   Implémentations passées et actuelles
       Une implémentation complète des capacités nécessite que :

       1. Pour toutes les opérations privilégiées, le noyau doit vérifier
          si le thread a la capacité requise dans son ensemble effectif ;

       2. Le noyau doit fournir des appels système permettant de changer et
          récupérer les ensembles de capacités d'un thread.

       3. 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é.

       Sous Linux 2.6.14, seules les deux premières clauses sont
       remplies.Avant le noyau 2.6.24, seules les deux premières exigences
       sont remplies ; depuis le noyau 2.6.24, ces trois exigences sont
       remplies.

   Ensembles de capacités des threads
       Chaque thread a trois ensembles contenant zéro ou plus des capacités
       ci-dessus :

       Permises :
              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é CAP_SETPCAP dans son ensemble
              effectif.

              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 execve(2) sur un programme Set-UID root ou un
              programme dont les capacités associées au fichier permettent
              cette capacité).

       Héritable :
              Il s'agit d'un ensemble de capacités préservées au travers
              d'un execve(2). Il fournit à un processus un mécanisme pour
              assigner des capacités à l'ensemble des capacités permises du
              nouveau programme lors d'un execve(2).

       Effectif :
              Il s'agit de l'ensemble des capacités utilisées par le noyau
              pour vérifier les permissions du thread.

       Un fils créé par fork(2) hérite d'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
       de capacités (voir ci-dessous).

       Ã partir de Linux 3.2, le fichier /proc/sys/kernel/cap_last_cap
       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.

   Capacités de fichier
       Depuis le noyau 2.6.24, le noyau prend en charge l'association
       d'ensembles de capacités avec un fichier exécutable à l'aide de
       setcap(8). Les ensembles de capacités du fichier sont stockés dans un
       attribut étendu (consultez setxattr(2)) appelé security.capability.
       Ãcrire dans cet attribut étendu nécessite la capacité CAP_SETFCAP.
       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 execve(2).

       Les trois ensembles de capacités de fichier sont :

       Permises (anciennement forcées) :
              Ces capacités sont automatiquement permises au thread, quelles
              que soient ses capacités héritables.

       Héritables (anciennement autorisées) :
              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 permises sont permises pour le thread après l'appel
              Ã  execve(2).

       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 execve(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 execve(2), aucune des nouvelles
              capacités permises ne se trouvera dans le nouvel ensemble
              effectif.

              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é permises correspondantes
              lors d'un execve(2) (consultez les règles de transformation
              décrites ci-dessous) fournira également cette capacité dans
              l'ensemble de capacités effectives du thread. Ainsi, lors de
              l'ajout de capacités à un fichier (setcap(8), cap_set_file(3),
              cap_set_fd(3)), si le bit effectif pour une des capacités est
              activé, alors le bit effectif doit également être activé
              pour toutes les capacités dont le bit permis ou héritable
              correspondant est activé.

   Transformation des capacités lors d'un appel execve()
       Durant un execve(2), le noyau calcule les nouvelles capacités du
       processus en utilisant l'algorithme suivant :

           P'(permises) = (P(héritables) & F(héritables) |
                          (F(permises) & cap_bset)

           P'(effectives) = F(effectives) ? P'(permises) : 0

           P'(héritables) = P(héritables)    [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 (décrit
                     ci-dessous).

   Capacités et exécution de programmes par root
       Pour fournir un root tout puissant en utilisant les ensembles de
       capacités, lors d'un execve(2) :

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

       2. Si un programme Set-UID root est exécuté, alors le bit des
          capacités effectives du fichier est défini à 1 (activé).

       L'effet des règles ci-dessus combinées avec les transformations de
       capacités ci-dessus, 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 permises et effectives, sauf celles
       qui sont interdites par la limitation de capacités. Ceci fournit une
       sémantique identique à celle fournie par les systèmes UNIX
       traditionnels.

   Limitation des capacités
       La 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 execve(2). La
       limitation de capacités est utilisée de cette façon :

       * Lors d'un execve(2), la limitation de capacités (un ensemble de
         capacités) est combinée avec 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. La limitation de capacités permet donc de limiter les
         capacités permises qui peuvent être accordées à un fichier
         exécutable.

       * (Depuis Linux 2.6.25) La 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 capset(2). Ceci
         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 execve(2) un fichier qui a cette
         capacité dans son ensemble de capacités héritables.

       Notez que la 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.

       Suivant la version du noyau, la limitation de capacités est un
       attribut au niveau du système ou un attribut par processus.

       Limitation de capacités avant Linux 2.6.25

       Dans les noyaux antérieurs à 2.6.25, la limitation de capacités est
       un attribut au niveau du système qui affecte tous les threads. La
       limitation de capacités est accessible par le fichier
       /proc/sys/kernel/cap-bound. (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 configurer des capacités dans l'ensemble
       de limitation de capacités ; sinon, le superutilisateur (plus
       précisément : les programmes avec la capacité CAP_SYS_MODULE) peut
       uniquement supprimer des capacités de 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 de capacités système a été ajoutée à  Linux Ã
       partir du noyau 2.2.11.

       Limitation de capacités après Linux 2.6.25

       Depuis Linux 2.6.25, la limitation de capacités est un attribut par
       thread (il n'y a plus désormais de limitation de capacités au niveau
       du système).

       La limitation est héritée du parent du thread au travers d'un fork(2)
       et est préservé au travers d'un execve(2).

       Un thread peut enlever des capacités de son ensemble de limitation de
       capacités en utilisant l'opération PR_CAPBSET_DROP de prctl(2), Ã
       condition qu'il possède la capacité CAP_SETPCAP. Une fois qu'une
       capacité a été supprimée de l'ensemble de limitation, elle ne peut
       être 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
       PR_CAPBSET_READ de prctl(2).

       La suppression de capacités dans l'ensemble de limitation des
       capacités n'est prise en charge que si les capacités de fichiers sont
       compilés dans le noyau. Dans les noyaux antérieurs à Linux 2.6.33,
       les capacités de fichiers étaient une fonctionnalité optionnelle
       configurable via l'option CONFIG_SECURITY_FILE_CAPABILITIES. Depuis
       Linux 2.6.33, l'option de configuration a été supprimée et les
       capacités de fichiers font maintenant toujours partie du noyau. Quand
       les capacités de fichiers sont compilées dans le noyau,  le processus
       init (l'ancêtre de tous les processus) démarre avec ensemble de
       limitation complet. Si les capacités de fichiers ne sont pas
       compilées dans le noyau, init démarre alors avec un ensemble de
       limitation complet, Ã  l'exception de CAP_SETPCAP, parce que cette
       capacité a une autre signification quand il n'y a pas de capacités de
       fichiers.

       Supprimer une capacité de la limitation de capacités ne la supprime
       pas de l'ensemble hérité d'un thread. Cependant il empêche de
       rajouter la capacité dans l'ensemble hérité du thread par la suite.

   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 permises et
          effectives.

       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 des capacités permises est copié dans l'ensemble des
          capacités effectives.

       4. Si le fsuid est modifié de 0 à une valeur non nulle (consultez
          setfsuid(2)), les capacités suivantes sont supprimées de
          l'ensemble effectif : CAP_CHOWN, CAP_DAC_OVERRIDE,
          CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_LINUX_IMMUTABLE
          (depuis Linux 2.6.30), CAP_MAC_OVERRIDE et CAP_MKNOD (depuis
          Linux 2.6.30). Si le fsuid devient nul, 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.

       Si un thread dont l'un des UID vaut 0 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'opération PR_SET_KEEPCAPS
       de l'appel système prctl(2).

   Ajuster les ensembles de capacités par programmation
       Un thread peut obtenir ou modifier ses ensembles de capacités en
       utilisant les appels système capget(2) et capset(2). Cependant, il
       faut leur préférer l'utilisation de cap_get_proc(3) et
       cap_set_proc(3), toutes deux fournies par le paquet libcap. Les règles
       suivantes gouvernent les modifications des ensembles de capacités d'un
       thread :

       1. Si l'appelant n'a pas la capacité CAP_SETPCAP, 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.

       2. (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.

       3. 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).

       4. Le nouvel ensemble effectif doit être un sous-ensemble du nouvel
          ensemble des capacités permises.

   Les attributs « securebits » : configuration d'un environnement restreint
       aux capacités de fichiers.
       à partir du noyau 2.6.26, si les capacités de fichiers sont activées,
       Linux implémente un ensemble d'attributs securebits par thread qui
       peuvent être utilisés pour désactiver la gestion particulière des
       capacités pour l'UID 0 (root). Ces attributs sont les suivants :

       SECBIT_KEEP_CAPS
              Activer cet attribut permet à un thread qui a un UID (ou plus)
              égal à 0 de conserver ses capacités quand il change ses UID
              et que plus aucun n'est nul. Si cet attribut est désactivé,
              alors ces changements d'UID feront perdre au thread toutes ses
              capacités. Cet attribut est toujours désactivé lors d'un
              execve(2). Cet attribut fournit la même fonctionnalité que
              l'ancienne opération PR_SET_KEEPCAPS de prctl(2)).

       SECBIT_NO_SETUID_FIXUP
              Activer cet attribut stoppe l'ajustement des ensembles de
              capacités par le noyau lorsque les UID effectifs et d'accès
              aux fichiers du thread passent d'une valeur nulle à une valeur
              non nulle. (Consultez la sous-section Effet des modifications
              d'UID sur les capacités.)

       SECBIT_NOROOT
              Si cet attribut est activé, alors le noyau n'autorise pas les
              capacités lorsqu'un programme Set-UID root est exécuté ou
              lorsqu'un processus dont l'identifiant effectif ou réel est nul
              appelle execve(2). (Consultez la sous-section Capacités et
              exécution de programmes par root.)

       Chacun des attributs de base ci-dessus a un attribut compagnon de
       verrouillage. L'activation d'un attribut de verrouillage est
       irréversible et permet d'éviter toute modification ultérieure de
       l'attribut de base. Les attributs de verrouillage sont :
       SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED et
       SECBIT_NOROOT_LOCKED.

       Les attributs securebits peuvent être modifiés et récupérés en
       utilisant les opérations PR_SET_SECUREBITS et PR_GET_SECUREBITS de
       prctl(2). La capacité CAP_SETPCAP est nécessaire pour modifier ces
       attributs.

       Les attributs securebits sont hérités par les processus fils. Lors
       d'un execve(2), tous les attributs sont conservés, à l'exception de
       SECBIT_KEEP_CAPS qui est toujours désactivé.

       Une application peut utiliser l'appel suivant pour se verrouiller
       elle-même, ainsi que tous ses descendant, 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 correspondantes :

           prctl(PR_SET_SECUREBITS,
                   SECBIT_KEEP_CAPS_LOCKED |
                   SECBIT_NO_SETUID_FIXUP |
                   SECBIT_NO_SETUID_FIXUP_LOCKED |
                   SECBIT_NOROOT |
                   SECBIT_NOROOT_LOCKED);

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 ; consultez ⟨http://wt.tuxomania.net/publications
       /posix.1e/⟩.

NOTES
       Depuis le noyau 2.5.27, les capacités sont optionnelles dans le noyau
       et peuvent être activées ou désactivées avec l'option de
       configuration CONFIG_SECURITY_CAPABILITIES du noyau.

       Le fichier /proc/PID/task/TID/status peut être utilisé pour voir les
       ensembles de capacités d'un thread. Le fichier /proc/PID/status
       indique les ensembles de capacités du thread principal d'un thread.
       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 (au-délà de CAP_LAST_CAP) sont vues comme
       désactivées (0).

       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). Ce paquet fournit également les programmes setcap(8) et
       getcap(8). Il peut être trouvé à l'adresse :
       ⟨http://www.kernel.org/pub/linux/libs/security/linux-privs⟩.

       Avant le noyau 2.6.24, et depuis le noyau 2.6.24 si les capacités de
       fichier ne sont pas activées, un thread avec la capacité CAP_SETPCAP
       peut manipuler les capacités des autres threads. Cependant, ce n'est
       possible qu'en théorie puisqu'aucun thread n'a la capacité
       CAP_SETPCAP dans un des cas suivants :

       * Dans l'implémentation antérieure au noyau 2.6.25, l'ensemble de
         limitation de capacités du système, /proc/sys/kernel/cap-bound,
         masque toujours cette capacité et ceci ne peut pas être changé
         sans modifier les sources du noyau et le recompiler.

       * Si les capacités de fichiers sont désactivées dans
         l'implémentation actuelle, alors init démarre sans cette capacité
         dans l'ensemble de limitation de capacité de son processus, et cet
         ensemble de limitation de capacité est hérité par tous les
         processus créés sur le système.

VOIR AUSSI
       capsh(1), capget(2), prctl(2), setfsuid(2), cap_clear(3),
       cap_copy_ext(3), cap_from_text(3), cap_get_file(3), cap_get_proc(3),
       cap_init(3), capgetp(3), capsetp(3), libcap(3), credentials(7),
       pthreads(7), getcap(8), setcap(8)

       include/linux/capability.h dans les sources du noyau Linux

COLOPHON
       Cette page fait partie de la publication 3.70 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
       Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
       <http://po4a.alioth.debian.org/> par l'équipe de traduction
       francophone au sein du projet perkamon
       <http://perkamon.alioth.debian.org/>.

       Christophe Blaess <http://www.blaess.fr/christophe/> (1996-2003), Alain
       Portal <http://manpagesfr.free.fr/> (2003-2006).  Julien Cristau et
       l'équipe francophone de traduction de Debian (2006-2009).

       Veuillez signaler toute erreur de traduction en écrivant Ã
       <perkamon-fr@traduc.org>.

       Vous pouvez toujours avoir accès à la version anglaise de ce document
       en utilisant la commande « LC_ALL=C man <section> <page_de_man> ».



Linux                             21 mai 2014                  CAPABILITIES(7)