Provided by: manpages-fr_2.80.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
       Sous Linux 2.6.14, les capacités suivantes sont implémentées :

       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)
              Permettre  l’écriture  d’enregistrements dans le journal d’audit
              du noyau.

       CAP_CHOWN
              Permet de modifier arbitrairement les UID et  GID  des  fichiers
              (voir chown(2)).

       CAP_DAC_OVERRIDE
              Contourne  les  permissions  de  lecture, écriture et exécution.
              (DAC  =  "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  les  CAP_DAC_OVERRIDE  et  CAP_DAC_READ_SEARCH ;
              positionner les attributs de fichier  étendus  (voir  chattr(1))
              sur   les  fichiers  arbitraires ;  positionner  les  listes  de
              contrôle d’accès  ACL  (Ndt :  Access  Control  Lists)  sur  les
              fichiers  arbitraires ;  ignorer le bit sticky pour supprimer un
              fichier ; spécifier O_NOATIME dans open(2) et fcntl(2) pour  des
              fichiers arbitraires.

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

       CAP_IPC_LOCK
              Permet le verrouillage de 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
              Système V.

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

       CAP_LEASE
              (Depuis  Linux  2.4)  Autorise  la demande de bail sur n’importe
              quel fichier (voir fcntl(2)).

       CAP_LINUX_IMMUTABLE
              Autorise le positionnement des attributs étendus  EXT2_APPEND_FL
              et EXT2_IMMUTABLE_FL (voir chattr(1)).

       CAP_MKNOD
              (Depuis  Linux  2.4)  Autorise  la création de fichiers spéciaux
              avec mknod(2).

       CAP_NET_ADMIN
              Permet certaines opérations réseau (p.ex.  obtenir  des  options
              privilégiées  sur  les sockets, activer le multicast, configurer
              les interfaces, modifier les tables de routage).

       CAP_NET_BIND_SERVICE
              Autorise l’attachement d’une socket sur un port réservé  (numéro
              de port inférieur à 1024).

       CAP_NET_BROADCAST
              (Inutilisé)  Permet  le  broadcast et l’écoute multicast sur les
              sockets.

       CAP_NET_RAW
              Autorise l’utilisation des sockets RAW et PACKET.

       CAP_SETGID
              Accès toute les manipulations des GID  du  processus  et  de  la
              liste  de  groupes supplémentaires, permet l’utilisation de faux
              GID sur les socket Unix.

       CAP_SETPCAP
              Autorise le transfert de  toutes  capacités  de  l’ensemble  des
              capacités  autorisées  de  l’appelant à partir ou vers n’importe
              quel processus.

       CAP_SETUID
              Permer  la  manipulation  arbitraire  des   UID   du   processus
              (setuid(2),  setreuid(2), setresuid(2), setfsuid(2)) ; permet de
              transmettre un faux UID sur une socket dans le domaine Unix.

       CAP_SYS_ADMIN
              Autorise  un  ensemble  d’opérations  d’administration  système,
              comprenant :   quotactl(2),   mount(2),   umount(2),  swapon(2),
              swapoff(2),   sethostname(2),   setdomainname(2),   IPC_SET   et
              IPC_RMID  sur  n’importe quel objet IPC Système V ; réaliser des
              opérations sur les attributs étendus trusted et  security  (voir
              attr(5)) ;  appeler  lookup_dcookie(2) ;  utiliser ioprio_set(2)
              pour fixer les classes d’ordonnancement d’E/S IOPRIO_CLASS_RT et
              IOPRIO_CLASS_IDLE ;  utiliser  les  opérations  KEYCTL_CHOWN  et
              KEYCTL_SETPERM de keyctl(2) ; permettre d’utiliser un  faux  UID
              pour  les  authentifications  des  sockets ;  dépasser la limite
              /proc/sys/fs/file-max dans les appels système  qui  ouvrent  les
              fichiers  (par exemple, accept(2), execve(2), open(2), pipe(2) ;
              sans cette capacité, ces appels système échouent  avec  l’erreur
              ENFILE  si  cette  limite  est  atteinte) ;  utiliser l’attribut
              CLONE_NEWNS  avec  clone(2)  et   unshare(2) ;   effectuer   les
              opérations KEYCTL_CHOWN et KEYCTL_SETPERM de keyctl(2).

       CAP_SYS_BOOT
              Autorise les appels reboot(2) et kexec_load(2).

       CAP_SYS_CHROOT
              Autorise l’appel chroot(2).

       CAP_SYS_MODULE
              Permet  le  chargement ou le déchargement de modules du noyaux ;
              permet  la  modification  des  limitations  de  capacités  (voir
              init_module(2) et delete_module(2)).

       CAP_SYS_NICE
              Autorise    la    diminution    de   la   courtoisie   (nice(2),
              setpriority(2)) et la modification de la valeur de courtoisie de
              n’importe    quel   processus ;   autorise   l’utilisation   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)) ; permet  de  définir
              l’affinité     CPU     pour     les     processus    arbitraires
              (sched_setaffinity(2)) ; de  fixer  la  classe  et  la  priorité
              d’ordonnancement    d’E/S    pour   n’importe   quel   processus
              (ioprio_set(2)) ; d’appliquer migrate_pages(2) à n’importe  quel
              processus  et  de migrer un processus vers n’importe quel nœud ;
              permet  à  move_pages(2)  d’être  appliqué   à   des   processus
              arbitraires ;  d’utiliser  l’option MPOL_MF_MOVE_ALL de mbind(2)
              et move_pages(2).

       CAP_SYS_PACCT
              Autorise l’appel acct(2).

       CAP_SYS_PTRACE
              Permet de suivre n’importe quel processus avec ptrace(2)

       CAP_SYS_RAWIO
              Autorise   les   opérations   d’entrées-sorties   (iopl(2)    et
              ioperm(2)) ; accède à /proc/kcore.

       CAP_SYS_RESOURCE
              Permet : l’utilisation de l’espace réservé sur un système ext2 ;
              l’appel ioctl(2) pour configurer  la  journalisation  ext3 ;  le
              dépassement des quotas de disque ; l’augmentation des limites de
              ressources (voir  setrlimit(2)) ;  la  surcharge  de  la  limite
              RLIMIT_NPROC ;  l’augmentation  de la limite msg_qbytes pour une
              file   de    messages    au-dessus    de    la    limite    dans
              /proc/sys/kernel/msgmnb (voir msgop(2) et msgctl(2)).

       CAP_SYS_TIME
              Autorise  la  modification  de l’heure système (settimeofday(2),
              stime(2), adjtimex(2)) ; permet  la  modification  de  l’horloge
              temps-réel (matérielle).

       CAP_SYS_TTY_CONFIG
              Autorise l’appel de vhangup(2).

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

       Effectif :
              Les  capacités  utilisées  par  le  noyau  pour   vérifier   les
              permissions du thread.

       Autoris :
              Les  capacités auxquelles le thread peut accéder (un surensemble
              limite  pour  les  ensembles  effectif  et  héritable).  Si   un
              processus  supprime une capacité de son ensemble autorisé, il ne
              peut plus jamais la récupérer (sauf s’il appelle  execve(2)  sur
              un programme Set-UID root).

       Hritable :
              Les capacités qui sont conservées au cours d’un execve(2).

       Un  enfant  créé par fork(2) reçoit 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,
       ou s’il a la  capacité  CAP_SETPCAP,  celles  d’un  thread  d’un  autre
       processus.

   Limitation des capacités
       Quand  un programme est exécuté, les capacités effectives et autorisées
       sont filtrées par  un  ET  binaire  avec  la  valeur  en  cours  de  la
       limitation     des     capacits,     définie     dans    le    fichier
       /proc/sys/kernel/cap-bound. Ce paramètre peut servir à fixer une limite
       au   niveau  système  sur  les  capacités  disponibles  pour  tous  les
       programmes exécutés ultérieurement. (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 fixer l’ensemble des  limitations ;  sinon,
       le superutilisateur peut uniquement effacer des bits dans 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  des  capacités  a été ajoutée à Linux à partir du noyau
       2.2.11.

   Implémentations actuelle et à venir
       Une implémentation complète des capacités réclame :

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

       2.  que  le  noyau  fournisse un appel système permettant de changer et
           récupérer les ensembles de capacités d’un processus.

       3.  le support du système de fichiers pour attacher des  capacités  aux
           fichiers exécutables, pour qu’un processus en dispose en lançant le
           programme.

       Sous Linux 2.6.14, seules les deux premières clauses sont remplies.

       Il pourrait même être possible d’associer trois ensembles  de  capacité
       avec un fichier exécutable, lesquels, en conjonction avec les ensembles
       de capacité du processus, détermineront les capacités dont un processus
       disposera après un execve(2) :

       Hritable (anciennement autoris) :
              cet  ensemble est combiné par un ET avec l’ensemble héritable du
              thread pour  savoir  quelles  capacités  seront  héritées  après
              l’appel execve(2).

       Autoris (anciennement forc) :
              les  capacités  automatiquement  fournies au thread, quelles que
              soient ses capacités héritables.

       Effectif :
              les capacités qui  du  nouvel  ensemble  autorisé  seront  aussi
              placées  dans  l’ensemble effectif. (F(effectif) est normalement
              entièrement composé de zéros ou de uns).

       En attendant, comme  l’implémentation  actuelle  ne  supporte  pas  les
       ensembles de capacités sur les fichiers, au cours d’un execve(2) :

       1.  Les trois ensembles de capacités du fichier sont supposés vides.

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

       3.  Si un programme Set-UID root est exécuté, alors l’ensemble effectif
           du fichier est rempli avec des uns.

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

           P’(autorisé) = (P(héritable) & F(héritable) |
                          (F(autorisé) & cap_bset)

           P’(effectif) = P’(autorisé) & F(effectif)

           P’(héritable) = P(héritable)    [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.

       Dans  l’implémentation  actuelle,  l’effet  de  cet  algorithme 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  autorisé
       et  effectif,  sauf  celles  qui  sont  interdites par la limitation de
       capacités  (c’est-à-dire  CAP_SETPCAP).  Ceci  fournit  une  sémantique
       identique à celle fournie par les systèmes Unix traditionnels.

   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 autorisé et effectif.

       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 autorisé est copié dans l’ensemble effectif.

       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 et CAP_FSETID. Si le fsuid devient nul, chacune  de  ces
           capacités  est  activée  dans  l’ensemble  effectif si elle faisait
           partie de l’ensemble autorisé.

       Si un thread dont l’un des UID vaut 0 ne  veut  pas  que  son  ensemble
       autorisé  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).

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.

NOTES

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

BOGUES

       Il n’y a pas encore de support dans le système de  fichiers  permettant
       d’associer les capacités et les fichiers exécutables.

VOIR AUSSI

       capget(2), prctl(2), setfsuid(2), credentials(7), pthreads(7)

COLOPHON

       Cette  page  fait  partie  de  la  publication 2.80 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> ».