Provided by: manpages-fr_3.57d1p1-1_all bug

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 ;
              * 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)) ;
              * 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 ; 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  sur-ensemble 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 corresppondant 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 sur-ensemble 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 processues) 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 limitatition  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

       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.57 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     à
       <debian-l10n-french@lists.debian.org>  ou  par  un  rapport  de  bogue   sur   le   paquet
       manpages-fr.

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