Provided by: manpages-fr_3.23.1-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  privilgis
       (dont  l’UID  effectif  est 0, appelé superutilisateur ou root), et les
       processus non  privilgis  (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
       capacits,  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  (voir
              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 (voir chattr(1))
                pour n’importe quel fichier ;
              * positionner les listes de contrôle d’accès ACL  (Ndt :  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  (voir
              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 (voir fcntl(2)).

       CAP_LINUX_IMMUTABLE
              Positionner    les    attributs    d’inoeuds   FS_APPEND_FL   et
              FS_IMMUTABLE_FL (voir 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é 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ésde 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ération   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 (voir 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  identifiant  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èmes  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.

       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 noyau (voir 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)

       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 (voir 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  (voir
                msgop(2) et msgctl(2)).

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

       Hritable :
              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 (voir 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 forces) :
              Ces capacités sont automatiquement permises au  thread,  quelles
              que soient ses capacités héritables.

       Hritables (anciennement autorises) :
              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)  (voir  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 dun 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é 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 capacits  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 dUID 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 (voir
          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 dun environnement restreint
       aux capacités de fichiers.
       A 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 :

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

       SECURE_NO_SETUID_FIXUP
              Activer   cet  attribut  stoppe  l’ajustement  des  ensemble  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  dUID
              sur les capacits.)

       SECURE_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  Capacits  et
              excution 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 :
       SECURE_KEEP_CAPS_LOCKED,        SECURE_NO_SETUID_FIXUP_LOCKED        et
       SECURE_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,
                   1 << SECURE_KEEP_CAPS_LOCKED |
                   1 << SECURE_NO_SETUID_FIXUP |
                   1 << SECURE_NO_SETUID_FIXUP_LOCKED |
                   1 << SECURE_NOROOT |
                   1 << SECURE_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 ; voir  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.23 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

       Cette page de manuel a été traduite  et  mise  à  jour  par  Christophe
       Blaess  <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
       Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et  mise  à
       disposition sur http://manpagesfr.free.fr/.

       Les mises à jour et corrections de la version présente dans Debian sont
       directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
       francophone de traduction de Debian.

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