Capacites(7) Miscellaneous Information Manual Capacites(7) NOM capabilities - Presentation des capacites Linux DESCRIPTION Pour verifier les permissions, les implementations UNIX traditionnelles distinguent deux categories de processus : les processus privilegies (dont l'UID effectif est 0, appele superutilisateur ou root) et les processus non privilegies (dont les UID effectifs sont differents de zero). Les processus privilegies contournent toutes 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 additionnels). A partir de Linux 2.2, Linux scinde les privileges traditionnellement associes au superutilisateur en unites distinctes, connues sous le nom de capabilities (capacites) que l'on peut activer ou inhiber individuellement. Les capacites sont des attributs individuels a chaque thread. Liste des capacites 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_READ (depuis Linux 3.16) Autoriser la lecture du journal d'audit au moyen d'un socket netlink multidiffusion. CAP_AUDIT_WRITE (depuis Linux 2.6.11) Ecrire des enregistrements dans le journal d'audit du noyau. CAP_BLOCK_SUSPEND (depuis Linux 3.5) Utiliser des fonctionnalites qui peuvent bloquer la mise en veille du systeme (epoll(7) EPOLLWAKEUP, /proc/sys/wake_lock). CAP_BPF (depuis Linux 5.8) Utiliser des operations BPF privilegiees ; consultez bpf(2) et bpf-helpers(7). Cette capacite a ete ajoutee dans Linux 5.8 pour separer la fonctionnalite BPF de la capacite CAP_SYS_ADMIN surchargee. CAP_CHECKPOINT_RESTORE (depuis Linux 5.9) - Mettre a jour /proc/sys/kernel/ns_last_pid (consultez pid_namespaces(7)) ; - Utiliser la fonction set_tid de clone3(2) ; - Lire le contenu des liens symboliques dans /proc/pid/map_files pour les autres processus. Cette capacite a ete ajoutee dans Linux 5.9 pour separer la fonctionnalite checkpoint/restore de la capacite CAP_SYS_ADMIN surchargee. CAP_CHOWN Effectuer toute modification des UID et GID de fichiers (consultez chown(2)). CAP_DAC_OVERRIDE Contourner les verifications des permissions de lecture, ecriture et execution. (DAC est l'abreviation de << discretionary access control >>, controle d'acces a volonte). CAP_DAC_READ_SEARCH - Contourner les verifications des permissions de lecture de fichiers et celles de lecture et d'execution des repertoires ; - invoquer open_by_handle_at(2) ; - utiliser l'attribut AT_EMPTY_PATH de linkat(2) pour creer un lien vers un fichier vise par un descripteur de fichier. CAP_FOWNER - Contourner les verifications pour les operations qui demandent que l'UID de systeme de fichiers 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 d'inoeuds (consultez FS_IOC_SETFLAGS(2const)) pour n'importe quel fichier ; - positionner les listes de controle d'acces ACL (<< Access Control Lists >>) pour n'importe quel fichier ; - ignorer le << sticky bit >> des repertoires pour les suppressions de fichier ; - modifier les attributs etendus user sur un repertoire avec le sticky bit defini, appartenant a n'importe quel utilisateur ; - specifier O_NOATIME dans open(2) et fcntl(2) pour n'importe quel fichier. CAP_FSETID - Ne pas effacer les bits de mode set-user-ID et set-group-ID lors de la modification d'un fichier ; - positionner le bit Set-group-ID sur un fichier dont le GID ne correspond pas au systeme de fichiers ni a aucun GID additionnel du processus appelant. CAP_IPC_LOCK - Verrouiller des pages memoire (mlock(2), mlockall(2), mmap(2), shmctl(2)) ; - allouer des pages memoire utilisant des pages larges (memfd_create(2), mmap(2), shmctl(2)). CAP_IPC_OWNER Contourner les verifications de permission pour les operations sur les objets IPC System V. CAP_KILL Contourner les verifications de permission pour l'emission de signaux (consultez kill(2)). Cette capacite inclut l'utilisation de l'operation KDSIGACCEPT d'ioctl(2). CAP_LEASE (depuis Linux 2.4) Demander des baux (leases) sur n'importe quel fichier (consultez fcntl(2)). CAP_LINUX_IMMUTABLE Positionner les attributs d'inoeuds FS_APPEND_FL et FS_IMMUTABLE_FL (consultez FS_IOC_SETFLAGS(2const)). CAP_MAC_ADMIN (depuis Linux 2.6.25) Permettre les modifications de la configuration ou des etats MAC. Implementee pour le module LSM (Smack Linux Security Module). CAP_MAC_OVERRIDE (depuis Linux 2.6.25) Surcharger les controles d'acces MAC (<< Mandatory Access Control >>). Implementee pour le module Smack LSM. CAP_MKNOD (depuis Linux 2.4) Creer des fichiers speciaux avec mknod(2). CAP_NET_ADMIN Effectuer diverses operations liees au reseau : - configuration des interfaces ; - administration du pare-feu, de la traduction d'adresse IP (<< masquerading >>) et collection de donnees sur le trafic reseau (<< accounting >>) ; - modification des tables de routages ; - attachement a n'importe quelle adresse pour un service mandataire transparent ; - selection du type de service (<< TOS >>) ; - effacement des statistiques du pilote ; - selection du mode << promiscuite >> ; - activation de la diffusion multipoint (<< multicast >>) ; - utilisation de setsockopt(2) pour definir les options de sockets suivantes : SO_DEBUG, SO_MARK, SO_PRIORITY (pour une priorite en dehors des valeurs de 0 a 6), SO_RCVBUFFORCE et SO_SNDBUFFORCE. CAP_NET_BIND_SERVICE Attacher un socket a un port privilegie du domaine de l'Internet (numero de port inferieur a 1024). CAP_NET_BROADCAST (Inutilise) diffusion par socket et ecoute de multidiffusion. CAP_NET_RAW - Utiliser des sockets RAW et PACKET ; - attacher a n'importe quelle adresse pour un service mandataire transparent. CAP_PERFMON (depuis Linux 5.8) Utiliser divers mecanismes de suivi des performances dont : - appeler perf_event_open(2) ; - utiliser diverses operations BPF qui ont des incidences sur les performances. Cette capacite a ete ajoutee dans Linux 5.8 pour separer la fonctionnalite de suivi des performances de la capacite CAP_SYS_ADMIN surchargee. Consultez aussi le fichier source du noyau Documentation/admin-guide/perf-security.rst. CAP_SETGID - Faire des manipulations arbitraires des GID et de la liste de GID additionnels des processus ; - simuler des GID lors du passage de references de sockets au moyen de sockets de domaine UNIX ; - ecrire une projection de GID dans un espace de noms utilisateur (consultez user_namespaces(7)). CAP_SETFCAP (depuis Linux 2.6.24) Definir des capacites arbitraires sur un fichier Depuis Linux 5.12, cette capacite est aussi necessaire pour projeter l'UID 0 dans un nouvel espace de noms utilisateur ; pour en savoir plus consultez user_namespaces(7). CAP_SETPCAP Si les capacites de fichier sont prises en charge (c'est-a-dire depuis Linux 2.6.24) : 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 les attributs securebits. Si les capacites de fichier ne sont pas prises en charge (c'est-a-dire avec les noyaux anterieurs a Linux 2.6.24) : accorder ou interdire toute capacite dans l'ensemble des capacites permises de 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 capacites de fichiers, puisque CAP_SETPCAP a une toute autre semantique pour ces noyaux). CAP_SETUID - Faire des manipulations arbitraires des UID de processus (setuid(2), setreuid(2), setresuid(2), setfsuid(2)) ; - simuler des UID lors du passage de references de sockets au moyen de sockets de domaine UNIX ; - ecrire une projection de l'UID dans un espace de noms utilisateur (consultez user_namespaces(7)). CAP_SYS_ADMIN Remarque : cette capacite est surchargee : voir les Notes pour les developpeurs du noyau ci-dessous. - Effectuer certaines operations d'administration systeme comme : quotactl(2), mount(2), umount(2), pivot_root(2), swapon(2), swapoff(2), sethostname(2) et setdomainname(2) ; - effectuer des operations syslog(2) necessitant des droits (depuis Linux 2.6.37, CAP_SYSLOG doit etre utilisee pour permettre de telles operations) ; - effectuer une commande VM86_REQUEST_IRQ vm86(2) ; - acceder a la meme fonctionnalite checkpoint/restore qui est controlee par CAP_CHECKPOINT_RESTORE (mais cette derniere capacite plus faible est preferee pour acceder a cette fonctionnalite) ; - effectuer les memes operations BPF que celles controlees par CAP_BPF (mais cette derniere capacite plus faible est preferee pour acceder a cette fonctionnalite) ; - utiliser les memes mecanismes de suivi des performances qui sont controles par CAP_PERFMON (mais cette derniere capacite plus faible est preferee pour acceder a cette fonctionnalite) ; - effectuer des operations IPC_SET et IPC_RMID sur n'importe quel objet IPC System V ; - ne pas tenir compte de la limite de ressource RLIMIT_NPROC ; - effectuer des operations sur les attributs etendus trusted et security (consultez xattr(7)) ; - utiliser lookup_dcookie(2) ; - utiliser ioprio_set(2) pour configurer une classe d'ordonnancement d'E/S IOPRIO_CLASS_RT et (avant Linux 2.6.25) IOPRIO_CLASS_IDLE ; - simuler des PID lors du passage de references de sockets au moyen de sockets de domaine UNIX ; - depasser /proc/sys/fs/file-max, la limite systeme du nombre de fichiers ouverts dans les appels systeme qui ouvrent des fichiers (par exemple accept(2), execve(2), open(2) et pipe(2)) ; - utiliser les attributs CLONE_* qui creent de nouveaux espaces de noms avec clone(2) et unshare(2) (mais, depuis Linux 3.8, la creation d'espaces de noms utilisateur ne necessite aucune capacite) ; - acceder aux informations d'evenements perf necessitant des droits ; - appeler setns(2) (necessite la capacite CAP_SYS_ADMIN dans l'espace de noms target ; - appeler fanotify_init(2) ; - effectuer des operations KEYCTL_CHOWN et KEYCTL_SETPERM de keyctl(2) necessitant des droits ; - effectuer une operation madvise(2) MADV_HWPOISON ; - utiliser la commande TIOCSTI de ioctl(2) pour inserer des caracteres dans la file d'entrees d'un terminal autre que le terminal de controle de l'appelant ; - utiliser l'appel systeme obsolete nfsservctl(2) ; - utiliser l'appel systeme obsolete bdflush(2) ; - effectuer diverses operations ioctl(2) sur des peripheriques bloc necessitant des droits ; - effectuer diverses operations ioctl(2) sur des systemes de fichiers necessitant des droits ; - effectuer des operations ioctl(2) necessitant des droits sur le peripherique /dev/random (consultez random(4)) ; - installer un filtre seccomp(2) sans avoir a definir d'abord l'attribut de thread no_new_privs ; - modifier les regles d'autorisation ou d'interdiction pour les groupes de controle de peripherique ; - utiliser l'operation PTRACE_SECCOMP_GET_FILTER de ptrace(2) pour vider les filtres seccomp de l'observe ; - utiliser l'operation PTRACE_SETOPTIONS de ptrace(2) pour suspendre les protections seccomp de l'observe (c'est-a-dire l'attribut PTRACE_O_SUSPEND_SECCOMP) ; - effectuer des operations d'administration sur de nombreux pilotes de peripheriques ; - modifier les valeurs de courtoisie de l'autogroupe en ecrivant dans /proc/pid/autogroup (consultez sched(7)). CAP_SYS_BOOT Utiliser reboot(2) et kexec_load(2). CAP_SYS_CHROOT - Utiliser chroot(2) ; - modifier l'espace de noms montage en utilisant setns(2). CAP_SYS_MODULE - Charger ou decharger des modules noyaux (consultez init_module(2) et delete_module(2)) ; - avant Linux 2.6.25 : enlever des capacites de l'ensemble de limitation de capacites au niveau du systeme. CAP_SYS_NICE - Baisser la valeur de courtoisie (<< nice >>) (nice(2), setpriority(2)) et changer la courtoisie de n'importe quel processus ; - definir les politiques d'ordonnancement temps reel pour le processus appelant et les politiques d'ordonnancement et les priorites de n'importe quel processus (sched_setscheduler(2), sched_setparam(2), sched_setattr(2)) ; - definir l'affinite CPU pour n'importe quel processus (sched_setaffinity(2)) ; - definir 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 ; - transferer les donnees depuis ou vers la memoire de n'importe quel processus au moyen de process_vm_readv(2) et de process_vm_writev(2) ; - examiner les processus avec kcmp(2). CAP_SYS_RAWIO - Effectuer des operations d'entrees-sorties (iopl(2) et ioperm(2)) ; - acceder a /proc/kcore ; - utiliser l'operation FIBMAP de ioctl(2) ; - ouvrir les peripheriques pour acceder aux registres specifiques au modele (MSR, consultez msr(4)) d'un processeur x86 ; - mettre a jour /proc/sys/vm/mmap_min_addr ; - creer des projections en memoire aux adresses inferieures a la valeur indiquee par /proc/sys/vm/mmap_min_addr ; - projeter les fichiers dans /proc/bus/pci ; - ouvrir /dev/mem et /dev/kmem ; - effectuer diverses commandes de peripherique SCSI ; - effectuer certaines operations sur les peripheriques hpsa(4) et cciss(4) ; - effectuer certaines operations specifiques a un peripherique sur d'autres peripheriques. CAP_SYS_RESOURCE - Utiliser de l'espace reserve sur des systemes de fichiers ext2 ; - effectuer des appels ioctl(2) pour controler la journalisation ext3 ; - ne pas tenir compte des limites de quota disque ; - augmenter les limites de ressources (consultez setrlimit(2)) ; - ne pas tenir compte de la limite de ressource RLIMIT_NPROC ; - ne pas tenir compte du nombre maximal de consoles sur l'allocation de console ; - ne pas tenir compte du nombre maximal de dispositions de clavier ; - permettre des interruptions a plus de 64 Hz depuis l'horloge temps reel ; - augmenter la limite msg_qbytes pour la file de messages System V au-dessus de la limite /proc/sys/kernel/msgmnb (consultez msgop(2) et msgctl(2)) ; - permettre le contournement de la limite de ressource RLIMIT_NOFILE sur le nombre de descripteurs de fichiers << en cours >> lors de leur transmission a un autre processus au moyen d'un socket de domaine UNIX (consultez unix(7)) ; - ne pas tenir compte de la limite /proc/sys/fs/pipe-size-max lors du reglage de la capacite d'un tube avec la commande fcntl(2) avec l'argument F_SETPIPE_SZ ; - utiliser F_SETPIPE_SZ pour augmenter la capacite d'un tube au-dessus de la limite specifiee par /proc/sys/fs/pipe-max-size ; - ne pas tenir compte des limites /proc/sys/fs/mqueue/queues_max, /proc/sys/fs/mqueue/msg_max et /proc/sys/fs/mqueue/msgsize_max lors de la creation de files de messages POSIX (consultez mq_overview(7)) ; - utiliser l'operation PR_SET_MM de prctl(2) ; - affecter a /proc/pid/oom_score_adj une valeur inferieure a la derniere valeur affectee par un processus avec CAP_SYS_RESOURCE. 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) ; employer diverses operations ioctl(2) necessitant des droits sur des terminaux virtuels. CAP_SYSLOG (depuis Linux 2.6.37) - Effectuer des operations syslog(2) necessitant des droits. Consultez syslog(2) pour savoir quelles operations necessitent des droits. - Inspecter les adresses du noyau exposees par /proc et d'autres interfaces lorsque /proc/sys/kernel/kptr_restrict a la valeur 1. (Voir la discussion sur kptr_restrict dans proc(5).) CAP_WAKE_ALARM (depuis Linux 3.0) Declencher quelque chose qui reveillera le systeme (reglage des alarmes CLOCK_REALTIME_ALARM et CLOCK_BOOTTIME_ALARM). Implementations passees et actuelles Une implementation complete des capacites necessite que : - pour toutes les operations privilegiees, le noyau doit verifier si le thread a la capacite requise dans son ensemble effectif ; - le noyau doit fournir des appels systeme permettant de changer et recuperer les ensembles de capacites d'un thread ; - le systeme de fichiers doit permettre d'attacher des capacites aux fichiers executables pour qu'un processus en dispose quand le fichier est execute. Avant Linux 2.6.24, seules les deux premieres exigences sont remplies ; depuis Linux 2.6.24, ces trois exigences sont remplies. Remarques pour les developpeurs du noyau Lors de l'ajout d'une nouvelle fonctionnalite du noyau qui pourrait etre controlee par une capacite, veuillez prendre en consideration les points suivants : - Le but des capacites est de decouper le pouvoir du superutilisateur en plusieurs aptitudes de telle sorte que si un programme qui a une ou plusieurs capacites est compromis, son pouvoir d'endommager le systeme soit moindre que si le programme est execute avec les privileges du superutilisateur. - Vous pouvez choisir de creer une nouvelle capacite pour votre nouvelle fonctionnalite, ou d'associer la fonctionnalite a l'une des capacites existantes. Afin que l'ensemble des capacites garde une taille gerable, la seconde solution est preferable, a moins qu'il y ait des raisons convaincantes de choisir la premiere option (il existe aussi une limite technique : la taille des ensembles de capacites est actuellement limitee a 64 bits). - Pour determiner parmi les capacites existantes laquelle est la mieux adaptee pour etre associee a la nouvelle fonctionnalite, examinez la liste de capacites ci-dessus pour trouver un << silo >> dans lequel la nouvelle capacite est la mieux adaptee. Une des options est de determiner s'il y a d'autres fonctionnalites exigeant des capacites qui seront toujours utilisees avec la nouvelle fonctionnalite. Si la nouvelle fonctionnalite ne sert a rien sans les autres fonctions, vous devriez utiliser la meme capacite que ces autres fonctions. - Ne choisissez pas CAP_SYS_ADMIN si vous pouvez l'eviter ! Une forte proportion de verifications de capacites existantes lui sont associee (voir une liste partielle plus haut). Elle pourrait plausiblement etre appelee << la nouvelle racine >>, dans la mesure ou d'une part, elle confere une large palette de pouvoirs, et d'autre part, sa vaste portee signifie que c'est la capacite qui est requise par de nombreux programmes privilegies. Ne rendez pas le probleme encore plus complique. Les seules nouvelles fonctionnalites qui pourraient etre associees a CAP_SYS_ADMIN sont celles qui correspondent de facon etroite aux usages existants dans ce silo. - Si vous avez etabli qu'il etait reellement necessaire de creer une nouvelle capacite pour votre fonctionnalite, ne la creez pas ou ne la nommez pas comme une capacite << a usage unique >>. Par consequent, par exemple, l'ajout de la capacite tres specifique CAP_SYS_PACCT etait probablement une erreur. Essayez plutot d'identifier et de nommer votre nouvelle capacite comme un silo plus general dans lequel d'autres futures cas d'usage semblable pourraient s'integrer. Ensembles de capacites des threads Chaque thread a les ensembles de capacites suivants contenant zero ou plus des capacites ci-dessus : Permitted (permis) Il s'agit d'un surensemble 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-user-ID-root ou un programme dont les capacites associees au fichier accordent cette capacite). Inheritable (heritable) Il s'agit d'un ensemble de capacites preservees au travers d'un execve(2). Les capacites heritables restent heritables lors de l'execution d'un programme et les capacites heritables sont ajoutees a l'ensemble de capacites permises lors de l'execution d'un programme qui a les bits correspondant actives dans l'ensemble heritable du fichier. Parce que les capacites heritables ne sont generalement pas preservees au travers d'un execve(2) lors d'une execution en tant qu'utilisateur ordinaire, les applications qui souhaitent executer des programmes d'assistance avec des capacites plus elevees devraient envisager d'utiliser les capacites ambiantes, decrites ci-dessous. Effective (effectif) Il s'agit de l'ensemble des capacites utilisees par le noyau pour verifier les permissions du thread. Bounding (limitation) (par processus depuis Linux 2.6.25) L'ensemble de limitation des capacites (<< capability bounding set >>) est un mecanisme qui peut etre utilise pour limiter les capacites qui peuvent etre obtenues lors d'un execve(2). Depuis Linux 2.6.25, c'est un ensemble de capacites par thread. Dans les noyaux plus anciens, la limitation des capacites etait un attribut pour l'ensemble du systeme, partage par tous les threads du systeme. Pour plus de details, voir Ensemble de limitation des capacites, ci-dessous. Ambient (ambiant) (depuis Linux 4.3) Il s'agit d'un ensemble de capacites preservees au travers d'un execve(2) d'un programme non privilegie. L'ensemble de capacites ambiantes obeit a la regle invariable qu'aucune capacite ne peut etre ambiante si elle n'est pas a la fois permise et heritable. L'ensemble de capacites ambiantes peut etre directement modifie avec prctl(2). Les capacites ambiantes sont automatiquement diminuees si une capacites soit permises soit heritables correspondantes sont diminuees. L'execution d'un programme qui change l'UID ou le GID a cause des bits set-user-ID ou set-group-ID, ou l'execution d'un programme qui a un ensemble de capacites de fichier supprimera l'ensemble ambiant. Les capacites ambiantes sont ajoutees a l'ensemble des capacites permises et assignees a l'ensemble des capacites effectives quand execve(2) est appele. Si les capacites ambiantes font que les capacites permises et ambiantes d'un processus sont accrues durant un execve(2), cela ne declenche pas le mode << secure-execution >> decrit dans ld.so(8). Un enfant cree par fork(2) herite d'une copie des ensembles de capacites de son parent. Pour des details sur la facon dont execve(2) affecte les capacites, voir Transformation des capacites lors d'un appel execve() plus bas. En utilisant capset(2), un thread peut manipuler ses propres ensembles de capacites ; voir Ajuster les ensembles de capacites par programmation ci-dessous). A partir de Linux 3.2, le fichier /proc/sys/kernel/cap_last_cap contient la valeur numerique de la capacite la plus elevee qui soit acceptee par le noyau en cours d'execution ; cette valeur peut etre utilisee pour determiner le bit le plus eleve qui puisse etre defini dans un ensemble de capacites. Capacites de fichier Depuis Linux 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) et xattr(7)) 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 : Permitted (anciennement forced (force)) : Ces capacites sont automatiquement permises au thread, quelles que soient ses capacites heritables. Inheritable (anciennement allowed (autorise)) : Cet ensemble est combine par un ET avec l'ensemble heritable du thread pour savoir quelles capacites de l'ensemble des capacites heritables sont permises dans l'ensemble permis du thread apres l'appel a execve(2). Effective (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 capacites permises correspondantes lors d'un execve(2) (consultez Transformation des capacites lors d'un appel execve() ci-dessous) fera que ce fichier aura aussi cette capacite dans son ensemble effectif. Ainsi, lors de l'ajout de capacites a un fichier (setcap(8), cap_set_file(3), cap_set_fd(3)), si l'attribut effectif pour une des capacites est active, alors l'attribut effectif doit egalement etre active pour toutes les autres capacites dont l'attribut permis ou heritable correspondant est active. Versionnage d'attributs etendus de capacite de fichier Pour permettre l'extensibilite, le noyau prend en charge un systeme pour coder un numero de version dans l'attribut etendu security.capability qui est utilise pour implementer les capacites de fichier. Ces numeros de version sont integres a l'implementation et pas directement visibles aux applications de l'espace utilisateur. A ce jour, les versions suivantes sont prise en charge : VFS_CAP_REVISION_1 C'etait l'implementation d'origine de la capacite de fichier qui prenait en charge les masques 32 bits pour les capacites de fichier. VFS_CAP_REVISION_2 (depuis Linux 2.6.25) Cette version permet des masques de capacite de fichier d'une taille de 64 bits, ce qui etait necessaire, car le nombre de capacites prises en charge depassait 32. Le noyau continue de facon transparente a prendre en charge l'execution de fichiers qui ont des masques de capacite version 1 32 bits, mais lors de l'ajout de capacites a des fichiers qui n'avaient pas encore de capacites ou lors de la modification des capacites de fichiers existants, il utilise automatiquement le systeme de la version 2 (ou eventuellement la version 3, comme decrit plus bas). VFS_CAP_REVISION_3 (depuis Linux 4.14) Les capacites de fichier version 3 sont fournies pour prendre en charge les capacites de fichier mises dans un espace de noms (decrites plus bas). Comme avec les capacites de fichier version 2, les masques de capacite version 3 ont une longueur de 64 bits. Mais en complement, l'UID root de l'espace de noms est code dans l'attribut etendu security.capability (un UID root d'espace de noms est la valeur a laquelle l'UID 0 dans cet espace de noms correspond dans l'espace de noms utilisateur initial). Les capacites de fichier version 3 sont concues pour coexister avec les capacites version 2 ; c'est-a-dire que, sur un systeme Linux moderne, il peut y avoir certains fichiers avec des capacites version 2 tandis que d'autres ont des capacites version 3. Avant Linux 4.14, le seul type d'attribut etendu de capacite de fichier qui pouvait etre attache a un fichier etait un attribut VFS_CAP_REVISION_2. Depuis Linux 4.14, la version de l'attribut etendu security.capability attache a un fichier depend des circonstances dans lesquelles l'attribut a ete cree. A partir de Linux 4.14, un attribut etendu security.capability est cree automatiquement (ou converti) en attribut version 3 (VFS_CAP_REVISION_3) si les deux conditions suivantes sont vraies : - Le thread qui ecrit l'attribut reside dans un espace de noms utilisateur non initial (plus precisement, le thread reside dans un espace de noms utilisateur autre que celui a partir duquel le systeme de fichiers sous-jacent a ete monte). - Le thread a la capacite CAP_SETFCAP sur l'inoeud du fichier, ce qui veut dire que (a) le thread a la capacite CAP_SETFCAP dans son propre espace de noms utilisateur et (b) l'UID et le GID de l'inoeud du fichier a des correspondances dans l'espace de noms utilisateur de celui qui ecrit. Quand un attribut etendu security.capability VFS_CAP_REVISION_3 est cree, l'UID root de l'espace de noms utilisateur du thread qui cree l'attribut est enregistre dans l'attribut etendu. Par contre, la creation ou la modification d'un attribut etendu security.capability a partir d'un thread privilegie (CAP_SETFCAP) qui reside dans l'espace de noms ou le systeme de fichiers sous-jacent a ete monte (ce qui correspond normalement a l'espace de noms utilisateur initial) a automatiquement pour consequence la creation d'un attribut version 2 (VFS_CAP_REVISION_2). Veuillez noter que la creation d'un attribut etendu security.capability version 3 est automatique. C'est-a-dire que losrsqu'une application de l'espace utilisateur ecrit (setxattr(2)) un attribut security.capability au format de la version 2, le noyau creera automatiquement un attribut version 3 si l'attribut est cree dans les conditions decrites plus haut. En parallele, quand un attribut security.capability version 3 est recupere (getxattr(2)) par un processus qui reside dans un espace de noms utilisateur qui a ete cree par l'UID root (ou un descendant de cet espace de noms utilisateur), l'attribut renvoye est (automatiquement) simplifie pour apparaitre comme un attribut version 2 (c'est-a-dire que la valeur renvoyee est la taille de l'attribut version 2 et n'inclut pas l'UID root). Ces transpositions automatiques signifient qu'aucune modification n'est requise pour les outils de l'espace utilisateur (par exemple setcap(1) getcap(1)) pour que ces outils soient utilises pour creer et recuperer des attributs security.capability version 3. Veuillez noter qu'un fichier peut se voir associe un attribut etendu security.capability version 2 ou version 3, mais pas les deux a la fois : la creation ou la modification de l'attribut etendu security.capability modifiera automatiquement la version selon les conditions dans lesquelles l'attribut etendu est cree ou modifie. Transformation des capacites lors d'un appel execve() Durant un execve(2), le noyau calcule les nouvelles capacites du processus en utilisant l'algorithme suivant : P'(ambient) = (le fichier est privilegie) ? 0 : P(ambient) P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding)) | P'(ambient) P'(effective) = F(effective) ? P'(permitted) : P'(ambient) P'(inheritable) = P(inheritable) [c'est-a-dire inchange] P'(bounding) = P(bounding) [c'est-a-dire 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 du thread apres le execve(2) F() indique la valeur d'un ensemble de capacites du fichier Veuillez noter les details suivants concernant les regles de transformation de capacites ci-dessus : - L'ensemble de capacites ambiantes est present seulement depuis Linux 4.3. Lors de la determination de la transformation de l'ensemble ambiant durant un execve(2), un fichier privilegie est un fichier qui a des capacites ou le bit set-user-ID ou le bit set-group-ID positionne. - Avant Linux 2.6.25, l'ensemble de limitation de capacites etait un attribut au niveau du systeme, partage par tous les threads. Cette valeur au niveau du systeme etait employee pour calculer le nouvel ensemble de capacites permises durant un execve(2) de la meme maniere que cela est montre plus haut pour P(bounding). Note : durant les transitions de capacite decrite plus haut, les capacites de fichier peuvent etre ignorees (traitees comme si elles etaient vides) pour les memes raisons que les bits set-user-ID et set-group-ID sont ignores ; voir execve(2). Les capacites de fichier sont ignorees de la meme maniere si le noyau a ete lance avec l'option no_file_caps. Note : conformement aux regles ci-dessus, si un processus avec des UID differents de zero executent un execve(2), alors toutes les capacites presentes dans son ensemble de capacites permises et effectives seront supprimees. Pour le traitement de capacites quand un processus avec un UID de zero execute un execve(2), consultez ci-dessous Capacites et execution de programmes par le superutilisateur. Verification de securite pour les binaires passives aux capacites Un binaire passif aux capacites est une application qui a ete marquee pour avoir des capacites de fichier, mais n'a pas ete convertie pour utiliser l'API libcap(3) pour manipuler ses capacites (en d'autres mots, c'est un programme set-user-iD-root traditionnel qui a ete modifie pour utiliser des capacites de fichier, mais dont le code n'a pas ete modifie pour comprendre les capacites). Pour ce type d'application, le bit de capacite effective est defini sur le fichier, de telle sorte que les capacites de fichier permises soient activees automatiquement dans l'ensemble de capacites effectives du processus lors de l'execution du fichier. Le noyau reconnait un fichier qui a un bit de capacite effective defini comme passif aux capacites en vue de la verification decrite ici. Lors de l'execution d'un binaire passif aux capacites, le noyau verifie si le processus a obtenu toutes les capacites permises qui sont specifiees dans l'ensemble de capacites permises de fichier, apres que les transformations de capacite decrites plus haut ont ete executees (la raison habituelle pour laquelle cela pourrait ne pas se produire est que l'ensemble de limitation de capacites a interdit certaines des capacites dans l'ensemble de capacites permises de fichier). Si le processus n'obtient pas l'ensemble complet de capacites permises de fichier, alors l'execve(2) echoue avec l'erreur EPERM. Cela evite de possibles risques de securite qui pourraient survenir quand une application passive aux capacites est executee avec moins de privileges que necessaire. Notez que, par definition, l'application ne pourrait pas reconnaitre elle-meme ce probleme, dans la mesure ou elle n'emploie pas l'API libcap(3). Capacites et execution de programmes par le superutilisateur Afin de refleter les semantiques traditionnelles d'UNIX, le noyau effectue un traitement particulier des capacites de fichier quand un processus avec l'UID 0 (superutilisateur) execute un programme et quand un programme set-user-ID-root est execute. Apres avoir realise toutes les modifications de l'ID effectif du processus qui ont ete declenchees par le bit de mode set-user-ID du binaire (par exemple, le changement de l'UID a 0 (superutilisateur) parce qu'un programme set-user-ID-root a ete execute), le noyau calcule les ensembles de capacites de fichier comme suit : (1) Si l'UID reel ou effectif du processus est 0 (superutilisateur), alors les ensembles de capacites heritables et permises de fichier sont ignores ; ils sont plutot consideres theoriquement comme remplis de uns (c'est-a-dire, toutes les capacites activees). Il y a une exception a ce comportement, decrite ci-dessous dans la section Programmes set-user-ID-root qui ont des capacites de fichier. (2) Si l'UID effectif du processus est 0 (superutilisateur) ou le bit des capacites effectives du fichier est en fait active, alors le bit des capacites effectives du fichier est theoriquement defini a un (active). Ces valeurs theoriques pour les ensembles de capacites de fichier sont alors utilisees comme decrites ci-dessus pour calculer la transformation des capacites du processus durant l'execve(2). Alors, quand un processus avec des UID differents de zero appelle execve(2) sur un programme set-user-ID-root qui n'a pas de capacites attachees ou quand un processus dont les UID reel et effectif sont zero applique execve(2) sur un programme, le calcul des nouvelles capacites permises du processus est simplifie a : P'(permitted) = P(inheritable) | P(bounding) P'(effective) = P'(permitted) En consequence, le processus obtient toutes les capacites dans ses ensembles de capacites permises et effectives, a l'exception de celles supprimees par l'ensemble de limitation de capacites (dans le calcul de P'(permitted), le terme P'(ambient) peut etre simplifie parce qu'il est par definition un sous-ensemble propre de P(inheritable)). Les traitements particuliers de l'UID 0 (superutilisateur) decrits dans cette sous-section peuvent etre desactives en utilisant le mecanisme de << securebits >> decrit plus bas. Les programmes set-user-ID-root qui ont des capacites de fichier Il y a une exception au comportement decrit dans Capacites et execution de programmes par le superutilisateur ci-dessus. Si (a) le binaire qui est en cours d'execution a des capacites attachees, (b) l'UID reelle du processus n'est pas 0 (supertutilisateur) et (c) l'UID effectif du processus est 0 (superutilisateur), alors les bits de capacite de fichier sont honores (c'est-a-dire qu'ils ne sont pas theoriquement consideres comme remplis de uns). La circonstance habituelle dans laquelle cette situation peut se produire est lors de l'execution d'un programme set-user-ID-root qui a aussi les capacites de fichier. Quand un programme de ce type est execute, le processus obtient simplement les capacites accordees par le programme (c'est-a-dire pas toutes les capacites comme cela pourrait se produire lors de l'execution d'un programme set-user-ID-root qui ne possede aucune capacite de fichier associee). Notez qu'il est possible d'assigner un ensemble de capacites vide a un fichier de programme et donc qu'il est possible de creer un programme set-user-ID-root qui modifie en 0 le set-user-ID effectif et sauvegarde du processus qui execute le programme, mais ne confere aucune capacite a ce processus. Ensemble de limitation des capacites L'ensemble de 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). L'ensemble de limitation de capacites est utilise de cette facon : - Lors d'un execve(2), l'ensemble de limitation de capacites est combinee par 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. L'ensemble de limitation de capacites permet donc de limiter les capacites permises qui peuvent etre accordees par un fichier executable. - (Depuis Linux 2.6.25) L'ensemble de limitation de capacites agit comme un surensemble limitant les capacites qu'un thread peut ajouter a son ensemble de capacites heritables en utilisant capset(2). Cela 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 l'ensemble de 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, l'ensemble de limitation de capacites est un attribut au niveau du systeme ou un attribut par processus. Ensemble de limitation de capacites apres Linux 2.6.25 Depuis Linux 2.6.25, l'ensemble de limitation de capacites est un attribut par thread. (L'ensemble de limitation de capacites au niveau du systeme decrite ci-dessous n'existe plus.) L'ensemble de limitation est herite 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 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 fichier sont compilees dans le noyau. Avant Linux 2.6.33, les capacites de fichier etaient une fonctionnalite optionnelle configurable ua moyen de l'option CONFIG_SECURITY_FILE_CAPABILITIES. Depuis Linux 2.6.33, l'option de configuration a ete supprimee et les capacites de fichier font maintenant toujours partie du noyau. Quand les capacites de fichier sont compilees dans le noyau, le processus init (l'ancetre de tous les processus) demarre avec un ensemble de limitation complet. Si les capacites de fichier ne sont pas compilees dans le noyau, init demarre alors avec un ensemble de limitation complet, 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 l'ensemble de limitation de capacites ne la supprime pas de l'ensemble heritable d'un thread. Cependant, il empeche de rajouter la capacite dans l'ensemble heritable du thread par la suite. Ensemble de limitation de capacites avant Linux 2.6.25 Avant Linux 2.6.25, l'ensemble de limitation de capacites est un attribut au niveau du systeme qui affecte tous les threads. L'ensemble de 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 ; en dehors de cela, le superutilisateur (plus precisement : un processus avec la capacite CAP_SYS_MODULE) peut uniquement supprimer des capacites de cet ensemble. Sur un systeme standard, l'ensemble de 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. L'ensemble de limitation de capacites pour tout le systeme a ete ajoutee a Linux 2.2.11. Effet des modifications d'UID sur les capacites Afin de preserver la semantique traditionnelle pour les transitions entre des UID 0 et des UID differents de zero, le noyau modifie les ensembles de capacites d'un thread de la facon suivante lors de modifications des UID reel, effectif, sauvegarde et du systeme de fichiers (avec setuid(2), setresuid(2) et compagnie) : - Si un ou plus des UID reels, effectifs ou sauves etaient egal a 0, et qu'a la suite de la modification d'UID, tous ces ID ont une valeur differente de zero, et toutes les capacites sont supprimees des ensembles de capacites permises, effectives et ambiantes. - Si l'UID effectif etait 0 et devient different de zero, toutes les capacites sont supprimees de l'ensemble effectif. - Si l'UID effectif est modifie d'une valeur differente de zero a 0, l'ensemble des capacites permises est copie dans l'ensemble des capacites effectives. - Si l'UID du systeme de fichiers est modifie de 0 a une valeur differente de zero (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.6.30), CAP_MAC_OVERRIDE et CAP_MKNOD (depuis Linux 2.6.30). Si l'UID du systeme de fichiers devient 0, 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 qui a une valeur 0 pour un ou plus de ses UID ne veut pas que son ensemble de capacites permises soit vide lorsqu'il redefinit tous ses UID a des valeurs non nulles, il peut le faire avec l'attribut << securebits >> de SECBIT_KEEP_CAPS decrit ci-dessous. Ajuster les ensembles de capacites par programmation Un thread peut obtenir ou modifier ses ensembles de capacites permises, effectives et heritees 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 : - 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. - (Depuis Linux 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. - 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). - Le nouvel ensemble effectif doit etre un sous-ensemble du nouvel ensemble des capacites permises. Les attributs << securebits >> : configuration d'un environnement restreint aux capacites de fichier. A partir de Linux 2.6.26, si les capacites de fichier sont activees dans le noyau, 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 dans son ensemble des capacites permises quand il change tous ses UID et que plus aucun n'est zero. Si cet attribut est desactive, alors ces changements d'UID feront perdre au thread toutes ses capacites permises. Cet attribut est toujours desactive lors d'un execve(2). Notez que meme quand l'attribut SECBIT_KEEP_CAPS est actif, les capacites effectives d'un thread sont supprimees quand il change son UID effectif pour une valeur differente de zero. Neanmoins, si le thread a active cet attribut et que son UID effectif est deja different de zero et si le thread change ensuite tous les autres UID pour des valeurs differentes de zero, alors, les capacites effectives ne seront pas supprimees. L'activation de l'attribut SECBIT_KEEP_CAPS est ignoree si l'attribut SECBIT_NO_SETUID_FIXUP est actif (ce dernier attribut fournit un surensemble des effets de l'attribut precedent). 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 permises, effectives et ambiantes du processus par le noyau lorsque les UID effectifs et du systeme de fichiers du thread passent d'une valeur zero a une valeur differente de zero. Consultez Effet des modifications d'UID sur les capacites plus haut. SECBIT_NOROOT Si cet attribut est active, alors le noyau n'accorde pas les capacites lorsqu'un programme set-user-ID-root est execute ou lorsqu'un processus dont l'UID effectif ou reel est zero appelle execve(2) (consultez Capacites et execution de programmes par le superutilisateur ci-dessus). SECBIT_NO_CAP_AMBIENT_RAISE Activer cet attribut desactive l'elevation des capacites ambiantes au moyen de l'operation PR_CAP_AMBIENT_RAISE de prctl(2). Chacun des attributs de << base >> ci-dessus a un attribut compagnon << verrouille >>. L'activation d'un attribut << verrouille >> est irreversible et permet d'eviter toute modification ulterieure de l'attribut de << base >> correspondant. Les attributs << verrouille >> sont : SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED, SECBIT_NOROOT_LOCKED et SECBIT_NO_CAP_AMBIENT_RAISE_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. Notez que les constantes SECBIT_* ne sont disponibles qu'apres l'inclusion du fichier d'en-tete . Les attributs securebits sont herites par les processus enfants. Lors d'un execve(2), tous les attributs sont conserves, a l'exception de SECBIT_KEEP_CAPS qui est toujours desactive. Une application peut utiliser l'appel suivant pour se verrouiller elle-meme, ainsi que tous ses descendants, dans un environnement ou la seule facon d'obtenir des capacites est d'executer un programme avec les capacites de fichiers associees : prctl(PR_SET_SECUREBITS, /* SECBIT_KEEP_CAPS desactive */ SECBIT_KEEP_CAPS_LOCKED | SECBIT_NO_SETUID_FIXUP | SECBIT_NO_SETUID_FIXUP_LOCKED | SECBIT_NOROOT | SECBIT_NOROOT_LOCKED); /* Activation/verrouillage de SECBIT_NO_CAP_AMBIENT_RAISE non requis */ Programmes << set-user_ID-root >> par espace de noms utilisateur Un programme set-user-ID dont l'UID correspond a l'UID qui a cree par un espace de noms utilisateur donnera des capacites dans les ensembles de capacites permises et effectives du processus lorsqu'il etait utilise par un processus dans l'espace de noms ou tout espace de noms utilisateur qui en est issu. Les regles de transformation des capacites du processus pendant un execve(2) sont exactement comme decrites dans Transformation des capacites lors d'un appel execve() et Capacites et execution de programmes par le superutilisateur ci-dessus;a la difference que, dans la seconde sous-section, << root >> est l'UID du createur de l'espace de noms utilisateur. Capacites de fichier mises dans un espace de noms Les capacites de fichier traditionnelles (c'est-a-dire version 2) n'associent qu'un ensemble de masques de capacite a un fichier binaire executable. Quand un processus execute un binaire avec des capacites de ce type, il obtient les capacites associees (dans son espace de noms utilisateur) comme pour les regles decrites ci-dessus dans Transformation des capacites lors d'un appel execve(). Etant donne que les capacites de fichier version 2 conferent des capacites pour l'execution de processus quel que soit l'espace de noms utilisateur dans lequel il reside, seuls les processus privilegies ont le droit d'associer des capacites avec un fichier. Ici, << privilegie >> veut dire un processus qui a la capacite CAP_SETFCAP dans l'espace de noms utilisateur ou le systeme de fichiers a ete monte (normalement, l'espace de noms initial de l'utilisateur). Cette limitation rend les capacites de fichier inutiles dans certains cas d'usage. Par exemple, dans les conteneurs d'un espace de noms utilisateur, il peut etre souhaitable de pouvoir creer un binaire qui confere des capacites uniquement au processus execute dans ce conteneur, mais pas aux processus executes en dehors du conteneur. Linux 4.14 a ajoute des capacites de fichier appelees << mises dans un espace de noms >> pour gerer ce genre de cas d'usage. Les capacites de fichier mises dans un espace de noms sont enregistrees en tant qu'attribut etendu security.capability version 3 (c'est-a-dire VFS_CAP_REVISION_3). Un attribut de ce type est cree automatiquement dans les circonstances decrites ci-dessus dans Versionnage d'attributs etendus de capacite de fichier. Quand un attribut etendu security.capability version 3 est cree, le noyau n'enregistre pas que les masques de capacite dans l'attribut etendu, mais aussi l'UID root de l'espace de noms. Comme c'est le cas avec un binaire qui possede des capacites de fichier VFS_CAP_REVISION_2, un binaire avec des capacites de fichier VFS_CAP_REVISION_3 confere des capacites a un processus durant un execve(). Neanmoins, ces capacites ne sont conferees que si le processus est execute par un processus qui reside dans un espace de noms utilisateur dont l'UID 0 correspond a l'UID root qui est sauvegarde dans l'attribut etendu, ou quand il est execute par un processus qui reside dans un descendant de ce type d'espace de noms. Interaction avec les espaces de noms Pour en savoir plus sur les interactions entre les capacites et les espaces de noms utilisateur, consultez user_namespaces(7). STANDARDS Il n'y a pas de veritable norme pour les capacites, mais l'implementation de Linux est basee sur une interpretation de l'avant-projet de norme (retire) POSIX.1e . NOTES Quand vous tentez de suivre avec strace(1) des binaires qui ont des capacites (ou des binaires set-user-UID-root), vous pouvez trouver l'option -u . Quelque chose comme ceci : $ sudo strace -o trace.log -u ceci ./mon_prog_prive De Linux 2.5.27 a Linux 2.6.26, les capacites etaient un composant optionnel du noyau et pouvaient 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 processus. Avant Linux 3.8, les capacites inexistantes etaient vues comme activees (1) dans ces ensembles. Depuis Linux 3.8, toutes les capacites inexistantes (superieures a la valeur de CAP_LAST_CAP) sont vues comme desactivees (0). Le paquet libcap fournit un ensemble de routines pour ecrire et connaitre 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 : . Avant Linux 2.6.24, et de Linux 2.6.24 a Linux 2.6.32, 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 la capacite CAP_SETPCAP et cela ne peut pas etre change sans modifier les sources du noyau et le recompiler. - Si les capacites de fichier sont desactivees (c'est-a-dire si l'option CONFIG_SECURITY_FILE_CAPABILITIES du noyau est desactivee), alors init demarre sans la capacite CAP_SETPCAP dans l'ensemble de limitation de capacites par processus, et cet ensemble de limitation de capacite est herite par tous les processus crees sur le systeme. VOIR AUSSI capsh(1), setpriv(1), prctl(2), setfsuid(2), cap_clear(3), cap_copy_ext(3), cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_init(3), capgetp(3), capsetp(3), libcap(3), proc(5), credentials(7), pthreads(7), user_namespaces(7), captest(8), filecap(8), getcap(8), getpcaps(8), netcap(8), pscap(8), setcap(8) include/linux/capability.h dans les sources du noyau Linux TRADUCTION La traduction francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot , Cedric Boutillier , Frederic Hantrais et Jean-Pierre Giraud Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.12 13 juin 2024 Capacites(7)