En fait, l'article se focalisait plus sur les différents niveau de sécurité qu'il y a dans un OpenBSD (d'apres ce que j'ai compris).
Le fait est qu'une fois qu'on verrouille un niveau de sécurité dans OpenBSD, on ne peut plus revenir en arrière. Le document explique que des systèmes matériels permettent de passer outre, et peuvent permettre d'exécuter du code en dehors de toute contrainte au niveau de l'OS (même en root, tu ne peux pas te créer un pointeur vers n'importe ou dans la mémoire, sauf à passer par un mechanisme spécifique de l'OS, que celui-ci contrôle et met à ta disposition gracieusement : /dev/mem).
Le document pointe surtout les failles qui sont accessibles dans des environnements ou même root n'est pas dieu sur la machine.
Forcement, un bureau sous linux sans protection particulière n'est pas concerné par cette attaque puisque le simple fait d'être root ouvre les portes de n'importe quoi. Par contre, un environnement sécurisé pour root (chroot comme dit plus haut, ou encore les niveaux de sécurité introduit par OpenBSD, et sans doute les ajouts de SELinux que je ne connais pas, et plein d'autres trucs) est particulièrement vulnérable à ce genre d'attaque.
Maintenant, si on parle de X, c'est parce que c'est le comportement actuel de X qui oblige les devs du noyau à laisser des trous de sécurité comme ça, pour pleins de raisons d'ailleurs.
N'hésitez pas à me corriger si je dis des choses fausses :-)
[^] # Re: Théo : one point - X.Org : (void *)NULL
Posté par Emmanuel C . En réponse au journal Graves problèmes de sécurité dans x.org. Évalué à 4.
Le fait est qu'une fois qu'on verrouille un niveau de sécurité dans OpenBSD, on ne peut plus revenir en arrière. Le document explique que des systèmes matériels permettent de passer outre, et peuvent permettre d'exécuter du code en dehors de toute contrainte au niveau de l'OS (même en root, tu ne peux pas te créer un pointeur vers n'importe ou dans la mémoire, sauf à passer par un mechanisme spécifique de l'OS, que celui-ci contrôle et met à ta disposition gracieusement : /dev/mem).
Le document pointe surtout les failles qui sont accessibles dans des environnements ou même root n'est pas dieu sur la machine.
Forcement, un bureau sous linux sans protection particulière n'est pas concerné par cette attaque puisque le simple fait d'être root ouvre les portes de n'importe quoi. Par contre, un environnement sécurisé pour root (chroot comme dit plus haut, ou encore les niveaux de sécurité introduit par OpenBSD, et sans doute les ajouts de SELinux que je ne connais pas, et plein d'autres trucs) est particulièrement vulnérable à ce genre d'attaque.
Maintenant, si on parle de X, c'est parce que c'est le comportement actuel de X qui oblige les devs du noyau à laisser des trous de sécurité comme ça, pour pleins de raisons d'ailleurs.
N'hésitez pas à me corriger si je dis des choses fausses :-)