Provided by: manpages-fr_3.32d0.2p4-1_all bug

NOM

       capabilities - Presentation des capacites Linux

DESCRIPTION

       Pour verifier les permissions, les implementations UNIX traditionnelles
       distinguent deux categories de processus :  les  processus  privil'egi'es
       (dont  l'UID  effectif  est 0, appele superutilisateur ou root), et les
       processus non  privil'egi'es  (dont  l'UID  effectif  est  non-nul).  Les
       processus  privilegies  contournent les verifications de permissions du
       noyau, alors que  les  processus  non-privilegies  sont  soumis  a  une
       verification   complete   basee   sur   l'identification  du  processus
       (habituellement : UID effectif, GID effectif, et liste des groupes).

       A partir du noyau 2.2, Linux propose un mecanisme (encore incomplet) de
       capacit'es,  qui  scinde  les  privileges traditionnellement associes au
       superutilisateur en unites distinctes que l'on peut activer ou  inhiber
       individuellement.

   Liste des capacit'es
       La  liste suivante indique les capacites implementees sous Linux et les
       operations ou comportements que chaque capacite permet :

       CAP_AUDIT_CONTROL (depuis Linux 2.6.11)
              Activer et desactiver l'audit du noyau ; changer les  regles  de
              filtrage d'audit ; acceder a l'etat de l'audit, et aux regles de
              filtrage.

       CAP_AUDIT_WRITE (depuis Linux 2.6.11)
              Ecrire 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, ecriture et execution.
              (DAC est l'abreviation de  << discretionary  access  control >>,
              controle d'acces a volonte).

       CAP_DAC_READ_SEARCH
              Contourne  les  permissions  de lecture de fichiers et celles de
              lecture et execution des repertoires.

       CAP_FOWNER
              * Contourne les verifications pour les operations qui  demandent
                que le FS-UID du processus corresponde a l'UID du fichier (par
                exemple chmod(2),  utime(2)),  a  l'exclusion  des  operations
                couvertes par CAP_DAC_OVERRIDE et CAP_DAC_READ_SEARCH ;
              * positionner   les  attributs  de  fichier  etendus  (consultez
                chattr(1)) pour n'importe quel fichier ;
              * positionner les listes  de  controle  d'acces  ACL  (<< Access
                Control Lists >>) pour n'importe quel fichier ;
              * ignorer le bit sticky des repertoires pour les suppressions de
                fichier ;
              * specifier 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 modifie ;  positionner  le  bit  Set-GID  sur  un
              fichier  dont  le  GID  ne  correspond  a aucun GID du processus
              appelant.

       CAP_IPC_LOCK
              Verrouiller des pages memoire (mlock(2),  mlockall(2),  mmap(2),
              shmctl(2)).

       CAP_IPC_OWNER
              Contourne  les  verifications  pour  les  operations sur les IPC
              System V.

       CAP_KILL
              Contourne  les  verifications   pour   l'emission   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'inoeuds   FS_APPEND_FL   et
              FS_IMMUTABLE_FL (consultez chattr(1)).

       CAP_MAC_ADMIN (depuis Linux 2.6.25)
              Surcharger  les  controles  d'acces  MAC  (<< Mandatory   Access
              Control >>).  Implementee  pour  le  module  de  securite (LSM :
              << Linux Security Module >>) Smack.

       CAP_MAC_OVERRIDE (depuis Linux 2.6.25)
              Permettre les modifications de la  configuration  ou  des  etats
              MAC. Implementee pour le LSM Smack.

       CAP_MKNOD (depuis Linux 2.4)
              Creer des fichiers speciaux avec mknod(2).

       CAP_NET_ADMIN
              Effectuer differentes operations reseau (par exemple obtenir des
              options privilegiees sur  les  sockets,  activer  le  multicast,
              configurer les interfaces, modifier les tables de routage).

       CAP_NET_BIND_SERVICE
              Attacher  une  socket  sur  un  port  privilegie (numero de port
              inferieur a 1024).

       CAP_NET_BROADCAST
              (Inutilise)  Broadcastet  et  ecouter  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 supplementaires, utiliser de faux GID sur les  socket
              UNIX.

       CAP_SETFCAP (depuis Linux 2.6.24)
              Definir des capacites de fichier

       CAP_SETPCAP
              Si les capacites de fichier sont prises en charge : autoriser ou
              interdire toute capacite dans l'ensemble des capacites  permises
              a  l'appelant  vers  ou  depuis  tout  autre  processus.  (Cette
              propriete de CAP_SETPCAP n'est pas disponible quand le noyau est
              configure  pour  prendre  en  charge  les  capacite de fichiers,
              puisque CAP_SETPCAP  a  une  toute  autre  semantique  pour  ces
              noyaux)

              Si  les  capacites  de  fichier  sont prises en charge : ajouter
              toute capacite de  l'ensemble  de  limitation  de  capacites  du
              thread  appelant a son ensemble herite ; supprimer les capacites
              de  l'ensemble  de  limitation  de  capacites   (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   operations   d'administration  comme :
                quotactl(2),  mount(2),  umount(2),   swapon(2),   swapoff(2),
                sethostname(2) et setdomainname(2) ;
              * effectuer  des  operations  IPC_SET  et IPC_RMID sur n'importe
                quel objet IPC System V ;
              * effectuer des operations sur les attributs etendus 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
                references de sockets ;
              * depasser /proc/sys/fs/file-max, la limite systeme du nombre de
                fichiers  ouverts,  dans  les  appels  systeme qui ouvrent des
                fichiers  (c'est-a-dire  accept(2),  execve(2),   open(2)   et
                pipe(2)) ;
              * utiliser l'attribut CLONE_NEWNS avec clone(2) et unshare(2) ;
              * effectuer    des    operations   keyctl(2)   KEYCTL_CHOWN   et
                KEYCTL_SETPERM ;
              * effectuer une operation 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   decharger   des   modules    noyaux    (consultez
              init_module(2) et delete_module(2)) ; dans les noyaux anterieurs
              a 2.6.25 :  enlever  des  capacites  de  l'ensemble  systeme  de
              limitation de capacites.

       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-reel  pour  le processus
                appelant, et la modification de l'ordonnancement de  n'importe
                quel processus (sched_setscheduler(2), sched_setparam(2)) ;
              * definir   l'affinite   CPU   pour   n'importe  quel  processus
                (sched_setaffinity(2)) ;
              * fixer   la   classe   et    la    priorite    d'ordonnancement
                d'entrees/sorties     pour     n'importe     quel    processus
                (ioprio_set(2)) ;
              * appliquer  migrate_pages(2)  a  n'importe  quel  processus  et
                migrer un processus vers n'importe quel noeud ;
              * 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)  a n'importe quel processus.

       CAP_SYS_RAWIO
              Effectuer   des   operations   d'entrees-sorties   (iopl(2)   et
              ioperm(2)) ; acceder a /proc/kcore.

       CAP_SYS_RESOURCE
              * Utiliser de l'espace reserve  sur  des  systemes  de  fichiers
                ext2 ;
              * effectuer    des    appels   ioctl(2)   pour   controller   la
                journalisation ext3 ;
              * ne pas  tenir  compte  des  limites  definies  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 capacite d'un tube
                au-dessus      de      la      limite      specifiee       par
                /proc/sys/fs/pipe-max-size.

       CAP_SYS_TIME
              Modifier    l'heure    systeme    (settimeofday(2),    stime(2),
              adjtimex(2)) ; modifier l'horloge temps-reel (materielle).

       CAP_SYS_TTY_CONFIG
              Utiliser vhangup(2).

   Impl'ementations pass'ees et actuelles
       Une implementation complete des capacites necessite que :

       1. Pour toutes les operations privilegiees, le noyau doit  verifier  si
          le thread a la capacite requise dans son ensemble effectif ;

       2. Le  noyau  doit  fournir des appels systeme permettant de changer et
          recuperer les ensembles de capacites d'un thread.

       3. Le systeme de fichiers doit permettre d'attacher des  capacites  aux
          fichiers  executables,  pour  qu'un  processus  en  dispose quand le
          fichier est execute.

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

   Ensembles de capacit'es des threads
       Chaque  thread  a  trois ensembles contenant zero ou plus des capacites
       ci-dessus :

       Permises :
              Il s'agit d'un sur-ensemble limitant  les  capacites  effectives
              que  le  thread  peut prendre. Il limite egalement les capacites
              qui peuvent etre ajoutees a l'ensemble heritable par  un  thread
              qui n'a pas la capacite CAP_SETPCAP dans son ensemble effectif.

              Si  un  processus  supprime  une  capacite  de  son  ensemble de
              capacites permises, il ne peut plus jamais  la  recuperer  (sauf
              s'il  appelle  execve(2)  sur  un  programme  Set-UID root ou un
              programme dont les capacites  associees  au  fichier  permettent
              cette capacite).

       H'eritable :
              Il  s'agit d'un ensemble de capacites preservees au travers d'un
              execve(2). Il fournit a un processus un mecanisme pour  assigner
              des  capacites  a  l'ensemble  des capacites permises du nouveau
              programme lors d'un execve(2).

       Effectif :
              Il s'agit de l'ensemble des capacites  utilisees  par  le  noyau
              pour verifier les permissions du thread.

       Un  fils  cree par fork(2) herite d'une copie des ensembles de capacite
       de son pere. Le traitement des capacites lors d'un execve(2) est decrit
       plus bas.

       En  utilisant capset(2), un thread peut manipuler ses propres ensembles
       de capacites (voir ci-dessous).

   Capacit'es de fichier
       Depuis  le  noyau 2.6.24,  le  noyau  prend  en  charge   l'association
       d'ensembles  de  capacites  avec  un  fichier  executable  a  l'aide de
       setcap(8). Les ensembles de capacites du fichier sont stockes  dans  un
       attribut  etendu  (consultez  setxattr(2))  appele security.capability.
       Ecrire dans cet attribut etendu necessite la capacite CAP_SETFCAP.  Les
       ensembles  de  capacites  d'un  fichier, combines avec les ensembles de
       capacites du thread determinent les  capacites  d'un  thread  apres  un
       execve(2).

       Les trois ensembles de capacites de fichier sont :

       Permises (anciennement forc'ees) :
              Ces  capacites  sont automatiquement permises au thread, quelles
              que soient ses capacites heritables.

       H'eritables (anciennement autoris'ees) :
              Cet ensemble est combine par un ET avec l'ensemble heritable  du
              thread pour savoir quelles capacites de l'ensemble des capacites
              permises sont permises pour le thread apres l'appel a execve(2).

       Effectif :
              Il ne s'agit pas d'un ensemble, mais plutot d'un unique bit.  Si
              le  bit  est  positionne, alors, lors d'un execve(2), toutes les
              nouvelles capacites  permises  pour  le  thread  sont  egalement
              positionnees  dans  l'ensemble  effectif.  Si  ce  bit n'est pas
              positionne, alors, apres  un  execve(2),  aucune  des  nouvelles
              capacites  permises  ne  se  trouvera  dans  le  nouvel ensemble
              effectif.

              Activer le bit des capacites effectives  d'un  fichier  implique
              que  toute capacite de fichier permise ou heritable qui permet a
              un thread d'obtenir les capacite permises  correspondantes  lors
              d'un  execve(2) (consultez les regles de transformation decrites
              ci-dessous) fournira egalement cette capacite dans l'ensemble de
              capacites  effectives  du  thread.  Ainsi,  lors  de  l'ajout de
              capacites   a   un    fichier    (setcap(8),    cap_set_file(3),
              cap_set_fd(3)),  si  le  bit effectif pour une des capacites est
              active, alors le bit effectif doit egalement  etre  active  pour
              toutes   les   capacites   dont   le  bit  permis  ou  heritable
              corresppondant est active.

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

           P'(permises) = (P(heritables) & F(heritables) |
                          (F(permises) & cap_bset)

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

           P'(heritables) = P(heritables)    [inchange]

       ou :

           P         indique  la  valeur  d'un ensemble de capacites du thread
                     avant le execve(2)

           P'        indique la valeur d'un ensemble  de  capacites  apres  le
                     execve(2)

           F         indique la valeur d'un ensemble de capacites du fichier

           cap_bset  est  la  valeur  de  la  limitation  de capacites (decrit
                     ci-dessous).

   Capacit'es et ex'ecution de programmes par root
       Pour fournir un root  tout  puissant  en  utilisant  les  ensembles  de
       capacites, lors d'un execve(2) :

       1. Si  on  execute un programme Set-UID root, ou si l'UID reel est nul,
          alors les ensembles des capacites heritables et permises du  fichier
          sont remplis de uns (toutes les capacites activees).

       2. Si un programme Set-UID root est execute, alors le bit des capacites
          effectives du fichier est defini a 1 (active).

       L'effet des regles ci-dessus  combinees  avec  les  transformations  de
       capacites ci-dessus, est que lorsqu'un processus lance (avec execve(2))
       un programme Set-UID root, ou lorsqu'un processus  d'UID  effectif  nul
       execute  un  programme,  il  obtient  toutes  les  capacites  dans  ses
       ensembles de capacites permises et effectives,  sauf  celles  qui  sont
       interdites  par la limitation de capacites. Ceci fournit une semantique
       identique a celle fournie par les systemes UNIX traditionnels.

   Limitation des capacit'es
       La limitation des capacites  (<< capability  bounding  set >>)  est  un
       mecanisme  de securite qui peut etre utilise pour limiter les capacites
       qui peuvent  etre  obtenues  lors  d'un  execve(2).  La  limitation  de
       capacites est utilisee de cette facon :

       * Lors  d'un  execve(2),  la  limitation  de  capacites (un ensemble de
         capacites) est combinee  avec  un  ET  binaire  avec  l'ensemble  des
         capacites  autorisees  du  fichier, et le resultat de cette operation
         est place dans l'ensemble des  capacites  autorisees  du  thread.  La
         limitation de capacites permet donc de limiter les capacites permises
         qui peuvent etre accordees a un fichier executable.

       * (Depuis Linux 2.6.25)  La  limitation  de  capacites  agit  comme  un
         sur-ensemble  limitant  les capacites qu'un thread peut ajouter a son
         ensemble  de  capacites  heritables  en  utilisant  capset(2).   Ceci
         signifie  que  si  une  capacite  ne se trouve pas dans l'ensemble de
         limitation des capacites, alors  un  thread  ne  peut  ajouter  cette
         capacite  dans  son ensemble de capacites heritables, meme si elle se
         trouvait dans son ensemble de capacites permises, et ne peut donc pas
         conserver  cette  capacite  dans  son  ensemble de capacites permises
         lorsqu'il execute avec execve(2) un fichier qui a cette capacite dans
         son ensemble de capacites heritables.

       Notez  que  la limitation de capacites masque les capacites permises du
       fichier, mais pas les capacites heritees. Si  un  thread  conserve  une
       capacite  dans son ensemble de capacites heritees et que cette capacite
       ne se trouve pas dans l'ensemble de limitation des capacites, alors  il
       peut  toujours  obtenir  cette  capacite dans son ensemble de capacites
       permises en executant un fichier qui a la capacite dans son ensemble de
       capacites heritees.

       Suivant la version du noyau, la limitation de capacites est un attribut
       au niveau du systeme ou un attribut par processus.

       Limitation de capacit'es avant Linux 2.6.25

       Dans les noyaux anterieurs a 2.6.25, la limitation de capacites est  un
       attribut  au  niveau  du  systeme  qui  affecte  tous  les  threads. La
       limitation   de   capacites   est    accessible    par    le    fichier
       /proc/sys/kernel/cap-bound.  (Le  masque  de  bits est exprime comme un
       nombre decimal signe dans /proc/sys/kernel/cap-bound, ce qui entretient
       les confusions).

       Seul le processus init peut configurer des capacites dans l'ensemble de
       limitation   de   capacites ;   sinon,   le   superutilisateur    (plus
       precisement :  les  programmes  avec  la  capacite CAP_SYS_MODULE) peut
       uniquement supprimer des capacites de cet ensemble.

       Sur un systeme standard, la limitation  elimine  toujours  la  capacite
       CAP_SETPCAP.   Pour   supprimer  cette  restriction  (attention,  c'est
       dangereux !),  modifiez  la   definition   de   CAP_INIT_EFF_SET   dans
       include/linux/capability.h et recompilez le noyau.

       La  limitation  de  capacites systeme a ete ajoutee a Linux a partir du
       noyau 2.2.11.

       Limitation de capacit'es apr`es Linux 2.6.25

       Depuis Linux 2.6.25, la limitation de capacit'es  est  un  attribut  par
       thread (il n'y a plus desormais de limitation de capacites au niveau du
       systeme).

       La limitation est heritee du parent du thread au travers  d'un  fork(2)
       et est preserve au travers d'un execve(2).

       Un  thread  peut enlever des capacites de son ensemble de limitation de
       capacites en  utilisant  l'operation  PR_CAPBSET_DROP  de  prctl(2),  a
       condition  qu'il  possede  la  capacite  CAP_SETPCAP.  Une  fois qu'une
       capacite a ete supprimee de l'ensemble de limitation, elle ne peut etre
       y  etre  remise. Un thread peut determiner si une capacite est dans son
       ensemble  de  limitation  de   capacites   en   utilisant   l'operation
       PR_CAPBSET_READ de prctl(2).

       La suppression de capacites dans l'ensemble de limitation des capacites
       n'est prise en charge que si les capacites de  fichiers  sont  compiles
       dans  le  noyau  (CONFIG_SECURITY_FILE_CAPABILITIES).  Dans  ce cas, le
       processus  init  demarre  avec  ensemble   plein   a   l'exception   de
       CAP_SETPCAP,  parce  que cette capacite a une autre signification quand
       il n'y a pas de capacites de fichier.

       Supprimer une capacite de la limitation de capacites ne la supprime pas
       de  l'ensemble  herite d'un thread. Cependant il empeche de rajouter la
       capacite dans l'ensemble herite du thread par la suite.

   Effet des modifications d'UID sur les capacit'es
       Afin de preserver la semantique  traditionnelle  pour  les  transitions
       entre  des  UID  nul  et  non  nul,  le  noyau modifie les ensembles de
       capacites d'un thread de la facon suivante lors  de  modifications  des
       UID  reel,  effectif,  sauve et du systeme de fichiers (avec setuid(2),
       setresuid(2) et compagnie) :

       1. Si l'UID reel, effectif ou sauve etait egal a 0, et qu'a la suite de
          la  modification  ils  sont tous non nuls, toutes les capacites sont
          supprimes des ensembles de capacites permises et effectives.

       2. Si l'UID effectif etait nul et devient non nul, toutes les capacites
          sont supprimees de l'ensemble effectif.

       3. Si l'UID effectif est modifie d'une valeur non nulle a 0, l'ensemble
          des capacites permises  est  copie  dans  l'ensemble  des  capacites
          effectives.

       4. Si  le  fsuid  est  modifie  de  0 a une valeur non nulle (consultez
          setfsuid(2)), les capacites suivantes sont supprimees 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 capacites est  activee  dans  l'ensemble
          des  capacites  effectives  si elle faisait partie de l'ensemble des
          capacites permises.

       Si un thread dont l'un des UID vaut 0 ne veut pas que son  ensemble  de
       capacites  permises soit vide lorsqu'il fixe tous ses UID a des valeurs
       non nulles, il  peut  le  faire  avec  l'operation  PR_SET_KEEPCAPS  de
       l'appel systeme prctl(2).

   Ajuster les ensembles de capacit'es par programmation
       Un  thread  peut  obtenir  ou  modifier  ses  ensembles de capacites en
       utilisant les appels systeme capget(2) et capset(2). Cependant, il faut
       leur  preferer  l'utilisation  de  cap_get_proc(3)  et cap_set_proc(3),
       toutes deux  fournies  par  le  paquet  libcap.  Les  regles  suivantes
       gouvernent les modifications des ensembles de capacites d'un thread :

       1. Si  l'appelant  n'a  pas la capacite CAP_SETPCAP, le nouvel ensemble
          des capacites heritables doit etre un sous-ensemble de  l'union  des
          ensembles de capacites heritables et des capacites permises.

       2. (Depuis  le  noyau 2.6.25) Le nouvel ensemble heritable doit etre un
          sous-ensemble de l'ensemble heritable existant et de  l'ensemble  de
          limitation de capacites.

       3. Le nouvel ensemble des capacites permises doit etre un sous-ensemble
          de l'ensemble des capacites permises  existant  (c'est-a-dire  qu'il
          n'est  pas  possible  d'obtenir des capacites permises que le thread
          n'a pas actuellement).

       4. Le nouvel ensemble effectif doit etre  un  sous-ensemble  du  nouvel
          ensemble des capacites permises.

   Les attributs << securebits >> : configuration d'un environnement restreint
       aux capacit'es de fichiers.
       A partir du noyau 2.6.26, si les capacites de fichiers  sont  activees,
       Linux  implemente  un  ensemble  d'attributs  securebits par thread qui
       peuvent etre utilises  pour  desactiver  la  gestion  particuliere  des
       capacites pour l'UID 0 (root). Ces attributs sont les suivants :

       SECBIT_KEEP_CAPS
              Activer  cet  attribut permet a un thread qui a un UID (ou plus)
              egal a 0 de conserver ses capacites quand il change ses  UID  et
              que  plus  aucun n'est nul. Si cet attribut est desactive, alors
              ces  changements  d'UID  feront  perdre  au  thread  toutes  ses
              capacites.   Cet  attribut  est  toujours  desactive  lors  d'un
              execve(2). Cet  attribut  fournit  la  meme  fonctionnalite  que
              l'ancienne operation PR_SET_KEEPCAPS de prctl(2)).

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

       SECBIT_NOROOT
              Si  cet  attribut  est active, alors le noyau n'autorise pas les
              capacites  lorsqu'un  programme  Set-UID  root  est  execute  ou
              lorsqu'un  processus dont l'identifiant effectif ou reel est nul
              appelle  execve(2).  (Consultez  la  sous-section  Capacit'es  et
              ex'ecution 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
       irreversible  et  permet  d'eviter  toute  modification  ulterieure  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  etre  modifies  et  recuperes   en
       utilisant  les  operations  PR_SET_SECUREBITS  et  PR_GET_SECUREBITS de
       prctl(2). La capacite CAP_SETPCAP  est  necessaire  pour  modifier  ces
       attributs.

       Les attributs securebits sont herites par les processus fils. Lors d'un
       execve(2),  tous  les  attributs  sont  conserves,  a  l'exception   de
       SECURE_KEEP_CAPS qui est desactive.

       Une  application  peut  utiliser  l'appel  suivant  pour se verrouiller
       elle-meme, ainsi que tous ses descendant, dans un environnement  ou  la
       seule  facon  d'obtenir  des capacites est d'executer un programme avec
       les capacites 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'E

       Il  n'y  a  pas  de  veritable   norme   pour   les   capacites,   mais
       l'implementation  Linux  est  base  sur  une interpretation de la norme
       (retiree)                     POSIX.1e ;                      consultez
       http://wt.xpilot.org/publications/posix.1e/.

NOTES

       Depuis  le  noyau 2.5.27, les capacites sont optionnelles dans le noyau
       et peuvent etre activees ou desactivees avec l'option de  configuration
       CONFIG_SECURITY_CAPABILITIES du noyau.

       Le  fichier  /proc/PID/task/TID/status  peut etre utilise pour voir les
       ensembles de capacites d'un thread. Le fichier /proc/PID/status indique
       les ensembles de capacites du thread principal d'un thread.

       Le  paquet  libcap  fournit un ensemble de routines pour ecrire et lire
       les  capacites  d'un  processus,  de  maniere  plus  simple  et   moins
       susceptible  de  changer  que  l'interface  fournie  par  capset(2)  et
       capget(2). Ce paquet fournit  egalement  les  programmes  setcap(8)  et
       getcap(8). Il peut etre trouve a 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 capacites de
       fichier ne sont pas activees, un thread avec  la  capacite  CAP_SETPCAP
       peut  manipuler  les  capacites des autres threads. Cependant, ce n'est
       possible qu'en theorie puisqu'aucun thread n'a la capacite  CAP_SETPCAP
       dans un des cas suivants :

       * Dans  l'implementation  anterieure  au  noyau 2.6.25,  l'ensemble  de
         limitation  de  capacites  du  systeme,   /proc/sys/kernel/cap-bound,
         masque  toujours  cette capacite et ceci ne peut pas etre change sans
         modifier les sources du noyau et le recompiler.

       * Si les capacites de fichiers sont desactivees  dans  l'implementation
         actuelle,  alors  init demarre sans cette capacite dans l'ensemble de
         limitation  de  capacite  de  son  processus,  et  cet  ensemble   de
         limitation de capacite est herite par tous les processus crees sur le
         systeme.

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       etre       trouvees      a      l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis 2010, cette traduction est maintenue a l'aide  de  l'outil  po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'equipe   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'equipe francophone de traduction de Debian (2006-2009).

       Veuillez   signaler   toute   erreur   de   traduction  en  ecrivant  a
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
       paquet manpages-fr.

       Vous  pouvez  toujours avoir acces a la version anglaise de ce document
       en utilisant la commande << man -L C <section> <page_de_man> >>.