tuto3: Spelling
This commit is contained in:
parent
be453216f8
commit
6b6f37b4a3
19 changed files with 73 additions and 63 deletions
|
|
@ -9,9 +9,10 @@ processus :
|
|||
* les processus *non-privilégiés* : dont l'identifiant numérique de son
|
||||
utilisateur n'est pas 0.
|
||||
|
||||
Lors des différents tests de permission fait par le noyau, les processus
|
||||
Lors des différents tests de permission faits par le noyau, les processus
|
||||
privilégiés outrepassaient ces tests, tandis que les autres devaient passer les
|
||||
tests de l'effective UID, effective GID, et autres groupes supplémentaires...
|
||||
tests de l'*effective UID*, *effective GID*, et autres groupes
|
||||
supplémentaires...
|
||||
|
||||
Dans les années 90, ce système s'est rélévé être un peu trop basique et
|
||||
conduisait régulièrement à des abus, au moyen de vulnérabilités trouvées dans
|
||||
|
|
@ -37,7 +38,7 @@ passe. Pourtant bien que l'on puisse lire le fichier `/etc/passwd`, seul `root`
|
|||
peut y apporter des modifications (il en est de même pour `/etc/shadow` qui
|
||||
contient les hashs des mots de passe).
|
||||
|
||||
C'est ainsi qu'est apparu le `suid-bit` parmi les modes des fichiers. Lorsque
|
||||
C'est ainsi qu'est apparu le `suid-bit` parmi les modes de fichiers. Lorsque
|
||||
ce bit est défini sur un binaire exécutable, au moment de l'exécution, le
|
||||
contexte passe à celui du propriétaire du fichier (`root` si le propriétaire
|
||||
est `root`, mais cela fonctionne quelque soit le propriétaire du fichier : on
|
||||
|
|
@ -68,7 +69,7 @@ d'écrire sur une interface réseau.
|
|||
### Et ainsi les privilèges furent séparés
|
||||
|
||||
Depuis Linux 2.2 (en 1998), les différentes actions réclamant des privilèges
|
||||
sont regroupés en catégories que l'on appelle *capabilities*. Chacune donne
|
||||
sont regroupées en catégories que l'on appelle *capabilities*. Chacune donne
|
||||
accès à un certain nombre d'actions, on trouve notamment :
|
||||
|
||||
* `CAP_CHOWN` : permet de modifier le propriétaire d'un fichier de manière
|
||||
|
|
@ -83,7 +84,7 @@ accès à un certain nombre d'actions, on trouve notamment :
|
|||
|
||||
Petit point historique, Linux n'est pas à l'origine du concept de
|
||||
*capabilities*, il s'agit au départ de la norme POSIX 1003.1e, mais celle-ci
|
||||
s'est éteinte auprès le 17e *draft*. Il devait y être standardisé de nombreux
|
||||
s'est éteinte après le 17\textsuperscript{ème} *draft*. Il devait y être standardisé de nombreux
|
||||
composants améliorant la sécurité des systèmes POSIX, notamment les
|
||||
*capabilities* POSIX, les *ACL POSIX*, ...
|
||||
|
||||
|
|
@ -142,7 +143,7 @@ Tout d'abord, il faut noter que chaque *thread* dispose de 5 ensembles de
|
|||
*capabilities*. Ceux-ci sont utilisés de la façon suivante :
|
||||
|
||||
- ***bounding*** (B) : c'est l'ensemble limitant des *capabilities* qui pourront
|
||||
faire l'objet d'un calcul lors des prochaines exécutions. Quelques soit les
|
||||
faire l'objet d'un calcul lors des prochaines exécutions. Quelques soient les
|
||||
*capabilities* que peut nous faire gagner une exécution, si la *capability*
|
||||
ne se trouve pas dans le *bounding set*, elle ne sera pas considérée et il
|
||||
sera impossible de l'obtenir. L'option `--cap-drop` de Docker modifie cet
|
||||
|
|
@ -328,7 +329,7 @@ struct vfs_cap_data {
|
|||
</div>
|
||||
|
||||
La valeur `magic` contient la version sur 1 octet, puis 3 octets sont réservés
|
||||
pour des flags. Actuellement un seul flag existe, il s'agit de
|
||||
pour des *flags*. Actuellement un seul *flag* existe, il s'agit de
|
||||
`VFS_CAP_FLAGS_EFFECTIVE` qui détermine si la liste effective de *capabilities*
|
||||
du programme doit être remplie avec les *capabilities* *permitted* si elle doit
|
||||
rester vide (auquel cas ce sera au programme de s'ajouter les *capabilities* au
|
||||
|
|
@ -391,7 +392,7 @@ naissance au nouveau processus et $p′$ le nouveau processus.\
|
|||
On remarque que sans les *ambients capabilities*, on perd systématiquement les
|
||||
*capabilities* dont on disposait avant l'`execve(2)`, car $f_I$ n'est que très
|
||||
rarement défini sur un exécutable. Dans le cas général, on récupère donc soit
|
||||
$f_P$, soit $p_A$ (les deux étant exclusif : si $f_P$ est défini, $p′_A$ est
|
||||
$f_P$, soit $p_A$ (les deux étant exclusifs : si $f_P$ est défini, $p′_A$ est
|
||||
vide).
|
||||
|
||||
Bien entendu, lorsque l'on se trouve dans le contexte d'exécution de `root` (ou
|
||||
|
|
@ -436,7 +437,7 @@ par l'ensemble *bounding*.
|
|||
|
||||
On utilise les appels système `capget(2)` et `capset(2)` pour respectivement
|
||||
connaître les *capabilities* actuelles de notre fil d'exécution et pour les
|
||||
écraser. Ces appels systèmes utilisent une structure d'en-tête et une structure
|
||||
écraser. Ces appels système utilisent une structure d'en-tête et une structure
|
||||
de données, qui sont définies dans `linux/capability.h` :
|
||||
|
||||
<div lang="en-US">
|
||||
|
|
@ -479,9 +480,9 @@ structures `vfs_cap_data` et `vfs_ns_cap_data` : il n'y a pas de notion de
|
|||
*namespace* ici.
|
||||
|
||||
Il y a eu un couac dans les en-têtes distribués avec Linux 2.6.25, causant des
|
||||
*buffers overflow* dans les applications qui n'avaient pas prévues de gérer les
|
||||
*buffers overflow* dans les applications qui n'avaient pas prévu de gérer les
|
||||
versions. Cela a été corrigé dans la version 2.6.26 : un avertissement est
|
||||
consigné dans les journaux systèmes en cas d'utilisation malheureuse de la
|
||||
consigné dans les journaux système en cas d'utilisation malheureuse de la
|
||||
version 2.
|
||||
|
||||
:::::
|
||||
|
|
@ -515,7 +516,7 @@ Le second paramètre attendu est l'une des constantes représentant une
|
|||
*capability*.\
|
||||
|
||||
Avec `PR_CAPBSET_READ`, `prctl(2)` retournera 0 si la *capability* ne fait pas
|
||||
parti de l'ensemble *bounding*, ou 1 si elle est bien présente.
|
||||
partie de l'ensemble *bounding*, ou 1 si elle est bien présente.
|
||||
|
||||
Avec `PR_CAPBSET_DROP`, `prctl(2)` retirera la *capability* passée en argument
|
||||
de l'ensemble *bounding*. Une fois cette action effectuée, il est impossible de
|
||||
|
|
@ -527,7 +528,7 @@ Dans la pratique, on préférera utiliser `cap_get_bound(3)` et
|
|||
:::::
|
||||
|
||||
Enfin, le *thread* peut aussi modifier à sa guise l'ensemble *ambient*, à
|
||||
condition que les *capabilities* ajoutées soient dans les ensemble *permitted*
|
||||
condition que les *capabilities* ajoutées soient dans les ensembles *permitted*
|
||||
et *inheritable*.
|
||||
|
||||
::::: {.code}
|
||||
|
|
@ -541,7 +542,7 @@ préciser l'action que l'on veut réaliser :\
|
|||
- `PR_CAP_AMBIENT_LOWER` : retire la *capability* précisée comme troisième
|
||||
paramètre ;
|
||||
- `PR_CAP_AMBIENT_IS_SET` : retourne 1 si la *capability* précisée comme
|
||||
troisième paramètre fait parti de l'ensemble *ambient*, sinon retourne 0 ;
|
||||
troisième paramètre fait partie de l'ensemble *ambient*, sinon retourne 0 ;
|
||||
- `PR_CAP_AMBIENT_CLEAR_ALL` : vide l'ensemble *ambient*.
|
||||
|
||||
:::::
|
||||
|
|
@ -682,7 +683,7 @@ amont.
|
|||
|
||||
Je vous recommande la lecture des *man* suivants :
|
||||
|
||||
* `capabilities(7)` : énumérant tous les capabilities, leur utilisation, etc. ;
|
||||
* `capabilities(7)` : énumérant tous les *capabilities*, leur utilisation, etc. ;
|
||||
* `xattrs(7)` : à propos des attributs étendus.
|
||||
|
||||
Et de ces quelques articles :
|
||||
|
|
@ -697,5 +698,5 @@ Et de ces quelques articles :
|
|||
<https://forums.grsecurity.net/viewtopic.php?f=7&t=2522#p10271>
|
||||
* [Linux Capabilities on HackTricks](https://book.hacktricks.xyz/linux-unix/privilege-escalation/linux-capabilities) :\
|
||||
<https://book.hacktricks.xyz/linux-unix/privilege-escalation/linux-capabilities>
|
||||
- [POSIZ Access Control Lists on Linux](https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html) :\
|
||||
- [POSIX Access Control Lists on Linux](https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html) :\
|
||||
<https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue