Provided by: manpages-fr_3.32d0.2p4-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.

   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_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.

       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  différentes  opérations  réseau  (par  exemple   obtenir   des   options
              privilégiées  sur  les  sockets,  activer  le multicast, configurer les interfaces,
              modifier les tables de routage).

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

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

       CAP_NET_RAW
              Utiliser des sockets RAW et PACKET.

       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  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 l'attribut CLONE_NEWNS avec clone(2) et unshare(2) ;
              * effectuer des opérations keyctl(2) KEYCTL_CHOWN et KEYCTL_SETPERM ;
              * effectuer une opération madvise(2) MADV_HWPOISON.

       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)) ;
              * fixer  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.

       CAP_SYS_RAWIO
              Effectuer des opérations  d'entrées-sorties  (iopl(2)  et  ioperm(2)) ;  accéder  à
              /proc/kcore.

       CAP_SYS_RESOURCE
              * Utiliser de l'espace réservé sur des systèmes de fichiers ext2 ;
              * effectuer des appels ioctl(2) pour controller 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 ;
              * augmenter la limite msg_qbytes pour la queue de messages System V au dessus de la
                limite /proc/sys/kernel/msgmnb (consultez msgop(2) et msgctl(2)).
              * 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.

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

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

   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
       (CONFIG_SECURITY_FILE_CAPABILITIES).  Dans ce cas, le processus init démarre avec ensemble
       plein à l'exception de CAP_SETPCAP, parce que cette capacité  a  une  autre  signification
       quand il n'y a pas de capacités de fichier.

       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.2.30), CAP_MAC_OVERRIDE et CAP_MKNOD (depuis Linux 2.2.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 fixe tous ses UID à des valeurs non nulles,  il  peut  le  faire  avec
       l'opération PR_SET_KEEPCAPS de l'appel système prctl(2).

   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 le noyau 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 SECURE_KEEP_CAPS qui est 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.xpilot.org/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.

       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),  credentials(7),
       pthreads(7), getcap(8), setcap(8)

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

COLOPHON

       Cette  page  fait partie de la publication 3.32 du projet man-pages Linux. Une description
       du projet et des  instructions  pour  signaler  des  anomalies  peuvent  être  trouvées  à
       l'adresse <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis    2010,    cette   traduction   est   maintenue   à   l'aide   de   l'outil   po4a
       <URL:http://po4a.alioth.debian.org/> par l'équipe de traduction  francophone  au  sein  du
       projet perkamon <URL:http://perkamon.alioth.debian.org/>.

       Christophe   Blaess   <URL:http://www.blaess.fr/christophe/>   (1996-2003),  Alain  Portal
       <URL: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> ».