NOM
capabilities - Présentation des capacités Linux
Pour vérifier les permissions, les implémentations Unix traditionnelles
distinguent deux catégories de processus : les processus privilgis
(dont l’UID effectif est 0, appelé superutilisateur ou root), et les
processus non privilgis (dont l’UID effectif est non-nul). Les
processus privilégiés contournent les vérifications de permissions du
noyau, alors que les processus non-privilégiés sont soumis à une
vérification complète basée sur l’identification du processus
(habituellement : UID effectif, GID effectif, et liste des groupes).
À partir du noyau 2.2, Linux propose un mécanisme (encore incomplet) de
capacits, qui scinde les privilèges traditionnellement associés au
superutilisateur en unités distinctes que l’on peut activer ou inhiber
individuellement.
Liste des capacités
La liste suivante indique les capacités implémentées sous Linux et les
opérations ou comportements que chaque capacité permet :
CAP_AUDIT_CONTROL (depuis Linux 2.6.11)
Activer et désactiver l’audit du noyau ; changer les règles de
filtrage d’audit ; accéder à l’état de l’audit, et aux règles de
filtrage.
CAP_AUDIT_WRITE (depuis Linux 2.6.11)
Écrire des enregistrements dans le journal d’audit du noyau.
CAP_CHOWN
Effectuer toute modification des UID et GID de fichiers (voir
chown(2)).
CAP_DAC_OVERRIDE
Contourne les permissions de lecture, écriture et exécution.
(DAC est l’abréviation de « discretionary access control »,
contrôle d’accès à volonté).
CAP_DAC_READ_SEARCH
Contourne les permissions de lecture de fichiers et celles de
lecture et exécution des répertoires.
CAP_FOWNER
* Contourne les vérifications pour les opérations qui demandent
que le FS-UID du processus corresponde à l’UID du fichier (par
exemple chmod(2), utime(2)), à l’exclusion des opérations
couvertes par CAP_DAC_OVERRIDE et CAP_DAC_READ_SEARCH ;
* positionner les attributs de fichier étendus (voir chattr(1))
pour n’importe quel fichier ;
* positionner les listes de contrôle d’accès ACL (Ndt : Access
Control Lists) pour n’importe quel fichier ;
* ignorer le bit sticky des répertoires pour les suppressions de
fichier ;
* spécifier O_NOATIME dans open(2) et fcntl(2) pour n’importe
quel fichier.
CAP_FSETID
Ne pas effacer les bits de permission Set-UID et Set-GID quand
un fichier est modifié ; positionner le bit Set-GID sur un
fichier dont le GID ne correspond à aucun GID du processus
appelant.
CAP_IPC_LOCK
Verrouiller des pages mémoire (mlock(2), mlockall(2), mmap(2),
shmctl(2)).
CAP_IPC_OWNER
Contourne les vérifications pour les opérations sur les IPC
System V.
CAP_KILL
Contourne les vérifications pour l’émission de signaux (voir
kill(2)). Cela inclut l’utilisation de l’ioctl(2) KDSIGACCEPT.
CAP_LEASE (depuis Linux 2.4)
Demander des baux sur n’importe quel fichier (voir fcntl(2)).
CAP_LINUX_IMMUTABLE
Positionner les attributs d’inoeuds FS_APPEND_FL et
FS_IMMUTABLE_FL (voir chattr(1)).
CAP_MAC_ADMIN (depuis Linux 2.6.25)
Surcharger les contrôles d’accès MAC (« Mandatory Access
Control »). Implémentée pour le module de sécurité (LSM :
« Linux Security Module ») Smack.
CAP_MAC_OVERRIDE (depuis Linux 2.6.25)
Permettre les modifications de la configuration ou des états
MAC. Implémentée pour le LSM Smack.
CAP_MKNOD (depuis Linux 2.4)
Créer des fichiers spéciaux avec mknod(2).
CAP_NET_ADMIN
Effectuer différentes opérations réseau (par exemple obtenir des
options privilégiées sur les sockets, activer le multicast,
configurer les interfaces, modifier les tables de routage).
CAP_NET_BIND_SERVICE
Attacher une socket sur un port privilégié (numéro de port
inférieur à 1024).
CAP_NET_BROADCAST
(Inutilisé) Broadcastet et écouter en multicast avec des
sockets.
CAP_NET_RAW
Utiliser des sockets RAW et PACKET.
CAP_SETGID
Effectuer toute manipulation des GID du processus et de la liste
de groupes supplémentaires, utiliser de faux GID sur les socket
Unix.
CAP_SETFCAP (depuis Linux 2.6.24)
Définir des capacités de fichier
CAP_SETPCAP
Si les capacités de fichier sont prises en charge : autoriser ou
interdire toute capacité dans l’ensemble des capacité permises à
l’appelant vers ou depuis tout autre processus. (Cette propriété
de CAP_SETPCAP n’est pas disponible quand le noyau est configuré
pour prendre en charge les capacité de fichiers, puisque
CAP_SETPCAP a une toute autre sémantique pour ces noyaux)
Si les capacitésde fichier sont prises en charge : ajouter toute
capacité de l’ensemble de limitation de capacités du thread
appelant à son ensemble hérité ; supprimer les capacités de
l’ensemble de limitation de capacités (avec prctl(2)
PR_CAPBSET_DROP) ; modifier l’attribut securebits.
CAP_SETUID
Effectuer toute manipulation des UID de processus (setuid(2),
setreuid(2), setresuid(2), setfsuid(2)) ; transmettre un faux
UID sur une socket dans le domaine Unix.
CAP_SYS_ADMIN
* Effectuer certaines opération d’administration comme :
quotactl(2), mount(2), umount(2), swapon(2), swapoff(2),
sethostname(2) et setdomainname(2) ;
* effectuer des opérations IPC_SET et IPC_RMID sur n’importe
quel objet IPC System V ;
* effectuer des opérations sur les attributs étendus trusted et
security (voir attr(5)) ;
* utiliser lookup_dcookie(2) ;
* utiliser ioprio_set(2) pour configurer une classe
d’ordonnancement IOPRIO_CLASS_RT (avant Linux 2.6.25) et
IOPRIO_CLASS_IDLE ;
* forger des identifiant d’utilisateur lors du passage de
références de sockets ;
* dépasser /proc/sys/fs/file-max, la limite système du nombre de
fichiers ouverts, dans les appels systèmes qui ouvrent des
fichiers (c’est-à-dire accept(2), execve(2), open(2) et
pipe(2)) ;
* utiliser l’attribut CLONE_NEWNS avec clone(2) et unshare(2) ;
* effectuer des opérations keyctl(2) KEYCTL_CHOWN et
KEYCTL_SETPERM.
CAP_SYS_BOOT
Utiliser reboot(2) et kexec_load(2).
CAP_SYS_CHROOT
Utiliser chroot(2).
CAP_SYS_MODULE
Charger ou décharger des modules noyau (voir init_module(2) et
delete_module(2)) ; dans les noyaux antérieurs à 2.6.25 :
enlever des capacités de l’ensemble système de limitation de
capacités.
CAP_SYS_NICE
* Augmenter la valeur de courtoisie (« nice ») (nice(2),
setpriority(2)) et changer la courtoisie de n’importe quel
processus ;
* utiliser des ordonnancements temps-réel pour le processus
appelant, et la modification de l’ordonnancement de n’importe
quel processus (sched_setscheduler(2), sched_setparam(2)) ;
* définir l’affinité CPU pour n’importe quel processus
(sched_setaffinity(2)) ;
* fixer la classe et la priorité d’ordonnancement
d’entrées/sorties pour n’importe quel processus
(ioprio_set(2)) ;
* appliquer migrate_pages(2) à n’importe quel processus et
migrer un processus vers n’importe quel nœud ;
* appliquer move_pages(2) pour n’importe quel processus ;
* utiliser l’attribut MPOL_MF_MOVE_ALL avec mbind(2) et
move_pages(2).
CAP_SYS_PACCT
Utiliser acct(2).
CAP_SYS_PTRACE
Suivre n’importe quel processus avec ptrace(2)
CAP_SYS_RAWIO
Effectuer des opérations d’entrées-sorties (iopl(2) et
ioperm(2)) ; accéder à /proc/kcore.
CAP_SYS_RESOURCE
* Utiliser de l’espace réservé sur des systèmes de fichiers
ext2 ;
* effectuer des appels ioctl(2) pour controller la
journalisation ext3 ;
* ne pas tenir compte des limites définies par les quota
disque ;
* augmenter les limites de ressources (voir setrlimit(2)) ;
* ne pas tenir compte de la limite de ressource RLIMIT_NPROC ;
* augmenter la limite msg_qbytes pour la queue de messages
System V au dessus de la limite /proc/sys/kernel/msgmnb (voir
msgop(2) et msgctl(2)).
CAP_SYS_TIME
Modifier l’heure système (settimeofday(2), stime(2),
adjtimex(2)); modifier l’horloge temps-réel (matérielle).
CAP_SYS_TTY_CONFIG
Utiliser vhangup(2).
Implémentations passées et actuelles
Une implémentation complète des capacités nécessite que :
1. Pour toutes les opérations privilégiées, le noyau doit vérifier si
le thread a la capacité requise dans son ensemble effectif ;
2. Le noyau doit fournir des appels système permettant de changer et
récupérer les ensembles de capacités d’un thread.
3. Le système de fichiers doit permettre d’attacher des capacités aux
fichiers exécutables, pour qu’un processus en dispose quand le
fichier est exécuté.
Sous Linux 2.6.14, seules les deux premières clauses sont
remplies.Avant le noyau 2.6.24, seules les deux premières exigences
sont remplies ; depuis le noyau 2.6.24, ces trois exigences sont
remplies.
Ensembles de capacités des threads
Chaque thread a trois ensembles contenant zéro ou plus des capacités
ci-dessus :
Permises :
Il s’agit d’un sur-ensemble limitant les capacités effectives
que le thread peut prendre. Il limite également les capacités
qui peuvent être ajoutées à l’ensemble héritable par un thread
qui n’a pas la capacité CAP_SETPCAP dans son ensemble effectif.
Si un processus supprime une capacité de son ensemble de
capacités permises, il ne peut plus jamais la récupérer (sauf
s’il appelle execve(2) sur un programme Set-UID root ou un
programme dont les capacités associées au fichier permettent
cette capacité).
Hritable :
Il s’agit d’un ensemble de capacités préservées au travers d’un
execve(2). Il fournit à un processus un mécanisme pour assigner
des capacités à l’ensemble des capacités permises du nouveau
programme lors d’un execve(2).
Effectif :
Il s’agit de l’ensemble des capacités utilisées par le noyau
pour vérifier les permissions du thread.
Un fils créé par fork(2) hérite d’une copie des ensembles de capacité
de son père. Le traitement des capacités lors d’un execve(2) est décrit
plus bas.
En utilisant capset(2), un thread peut manipuler ses propres ensembles
de capacités (voir ci-dessous).
Capacités de fichier
Depuis le noyau 2.6.24, le noyau prend en charge l’association
d’ensembles de capacités avec un fichier exécutable à l’aide de
setcap(8). Les ensembles de capacités du fichier sont stockés dans un
attribut étendu (voir setxattr(2)) appelé security.capability. Écrire
dans cet attribut étendu nécessite la capacité CAP_SETFCAP. Les
ensembles de capacités d’un fichier, combinés avec les ensembles de
capacités du thread déterminent les capacités d’un thread après un
execve(2).
Les trois ensembles de capacités de fichier sont :
Permises (anciennement forces) :
Ces capacités sont automatiquement permises au thread, quelles
que soient ses capacités héritables.
Hritables (anciennement autorises) :
Cet ensemble est combiné par un ET avec l’ensemble héritable du
thread pour savoir quelles capacités de l’ensemble des capacités
permises sont permises pour le thread après l’appel à execve(2).
Effectif :
Il ne s’agit pas d’un ensemble, mais plutôt d’un unique bit. Si
le bit est positionné, alors, lors d’un execve(2), toutes les
nouvelles capacités permises pour le thread sont également
positionnées dans l’ensemble effectif. Si ce bit n’est pas
positionné, alors, après un execve(2), aucune des nouvelles
capacités permises ne se trouvera dans le nouvel ensemble
effectif.
Activer le bit des capacités effectives d’un fichier implique
que toute capacité de fichier permise ou héritable qui permet à
un thread d’obtenir les capacité permises correspondantes lors
d’un execve(2) (voir les règles de transformation décrites
ci-dessous) fournira également cette capacité dans l’ensemble de
capacités effectives du thread. Ainsi, lors de l’ajout de
capacités à un fichier (setcap(8), cap_set_file(3),
cap_set_fd(3)), si le bit effectif pour une des capacités est
activé, alors le bit effectif doit également être activé pour
toutes les capacités dont le bit permis ou héritable
corresppondant est activé.
Transformation des capacités lors d’un appel execve()
Durant un execve(2), le noyau calcule les nouvelles capacités du
processus en utilisant l’algorithme suivant :
P’(permises) = (P(héritables) & F(héritables) |
(F(permises) & cap_bset)
P’(effectives) = F(effectives) ? P’(permises) : 0
P’(héritables) = P(héritables) [inchangé]
où :
P indique la valeur d’un ensemble de capacités du thread
avant le execve(2)
P’ indique la valeur d’un ensemble de capacités après le
execve(2)
F indique la valeur d’un ensemble de capacités du fichier
cap_bset est la valeur de la limitation de capacités (décrit
ci-dessous).
Capacités et exécution de programmes par root
Pour fournir un root tout puissant en utilisant les ensembles de
capacités, lors d’un execve(2) :
1. Si on exécute un programme Set-UID root, ou si l’UID réel est nul,
alors les ensembles des capacités héritables et permises du fichier
sont remplis de uns (toutes les capacités activées).
2. Si un programme Set-UID root est exécuté, alors le bit des capacités
effectives du fichier est défini à 1 (activé).
L’effet des règles ci-dessus combinées avec les transformations de
capacités ci-dessus, est que lorsqu’un processus lance (avec execve(2))
un programme Set-UID root, ou lorsqu’un processus d’UID effectif nul
exécute un programme, il obtient toutes les capacités dans ses
ensembles de capacités permises et effectives, sauf celles qui sont
interdites par la limitation de capacités. Ceci fournit une sémantique
identique à celle fournie par les systèmes Unix traditionnels.
Limitation des capacités
La limitation des capacités (« capability bounding set ») est un
mécanisme de sécurité qui peut être utilisé pour limiter les capacités
qui peuvent être obtenues lors d’un execve(2). La limitation de
capacités est utilisée de cette façon :
* Lors d’un execve(2), la limitation de capacités (un ensemble de
capacités) est combinée avec un ET binaire avec l’ensemble des
capacités autorisées du fichier, et le résultat de cette opération
est placé dans l’ensemble des capacités autorisées du thread. La
limitation de capacités permet donc de limiter les capacités permises
qui peuvent être accordées à un fichier exécutable.
* (Depuis Linux 2.6.25) La limitation de capacités agit comme un
sur-ensemble limitant les capacités qu’un thread peut ajouter à son
ensemble de capacités héritables en utilisant capset(2). Ceci
signifie que si une capacité ne se trouve pas dans l’ensemble de
limitation des capacités, alors un thread ne peut ajouter cette
capacité dans son ensemble de capacités héritables, même si elle se
trouvait dans son ensemble de capacités permises, et ne peut donc pas
conserver cette capacité dans son ensemble de capacités permises
lorsqu’il exécute avec execve(2) un fichier qui a cette capacité dans
son ensemble de capacités héritables.
Notez que la limitation de capacités masque les capacités permises du
fichier, mais pas les capacités héritées. Si un thread conserve une
capacité dans son ensemble de capacités héritées et que cette capacité
ne se trouve pas dans l’ensemble de limitation des capacités, alors il
peut toujours obtenir cette capacité dans son ensemble de capacités
permises en exécutant un fichier qui a la capacité dans son ensemble de
capacités héritées.
Suivant la version du noyau, la limitation de capacités est un attribut
au niveau du système ou un attribut par processus.
Limitation de capacités avant Linux 2.6.25
Dans les noyaux antérieurs à 2.6.25, la limitation de capacités est un
attribut au niveau du système qui affecte tous les threads. La
limitation de capacités est accessible par le fichier
/proc/sys/kernel/cap-bound. (Le masque de bits est exprimé comme un
nombre décimal signé dans /proc/sys/kernel/cap-bound, ce qui entretient
les confusions).
Seul le processus init peut configurer des capacité dans l’ensemble de
limitation de capacités ; sinon, le superutilisateur (plus
précisément : les programmes avec la capacité CAP_SYS_MODULE) peut
uniquement supprimer des capacités de cet ensemble.
Sur un système standard, la limitation élimine toujours la capacité
CAP_SETPCAP. Pour supprimer cette restriction (attention, c’est
dangereux !), modifiez la définition de CAP_INIT_EFF_SET dans
include/linux/capability.h et recompilez le noyau.
La limitation de capacités système a été ajoutée à Linux à partir du
noyau 2.2.11.
Limitation de capacités après Linux 2.6.25
Depuis Linux 2.6.25, la limitation de capacits est un attribut par
thread (il n’y a plus désormais de limitation de capacités au niveau du
système).
La limitation est héritée du parent du thread au travers d’un fork(2)
et est préservé au travers d’un execve(2).
Un thread peut enlever des capacités de son ensemble de limitation de
capacités en utilisant l’opération PR_CAPBSET_DROP de prctl(2), à
condition qu’il possède la capacité CAP_SETPCAP. Une fois qu’une
capacité a été supprimée de l’ensemble de limitation, elle ne peut être
y être remise. Un thread peut déterminer si une capacité est dans son
ensemble de limitation de capacités en utilisant l’opération
PR_CAPBSET_READ de prctl(2).
La suppression de capacités dans l’ensemble de limitation des capacités
n’est prise en charge que si les capacités de fichiers sont compilés
dans le noyau (CONFIG_SECURITY_FILE_CAPABILITIES). Dans ce cas, le
processus init démarre avec ensemble plein à l’exception de
CAP_SETPCAP, parce que cette capacité a une autre signification quand
il n’y a pas de capacités de fichier.
Supprimer une capacité de la limitation de capacités ne la supprime pas
de l’ensemble hérité d’un thread. Cependant il empêche de rajouter la
capacité dans l’ensemble hérité du thread par la suite.
Effet des modifications d’UID sur les capacités
Afin de préserver la sémantique traditionnelle pour les transitions
entre des UID nul et non nul, le noyau modifie les ensembles de
capacités d’un thread de la façon suivante lors de modifications des
UID réel, effectif, sauvé et du système de fichiers (avec setuid(2),
setresuid(2) et compagnie) :
1. Si l’UID réel, effectif ou sauvé était égal à 0, et qu’à la suite de
la modification ils sont tous non nuls, toutes les capacités sont
supprimés des ensembles de capacités permises et effectives.
2. Si l’UID effectif était nul et devient non nul, toutes les capacités
sont supprimées de l’ensemble effectif.
3. Si l’UID effectif est modifié d’une valeur non nulle à 0, l’ensemble
des capacités permises est copié dans l’ensemble des capacités
effectives.
4. Si le fsuid est modifié de 0 à une valeur non nulle (voir
setfsuid(2)), les capacités suivantes sont supprimées de l’ensemble
effectif : CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH,
CAP_FOWNER, CAP_FSETID, CAP_LINUX_IMMUTABLE (depuis Linux 2.2.30),
CAP_MAC_OVERRIDE et CAP_MKNOD (depuis Linux 2.2.30). Si le fsuid
devient nul, chacune de ces capacités est activée dans l’ensemble
des capacités effectives si elle faisait partie de l’ensemble des
capacités permises.
Si un thread dont l’un des UID vaut 0 ne veut pas que son ensemble de
capacités permises soit vidé lorsqu’il fixe tous ses UID à des valeurs
non nulles, il peut le faire avec l’opération PR_SET_KEEPCAPS de
l’appel système prctl(2).
Ajuster les ensembles de capacités par programmation
Un thread peut obtenir ou modifier ses ensembles de capacités en
utilisant les appels système capget(2) et capset(2). Cependant, il faut
leur préférer l’utilisation de cap_get_proc(3) et cap_set_proc(3),
toutes deux fournies par le paquet libcap. Les règles suivantes
gouvernent les modifications des ensembles de capacités d’un thread :
1. Si l’appelant n’a pas la capacité CAP_SETPCAP, le nouvel ensemble
des capacités héritables doit être un sous-ensemble de l’union des
ensembles de capacités héritables et des capacités permises.
2. (Depuis le noyau 2.6.25) Le nouvel ensemble héritable doit être un
sous-ensemble de l’ensemble héritable existant et de l’ensemble de
limitation de capacités.
3. Le nouvel ensemble des capacités permises doit être un sous-ensemble
de l’ensemble des capacités permises existant (c’est-à-dire qu’il
n’est pas possible d’obtenir des capacités permises que le thread
n’a pas actuellement).
4. Le nouvel ensemble effectif doit être un sous-ensemble du nouvel
ensemble des capacités permises.
Les attributs « securebits » : configuration d’un environnement restreint
aux capacités de fichiers.
A partir du noyau 2.6.26, si les capacités de fichiers sont activées,
Linux implémente un ensemble d’attributs securebits par thread qui
peuvent être utilisés pour désactiver la gestion particulière des
capacités pour l’UID 0 (root). Ces attributs sont les suivants :
SECURE_KEEP_CAPS
Activer cet attribut permet à un thread qui a un UID (ou plus)
égal à 0 de conserver ses capacités quand il change ses UID et
que plus aucun n’est nul. Si cet attribut est désactivé, alors
ces changements d’UID feront perdre au thread toutes ses
capacités. Cet attribut est toujours désactivé lors d’un
execve(2). Cet attribut fournit la même fonctionnalité que
l’ancienne opération PR_SET_KEEPCAPS de prctl(2)).
SECURE_NO_SETUID_FIXUP
Activer cet attribut stoppe l’ajustement des ensemble de
capacités par le noyau lorsque les UID effectifs et d’accès aux
fichiers du thread passent d’une valeur nulle à une valeur non
nulle. (Consultez la sous-section Effet des modifications dUID
sur les capacits.)
SECURE_NOROOT
Si cet attribut est activé, alors le noyau n’autorise pas les
capacités lorsqu’un programme Set-UID root est exécuté ou
lorsqu’un processus dont l’identifiant effectif ou réel est nul
appelle execve(2). (Consultez la sous-section Capacits et
excution de programmes par root.)
Chacun des attributs de base ci-dessus a un attribut compagnon de
verrouillage. L’activation d’un attribut de verrouillage est
irréversible et permet d’éviter toute modification ultérieure de
l’attribut de base. Les attributs de verrouillage sont :
SECURE_KEEP_CAPS_LOCKED, SECURE_NO_SETUID_FIXUP_LOCKED et
SECURE_NOROOT_LOCKED.
Les attributs securebits peuvent être modifiés et récupérés en
utilisant les opérations PR_SET_SECUREBITS et PR_GET_SECUREBITS de
prctl(2). La capacité CAP_SETPCAP est nécessaire pour modifier ces
attributs.
Les attributs securebits sont hérités par les processus fils. Lors d’un
execve(2), tous les attributs sont conservés, à l’exception de
SECURE_KEEP_CAPS qui est désactivé.
Une application peut utiliser l’appel suivant pour se verrouiller
elle-même, ainsi que tous ses descendant, dans un environnement où la
seule façon d’obtenir des capacités est d’exécuter un programme avec
les capacités de fichiers correspondantes :
prctl(PR_SET_SECUREBITS,
1 << SECURE_KEEP_CAPS_LOCKED |
1 << SECURE_NO_SETUID_FIXUP |
1 << SECURE_NO_SETUID_FIXUP_LOCKED |
1 << SECURE_NOROOT |
1 << SECURE_NOROOT_LOCKED);
CONFORMITÉ
Il n’y a pas de véritable norme pour les capacités, mais
l’implémentation Linux est basé sur une interprétation de la norme
(retirée) POSIX.1e ; voir http://wt.xpilot.org/publications/posix.1e/.
NOTES
Depuis le noyau 2.5.27, les capacités sont optionnelles dans le noyau
et peuvent être activées ou désactivées avec l’option de configuration
CONFIG_SECURITY_CAPABILITIES du noyau.
Le fichier /proc/PID/task/TID/status peut être utilisé pour voir les
ensembles de capacités d’un thread. Le fichier /proc/PID/status indique
les ensembles de capacités du thread principal d’un thread.
Le paquet libcap fournit un ensemble de routines pour écrire et lire
les capacités d’un processus, de manière plus simple et moins
susceptible de changer que l’interface fournie par capset(2) et
capget(2). Ce paquet fournit également les programmes setcap(8) et
getcap(8). Il peut être trouvé à l’adresse :
http://www.kernel.org/pub/linux/libs/security/linux-privs.
Avant le noyau 2.6.24, et depuis le noyau 2.6.24 si les capacités de
fichier ne sont pas activées, un thread avec la capacité CAP_SETPCAP
peut manipuler les capacités des autres threads. Cependant, ce n’est
possible qu’en théorie puisqu’aucun thread n’a la capacité CAP_SETPCAP
dans un des cas suivants :
* Dans l’implémentation antérieure au noyau 2.6.25, l’ensemble de
limitation de capacités du système, /proc/sys/kernel/cap-bound,
masque toujours cette capacité et ceci ne peut pas être changé sans
modifier les sources du noyau et le recompiler.
* Si les capacités de fichiers sont désactivées dans l’implémentation
actuelle, alors init démarre sans cette capacité dans l’ensemble de
limitation de capacité de son processus, et cet ensemble de
limitation de capacité est hérité par tous les processus créés sur le
système.
VOIR AUSSI
capget(2), prctl(2), setfsuid(2), cap_clear(3), cap_copy_ext(3),
cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_init(3),
capgetp(3), capsetp(3), credentials(7), pthreads(7), getcap(8),
setcap(8)
include/linux/capability.h dans les sources du noyau
COLOPHON
Cette page fait partie de la publication 3.23 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent être trouvées à l’adresse
http://www.kernel.org/doc/man-pages/.
TRADUCTION
Cette page de manuel a été traduite et mise à jour par Christophe
Blaess <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et mise à
disposition sur http://manpagesfr.free.fr/.
Les mises à jour et corrections de la version présente dans Debian sont
directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
francophone de traduction de Debian.
Veuillez signaler toute erreur de traduction en écrivant à
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document
en utilisant la commande « man -L C <section> <page_de_man> ».