millions de ligne de code, donc il est très vraisemblable qu'il y ait beaucoup de trous de sécurité dedans, qui va permettre a un attaquant de devenir root sur la machine. C'est pour cela que la sagesse populaire conseille de ne pas faire tourner X sur des serveurs critiques.
Oui et d'ailleurs pas seulement. À mon avis la sécurité n'est pas le seul enjeu dans le cas de « serveurs critiques », la stabilité est aussi très importante ; un gros processus root qui part en sucette peut faire beaucoup de dégâts (surtout un processus root qui en plus cause au matériel par devers le noyau). Ne pas sous estimer la profondeur des sagesses populaires ;)
Des techniques complémentaires comme SELinux permettaient, croyait-on de se prémunir contre certaines de ces attaques.
En fait je n'ai indiqué SELinux que pour lister les techniques courantes de confinement sous Linux (en parallèle avec securelevel(7) quoi, pour faire moins OpenBSD-centric ;).
Mais je pense (il faudrait creuser) que ce n'est pas la protection la plus visée par cette attaque (sauf si par exemple on compte sur lui pour déléguer de façon sécurisée des droits d'accès aux PIO iopl(3) a un utilisateur non privilégié qui ferait tourner x.org). Les « victimes de choix » qui viennent tout de suite à l'esprit seraient plutôt les protections visant à réduire les possibilité du superutilisateur root (sous Linux, type RSBAC ou LIDS).
La découverte de Duflot montre que dans certaines conditions, root peut faire encore plus de choses que ce qu'on pensait.
D'autre part, sous Linux précisément, il n'est pas certain que cette faille soit la méthode la plus simple pour ce type de détournement (mais ce n'est pas une raison pour accepter qu'il y en ai une de plus).
et permet aussi de sortir d'une machine virtuelle Xen.
Ah oui tu fait bien d'en parler: à priori (cf. l'interview) les machines "invitées" (guest, dom>0) de Xen n'ont pas le droit d'accéder aux PIO, donc non, ils ne peuvent dans ce cas précis utiliser cette fragilité pour sortir. Xen serait donc une bonne protection.
[^] # Re: petites corrections par rapport au journal
Posté par herodiade . En réponse à la dépêche Graves problèmes de sécurité dans x.org. Évalué à 7.
Oui et d'ailleurs pas seulement. À mon avis la sécurité n'est pas le seul enjeu dans le cas de « serveurs critiques », la stabilité est aussi très importante ; un gros processus root qui part en sucette peut faire beaucoup de dégâts (surtout un processus root qui en plus cause au matériel par devers le noyau). Ne pas sous estimer la profondeur des sagesses populaires ;)
Des techniques complémentaires comme SELinux permettaient, croyait-on de se prémunir contre certaines de ces attaques.
En fait je n'ai indiqué SELinux que pour lister les techniques courantes de confinement sous Linux (en parallèle avec securelevel(7) quoi, pour faire moins OpenBSD-centric ;).
Mais je pense (il faudrait creuser) que ce n'est pas la protection la plus visée par cette attaque (sauf si par exemple on compte sur lui pour déléguer de façon sécurisée des droits d'accès aux PIO iopl(3) a un utilisateur non privilégié qui ferait tourner x.org). Les « victimes de choix » qui viennent tout de suite à l'esprit seraient plutôt les protections visant à réduire les possibilité du superutilisateur root (sous Linux, type RSBAC ou LIDS).
La découverte de Duflot montre que dans certaines conditions, root peut faire encore plus de choses que ce qu'on pensait.
D'autre part, sous Linux précisément, il n'est pas certain que cette faille soit la méthode la plus simple pour ce type de détournement (mais ce n'est pas une raison pour accepter qu'il y en ai une de plus).
et permet aussi de sortir d'une machine virtuelle Xen.
Ah oui tu fait bien d'en parler: à priori (cf. l'interview) les machines "invitées" (guest, dom>0) de Xen n'ont pas le droit d'accéder aux PIO, donc non, ils ne peuvent dans ce cas précis utiliser cette fragilité pour sortir. Xen serait donc une bonne protection.