Provided by:
manpages-fr_3.32d0.2p4-1_all 
NOM
capabilities - Presentation des capacites Linux
DESCRIPTION
Pour verifier les permissions, les implementations UNIX traditionnelles
distinguent deux categories de processus : les processus privil'egi'es
(dont l'UID effectif est 0, appele superutilisateur ou root), et les
processus non privil'egi'es (dont l'UID effectif est non-nul). Les
processus privilegies contournent les verifications de permissions du
noyau, alors que les processus non-privilegies sont soumis a une
verification complete basee sur l'identification du processus
(habituellement : UID effectif, GID effectif, et liste des groupes).
A partir du noyau 2.2, Linux propose un mecanisme (encore incomplet) de
capacit'es, qui scinde les privileges traditionnellement associes au
superutilisateur en unites distinctes que l'on peut activer ou inhiber
individuellement.
Liste des capacit'es
La liste suivante indique les capacites implementees sous Linux et les
operations ou comportements que chaque capacite permet :
CAP_AUDIT_CONTROL (depuis Linux 2.6.11)
Activer et desactiver l'audit du noyau ; changer les regles de
filtrage d'audit ; acceder a l'etat de l'audit, et aux regles de
filtrage.
CAP_AUDIT_WRITE (depuis Linux 2.6.11)
Ecrire des enregistrements dans le journal d'audit du noyau.
CAP_CHOWN
Effectuer toute modification des UID et GID de fichiers
(consultez chown(2)).
CAP_DAC_OVERRIDE
Contourne les permissions de lecture, ecriture et execution.
(DAC est l'abreviation de << discretionary access control >>,
controle d'acces a volonte).
CAP_DAC_READ_SEARCH
Contourne les permissions de lecture de fichiers et celles de
lecture et execution des repertoires.
CAP_FOWNER
* Contourne les verifications pour les operations qui demandent
que le FS-UID du processus corresponde a l'UID du fichier (par
exemple chmod(2), utime(2)), a l'exclusion des operations
couvertes par CAP_DAC_OVERRIDE et CAP_DAC_READ_SEARCH ;
* positionner les attributs de fichier etendus (consultez
chattr(1)) pour n'importe quel fichier ;
* positionner les listes de controle d'acces ACL (<< Access
Control Lists >>) pour n'importe quel fichier ;
* ignorer le bit sticky des repertoires pour les suppressions de
fichier ;
* specifier O_NOATIME dans open(2) et fcntl(2) pour n'importe
quel fichier.
CAP_FSETID
Ne pas effacer les bits de permission Set-UID et Set-GID quand
un fichier est modifie ; positionner le bit Set-GID sur un
fichier dont le GID ne correspond a aucun GID du processus
appelant.
CAP_IPC_LOCK
Verrouiller des pages memoire (mlock(2), mlockall(2), mmap(2),
shmctl(2)).
CAP_IPC_OWNER
Contourne les verifications pour les operations sur les IPC
System V.
CAP_KILL
Contourne les verifications pour l'emission de signaux
(consultez kill(2)). Cela inclut l'utilisation de l'ioctl(2)
KDSIGACCEPT.
CAP_LEASE (depuis Linux 2.4)
Demander des baux sur n'importe quel fichier (consultez
fcntl(2)).
CAP_LINUX_IMMUTABLE
Positionner les attributs d'inoeuds FS_APPEND_FL et
FS_IMMUTABLE_FL (consultez chattr(1)).
CAP_MAC_ADMIN (depuis Linux 2.6.25)
Surcharger les controles d'acces MAC (<< Mandatory Access
Control >>). Implementee pour le module de securite (LSM :
<< Linux Security Module >>) Smack.
CAP_MAC_OVERRIDE (depuis Linux 2.6.25)
Permettre les modifications de la configuration ou des etats
MAC. Implementee pour le LSM Smack.
CAP_MKNOD (depuis Linux 2.4)
Creer des fichiers speciaux avec mknod(2).
CAP_NET_ADMIN
Effectuer differentes operations reseau (par exemple obtenir des
options privilegiees sur les sockets, activer le multicast,
configurer les interfaces, modifier les tables de routage).
CAP_NET_BIND_SERVICE
Attacher une socket sur un port privilegie (numero de port
inferieur a 1024).
CAP_NET_BROADCAST
(Inutilise) Broadcastet et ecouter en multicast avec des
sockets.
CAP_NET_RAW
Utiliser des sockets RAW et PACKET.
CAP_SETGID
Effectuer toute manipulation des GID du processus et de la liste
de groupes supplementaires, utiliser de faux GID sur les socket
UNIX.
CAP_SETFCAP (depuis Linux 2.6.24)
Definir des capacites de fichier
CAP_SETPCAP
Si les capacites de fichier sont prises en charge : autoriser ou
interdire toute capacite dans l'ensemble des capacites permises
a l'appelant vers ou depuis tout autre processus. (Cette
propriete de CAP_SETPCAP n'est pas disponible quand le noyau est
configure pour prendre en charge les capacite de fichiers,
puisque CAP_SETPCAP a une toute autre semantique pour ces
noyaux)
Si les capacites de fichier sont prises en charge : ajouter
toute capacite de l'ensemble de limitation de capacites du
thread appelant a son ensemble herite ; supprimer les capacites
de l'ensemble de limitation de capacites (avec prctl(2)
PR_CAPBSET_DROP) ; modifier l'attribut securebits.
CAP_SETUID
Effectuer toute manipulation des UID de processus (setuid(2),
setreuid(2), setresuid(2), setfsuid(2)) ; transmettre un faux
UID sur une socket dans le domaine UNIX.
CAP_SYS_ADMIN
* Effectuer certaines operations d'administration comme :
quotactl(2), mount(2), umount(2), swapon(2), swapoff(2),
sethostname(2) et setdomainname(2) ;
* effectuer des operations IPC_SET et IPC_RMID sur n'importe
quel objet IPC System V ;
* effectuer des operations sur les attributs etendus trusted et
security (consultez attr(5)) ;
* utiliser lookup_dcookie(2) ;
* utiliser ioprio_set(2) pour configurer une classe
d'ordonnancement IOPRIO_CLASS_RT (avant Linux 2.6.25) et
IOPRIO_CLASS_IDLE ;
* forger des identifiants d'utilisateur lors du passage de
references de sockets ;
* depasser /proc/sys/fs/file-max, la limite systeme du nombre de
fichiers ouverts, dans les appels systeme qui ouvrent des
fichiers (c'est-a-dire accept(2), execve(2), open(2) et
pipe(2)) ;
* utiliser l'attribut CLONE_NEWNS avec clone(2) et unshare(2) ;
* effectuer des operations keyctl(2) KEYCTL_CHOWN et
KEYCTL_SETPERM ;
* effectuer une operation madvise(2) MADV_HWPOISON.
CAP_SYS_BOOT
Utiliser reboot(2) et kexec_load(2).
CAP_SYS_CHROOT
Utiliser chroot(2).
CAP_SYS_MODULE
Charger ou decharger des modules noyaux (consultez
init_module(2) et delete_module(2)) ; dans les noyaux anterieurs
a 2.6.25 : enlever des capacites de l'ensemble systeme de
limitation de capacites.
CAP_SYS_NICE
* Augmenter la valeur de courtoisie (<< nice >>) (nice(2),
setpriority(2)) et changer la courtoisie de n'importe quel
processus ;
* utiliser des ordonnancements temps-reel pour le processus
appelant, et la modification de l'ordonnancement de n'importe
quel processus (sched_setscheduler(2), sched_setparam(2)) ;
* definir l'affinite CPU pour n'importe quel processus
(sched_setaffinity(2)) ;
* fixer la classe et la priorite d'ordonnancement
d'entrees/sorties pour n'importe quel processus
(ioprio_set(2)) ;
* appliquer migrate_pages(2) a n'importe quel processus et
migrer un processus vers n'importe quel noeud ;
* appliquer move_pages(2) pour n'importe quel processus ;
* utiliser l'attribut MPOL_MF_MOVE_ALL avec mbind(2) et
move_pages(2).
CAP_SYS_PACCT
Utiliser acct(2).
CAP_SYS_PTRACE
Suivre n'importe quel processus avec ptrace(2) ; appliquer
get_robust_list(2) a n'importe quel processus.
CAP_SYS_RAWIO
Effectuer des operations d'entrees-sorties (iopl(2) et
ioperm(2)) ; acceder a /proc/kcore.
CAP_SYS_RESOURCE
* Utiliser de l'espace reserve sur des systemes de fichiers
ext2 ;
* effectuer des appels ioctl(2) pour controller la
journalisation ext3 ;
* ne pas tenir compte des limites definies par les quota
disque ;
* augmenter les limites de ressources (consultez setrlimit(2)) ;
* ne pas tenir compte de la limite de ressource RLIMIT_NPROC ;
* augmenter la limite msg_qbytes pour la queue de messages
System V au dessus de la limite /proc/sys/kernel/msgmnb
(consultez msgop(2) et msgctl(2)).
* utiliser F_SETPIPE_SZ pour augmenter la capacite d'un tube
au-dessus de la limite specifiee par
/proc/sys/fs/pipe-max-size.
CAP_SYS_TIME
Modifier l'heure systeme (settimeofday(2), stime(2),
adjtimex(2)) ; modifier l'horloge temps-reel (materielle).
CAP_SYS_TTY_CONFIG
Utiliser vhangup(2).
Impl'ementations pass'ees et actuelles
Une implementation complete des capacites necessite que :
1. Pour toutes les operations privilegiees, le noyau doit verifier si
le thread a la capacite requise dans son ensemble effectif ;
2. Le noyau doit fournir des appels systeme permettant de changer et
recuperer les ensembles de capacites d'un thread.
3. Le systeme de fichiers doit permettre d'attacher des capacites aux
fichiers executables, pour qu'un processus en dispose quand le
fichier est execute.
Sous Linux 2.6.14, seules les deux premieres clauses sont
remplies.Avant le noyau 2.6.24, seules les deux premieres exigences
sont remplies ; depuis le noyau 2.6.24, ces trois exigences sont
remplies.
Ensembles de capacit'es des threads
Chaque thread a trois ensembles contenant zero ou plus des capacites
ci-dessus :
Permises :
Il s'agit d'un sur-ensemble limitant les capacites effectives
que le thread peut prendre. Il limite egalement les capacites
qui peuvent etre ajoutees a l'ensemble heritable par un thread
qui n'a pas la capacite CAP_SETPCAP dans son ensemble effectif.
Si un processus supprime une capacite de son ensemble de
capacites permises, il ne peut plus jamais la recuperer (sauf
s'il appelle execve(2) sur un programme Set-UID root ou un
programme dont les capacites associees au fichier permettent
cette capacite).
H'eritable :
Il s'agit d'un ensemble de capacites preservees au travers d'un
execve(2). Il fournit a un processus un mecanisme pour assigner
des capacites a l'ensemble des capacites permises du nouveau
programme lors d'un execve(2).
Effectif :
Il s'agit de l'ensemble des capacites utilisees par le noyau
pour verifier les permissions du thread.
Un fils cree par fork(2) herite d'une copie des ensembles de capacite
de son pere. Le traitement des capacites lors d'un execve(2) est decrit
plus bas.
En utilisant capset(2), un thread peut manipuler ses propres ensembles
de capacites (voir ci-dessous).
Capacit'es de fichier
Depuis le noyau 2.6.24, le noyau prend en charge l'association
d'ensembles de capacites avec un fichier executable a l'aide de
setcap(8). Les ensembles de capacites du fichier sont stockes dans un
attribut etendu (consultez setxattr(2)) appele security.capability.
Ecrire dans cet attribut etendu necessite la capacite CAP_SETFCAP. Les
ensembles de capacites d'un fichier, combines avec les ensembles de
capacites du thread determinent les capacites d'un thread apres un
execve(2).
Les trois ensembles de capacites de fichier sont :
Permises (anciennement forc'ees) :
Ces capacites sont automatiquement permises au thread, quelles
que soient ses capacites heritables.
H'eritables (anciennement autoris'ees) :
Cet ensemble est combine par un ET avec l'ensemble heritable du
thread pour savoir quelles capacites de l'ensemble des capacites
permises sont permises pour le thread apres l'appel a execve(2).
Effectif :
Il ne s'agit pas d'un ensemble, mais plutot d'un unique bit. Si
le bit est positionne, alors, lors d'un execve(2), toutes les
nouvelles capacites permises pour le thread sont egalement
positionnees dans l'ensemble effectif. Si ce bit n'est pas
positionne, alors, apres un execve(2), aucune des nouvelles
capacites permises ne se trouvera dans le nouvel ensemble
effectif.
Activer le bit des capacites effectives d'un fichier implique
que toute capacite de fichier permise ou heritable qui permet a
un thread d'obtenir les capacite permises correspondantes lors
d'un execve(2) (consultez les regles de transformation decrites
ci-dessous) fournira egalement cette capacite dans l'ensemble de
capacites effectives du thread. Ainsi, lors de l'ajout de
capacites a un fichier (setcap(8), cap_set_file(3),
cap_set_fd(3)), si le bit effectif pour une des capacites est
active, alors le bit effectif doit egalement etre active pour
toutes les capacites dont le bit permis ou heritable
corresppondant est active.
Transformation des capacit'es lors d'un appel execve()
Durant un execve(2), le noyau calcule les nouvelles capacites du
processus en utilisant l'algorithme suivant :
P'(permises) = (P(heritables) & F(heritables) |
(F(permises) & cap_bset)
P'(effectives) = F(effectives) ? P'(permises) : 0
P'(heritables) = P(heritables) [inchange]
ou :
P indique la valeur d'un ensemble de capacites du thread
avant le execve(2)
P' indique la valeur d'un ensemble de capacites apres le
execve(2)
F indique la valeur d'un ensemble de capacites du fichier
cap_bset est la valeur de la limitation de capacites (decrit
ci-dessous).
Capacit'es et ex'ecution de programmes par root
Pour fournir un root tout puissant en utilisant les ensembles de
capacites, lors d'un execve(2) :
1. Si on execute un programme Set-UID root, ou si l'UID reel est nul,
alors les ensembles des capacites heritables et permises du fichier
sont remplis de uns (toutes les capacites activees).
2. Si un programme Set-UID root est execute, alors le bit des capacites
effectives du fichier est defini a 1 (active).
L'effet des regles ci-dessus combinees avec les transformations de
capacites ci-dessus, est que lorsqu'un processus lance (avec execve(2))
un programme Set-UID root, ou lorsqu'un processus d'UID effectif nul
execute un programme, il obtient toutes les capacites dans ses
ensembles de capacites permises et effectives, sauf celles qui sont
interdites par la limitation de capacites. Ceci fournit une semantique
identique a celle fournie par les systemes UNIX traditionnels.
Limitation des capacit'es
La limitation des capacites (<< capability bounding set >>) est un
mecanisme de securite qui peut etre utilise pour limiter les capacites
qui peuvent etre obtenues lors d'un execve(2). La limitation de
capacites est utilisee de cette facon :
* Lors d'un execve(2), la limitation de capacites (un ensemble de
capacites) est combinee avec un ET binaire avec l'ensemble des
capacites autorisees du fichier, et le resultat de cette operation
est place dans l'ensemble des capacites autorisees du thread. La
limitation de capacites permet donc de limiter les capacites permises
qui peuvent etre accordees a un fichier executable.
* (Depuis Linux 2.6.25) La limitation de capacites agit comme un
sur-ensemble limitant les capacites qu'un thread peut ajouter a son
ensemble de capacites heritables en utilisant capset(2). Ceci
signifie que si une capacite ne se trouve pas dans l'ensemble de
limitation des capacites, alors un thread ne peut ajouter cette
capacite dans son ensemble de capacites heritables, meme si elle se
trouvait dans son ensemble de capacites permises, et ne peut donc pas
conserver cette capacite dans son ensemble de capacites permises
lorsqu'il execute avec execve(2) un fichier qui a cette capacite dans
son ensemble de capacites heritables.
Notez que la limitation de capacites masque les capacites permises du
fichier, mais pas les capacites heritees. Si un thread conserve une
capacite dans son ensemble de capacites heritees et que cette capacite
ne se trouve pas dans l'ensemble de limitation des capacites, alors il
peut toujours obtenir cette capacite dans son ensemble de capacites
permises en executant un fichier qui a la capacite dans son ensemble de
capacites heritees.
Suivant la version du noyau, la limitation de capacites est un attribut
au niveau du systeme ou un attribut par processus.
Limitation de capacit'es avant Linux 2.6.25
Dans les noyaux anterieurs a 2.6.25, la limitation de capacites est un
attribut au niveau du systeme qui affecte tous les threads. La
limitation de capacites est accessible par le fichier
/proc/sys/kernel/cap-bound. (Le masque de bits est exprime comme un
nombre decimal signe dans /proc/sys/kernel/cap-bound, ce qui entretient
les confusions).
Seul le processus init peut configurer des capacites dans l'ensemble de
limitation de capacites ; sinon, le superutilisateur (plus
precisement : les programmes avec la capacite CAP_SYS_MODULE) peut
uniquement supprimer des capacites de cet ensemble.
Sur un systeme standard, la limitation elimine toujours la capacite
CAP_SETPCAP. Pour supprimer cette restriction (attention, c'est
dangereux !), modifiez la definition de CAP_INIT_EFF_SET dans
include/linux/capability.h et recompilez le noyau.
La limitation de capacites systeme a ete ajoutee a Linux a partir du
noyau 2.2.11.
Limitation de capacit'es apr`es Linux 2.6.25
Depuis Linux 2.6.25, la limitation de capacit'es est un attribut par
thread (il n'y a plus desormais de limitation de capacites au niveau du
systeme).
La limitation est heritee du parent du thread au travers d'un fork(2)
et est preserve au travers d'un execve(2).
Un thread peut enlever des capacites de son ensemble de limitation de
capacites en utilisant l'operation PR_CAPBSET_DROP de prctl(2), a
condition qu'il possede la capacite CAP_SETPCAP. Une fois qu'une
capacite a ete supprimee de l'ensemble de limitation, elle ne peut etre
y etre remise. Un thread peut determiner si une capacite est dans son
ensemble de limitation de capacites en utilisant l'operation
PR_CAPBSET_READ de prctl(2).
La suppression de capacites dans l'ensemble de limitation des capacites
n'est prise en charge que si les capacites de fichiers sont compiles
dans le noyau (CONFIG_SECURITY_FILE_CAPABILITIES). Dans ce cas, le
processus init demarre avec ensemble plein a l'exception de
CAP_SETPCAP, parce que cette capacite a une autre signification quand
il n'y a pas de capacites de fichier.
Supprimer une capacite de la limitation de capacites ne la supprime pas
de l'ensemble herite d'un thread. Cependant il empeche de rajouter la
capacite dans l'ensemble herite du thread par la suite.
Effet des modifications d'UID sur les capacit'es
Afin de preserver la semantique traditionnelle pour les transitions
entre des UID nul et non nul, le noyau modifie les ensembles de
capacites d'un thread de la facon suivante lors de modifications des
UID reel, effectif, sauve et du systeme de fichiers (avec setuid(2),
setresuid(2) et compagnie) :
1. Si l'UID reel, effectif ou sauve etait egal a 0, et qu'a la suite de
la modification ils sont tous non nuls, toutes les capacites sont
supprimes des ensembles de capacites permises et effectives.
2. Si l'UID effectif etait nul et devient non nul, toutes les capacites
sont supprimees de l'ensemble effectif.
3. Si l'UID effectif est modifie d'une valeur non nulle a 0, l'ensemble
des capacites permises est copie dans l'ensemble des capacites
effectives.
4. Si le fsuid est modifie de 0 a une valeur non nulle (consultez
setfsuid(2)), les capacites suivantes sont supprimees de l'ensemble
effectif : CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH,
CAP_FOWNER, CAP_FSETID, CAP_LINUX_IMMUTABLE (depuis Linux 2.2.30),
CAP_MAC_OVERRIDE et CAP_MKNOD (depuis Linux 2.2.30). Si le fsuid
devient nul, chacune de ces capacites est activee dans l'ensemble
des capacites effectives si elle faisait partie de l'ensemble des
capacites permises.
Si un thread dont l'un des UID vaut 0 ne veut pas que son ensemble de
capacites permises soit vide lorsqu'il fixe tous ses UID a des valeurs
non nulles, il peut le faire avec l'operation PR_SET_KEEPCAPS de
l'appel systeme prctl(2).
Ajuster les ensembles de capacit'es par programmation
Un thread peut obtenir ou modifier ses ensembles de capacites en
utilisant les appels systeme capget(2) et capset(2). Cependant, il faut
leur preferer l'utilisation de cap_get_proc(3) et cap_set_proc(3),
toutes deux fournies par le paquet libcap. Les regles suivantes
gouvernent les modifications des ensembles de capacites d'un thread :
1. Si l'appelant n'a pas la capacite CAP_SETPCAP, le nouvel ensemble
des capacites heritables doit etre un sous-ensemble de l'union des
ensembles de capacites heritables et des capacites permises.
2. (Depuis le noyau 2.6.25) Le nouvel ensemble heritable doit etre un
sous-ensemble de l'ensemble heritable existant et de l'ensemble de
limitation de capacites.
3. Le nouvel ensemble des capacites permises doit etre un sous-ensemble
de l'ensemble des capacites permises existant (c'est-a-dire qu'il
n'est pas possible d'obtenir des capacites permises que le thread
n'a pas actuellement).
4. Le nouvel ensemble effectif doit etre un sous-ensemble du nouvel
ensemble des capacites permises.
Les attributs << securebits >> : configuration d'un environnement restreint
aux capacit'es de fichiers.
A partir du noyau 2.6.26, si les capacites de fichiers sont activees,
Linux implemente un ensemble d'attributs securebits par thread qui
peuvent etre utilises pour desactiver la gestion particuliere des
capacites pour l'UID 0 (root). Ces attributs sont les suivants :
SECBIT_KEEP_CAPS
Activer cet attribut permet a un thread qui a un UID (ou plus)
egal a 0 de conserver ses capacites quand il change ses UID et
que plus aucun n'est nul. Si cet attribut est desactive, alors
ces changements d'UID feront perdre au thread toutes ses
capacites. Cet attribut est toujours desactive lors d'un
execve(2). Cet attribut fournit la meme fonctionnalite que
l'ancienne operation PR_SET_KEEPCAPS de prctl(2)).
SECBIT_NO_SETUID_FIXUP
Activer cet attribut stoppe l'ajustement des ensembles de
capacites par le noyau lorsque les UID effectifs et d'acces aux
fichiers du thread passent d'une valeur nulle a une valeur non
nulle. (Consultez la sous-section Effet des modifications d'UID
sur les capacit'es.)
SECBIT_NOROOT
Si cet attribut est active, alors le noyau n'autorise pas les
capacites lorsqu'un programme Set-UID root est execute ou
lorsqu'un processus dont l'identifiant effectif ou reel est nul
appelle execve(2). (Consultez la sous-section Capacit'es et
ex'ecution de programmes par root.)
Chacun des attributs de base ci-dessus a un attribut compagnon de
verrouillage. L'activation d'un attribut de verrouillage est
irreversible et permet d'eviter toute modification ulterieure de
l'attribut de base. Les attributs de verrouillage sont :
SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED et
SECBIT_NOROOT_LOCKED.
Les attributs securebits peuvent etre modifies et recuperes en
utilisant les operations PR_SET_SECUREBITS et PR_GET_SECUREBITS de
prctl(2). La capacite CAP_SETPCAP est necessaire pour modifier ces
attributs.
Les attributs securebits sont herites par les processus fils. Lors d'un
execve(2), tous les attributs sont conserves, a l'exception de
SECURE_KEEP_CAPS qui est desactive.
Une application peut utiliser l'appel suivant pour se verrouiller
elle-meme, ainsi que tous ses descendant, dans un environnement ou la
seule facon d'obtenir des capacites est d'executer un programme avec
les capacites de fichiers correspondantes :
prctl(PR_SET_SECUREBITS,
SECBIT_KEEP_CAPS_LOCKED |
SECBIT_NO_SETUID_FIXUP |
SECBIT_NO_SETUID_FIXUP_LOCKED |
SECBIT_NOROOT |
SECBIT_NOROOT_LOCKED);
CONFORMIT'E
Il n'y a pas de veritable norme pour les capacites, mais
l'implementation Linux est base sur une interpretation de la norme
(retiree) POSIX.1e ; consultez
http://wt.xpilot.org/publications/posix.1e/.
NOTES
Depuis le noyau 2.5.27, les capacites sont optionnelles dans le noyau
et peuvent etre activees ou desactivees avec l'option de configuration
CONFIG_SECURITY_CAPABILITIES du noyau.
Le fichier /proc/PID/task/TID/status peut etre utilise pour voir les
ensembles de capacites d'un thread. Le fichier /proc/PID/status indique
les ensembles de capacites du thread principal d'un thread.
Le paquet libcap fournit un ensemble de routines pour ecrire et lire
les capacites d'un processus, de maniere plus simple et moins
susceptible de changer que l'interface fournie par capset(2) et
capget(2). Ce paquet fournit egalement les programmes setcap(8) et
getcap(8). Il peut etre trouve a l'adresse :
http://www.kernel.org/pub/linux/libs/security/linux-privs.
Avant le noyau 2.6.24, et depuis le noyau 2.6.24 si les capacites de
fichier ne sont pas activees, un thread avec la capacite CAP_SETPCAP
peut manipuler les capacites des autres threads. Cependant, ce n'est
possible qu'en theorie puisqu'aucun thread n'a la capacite CAP_SETPCAP
dans un des cas suivants :
* Dans l'implementation anterieure au noyau 2.6.25, l'ensemble de
limitation de capacites du systeme, /proc/sys/kernel/cap-bound,
masque toujours cette capacite et ceci ne peut pas etre change sans
modifier les sources du noyau et le recompiler.
* Si les capacites de fichiers sont desactivees dans l'implementation
actuelle, alors init demarre sans cette capacite dans l'ensemble de
limitation de capacite de son processus, et cet ensemble de
limitation de capacite est herite par tous les processus crees sur le
systeme.
VOIR AUSSI
capget(2), prctl(2), setfsuid(2), cap_clear(3), cap_copy_ext(3),
cap_from_text(3), cap_get_file(3), cap_get_proc(3), cap_init(3),
capgetp(3), capsetp(3), credentials(7), pthreads(7), getcap(8),
setcap(8)
include/linux/capability.h dans les sources du noyau
COLOPHON
Cette page fait partie de la publication 3.32 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent etre trouvees a l'adresse
<URL:http://www.kernel.org/doc/man-pages/>.
TRADUCTION
Depuis 2010, cette traduction est maintenue a l'aide de l'outil po4a
<URL:http://po4a.alioth.debian.org/> par l'equipe de traduction
francophone au sein du projet perkamon
<URL:http://perkamon.alioth.debian.org/>.
Christophe Blaess <URL:http://www.blaess.fr/christophe/> (1996-2003),
Alain Portal <URL:http://manpagesfr.free.fr/> (2003-2006). Julien
Cristau et l'equipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en ecrivant a
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir acces a la version anglaise de ce document
en utilisant la commande << man -L C <section> <page_de_man> >>.