Je ne me suis pas senti assez à l'aise pour faire une dépêche (le sujet est ardu et m'échappe largement).
Mais bon, histoire de détourner les débats du journal vers ici ;), je vais essayer de faire une mini synthèse sur un point qui a été discuté dans le journal, et qui semblait pas naturel pour certains: sur les Unix modernes, le super utilisateur root n'est pas toujours censé avoir tout les droits.
En particulier, il est généralement admis qu'il est préférable que les utilisateurs (dont root) n'accèdent pas directement au matériel: on préfère qu'ils s'adressent au noyau (qui peut ensuite décider de dialoguer avec le matériel) via une interface bien définie (un appel système). Mais pour des raisons de commodité et de portabilité notamment, x.org et XFree86 dérogent à ce principe et accèdent directement au matériel. Le noyau doit donc ménager une ouverture pour permettre ce genre d'opérations.
Par ailleurs les Unix libres intègrent parfois des protections permettant de limiter les dégâts que peut causer (volontairement ou pas) les programmes ayant des droits root (acquis et utilisés légitimement ou pas). Par exemple les systèmes BSD incluent généralement un mécanisme appelé securelevel(7) qui peut permettre -entre autres- d'empêcher totalement (même pour root) la modification des fichiers ayant le drapeau "immuable", ou d'écrire sur /dev/mem, ou de modifier le paramétrage du pare feu, etc. En théorie, seul l'administrateur système (la personne physique, à ne pas confondre avec le concept informatique de "root") peut désactiver ces mécanismes lorsqu'il a accès à la console physique de la machine, et avant que le système d'exploitation ne passe en mode multi utilisateur. Le noyau Linux possède lui aussi des mécanisme de confinement (comme SELinux, GRSecurity ou encore RSBAC).
Mais là où les choses deviennent manifestement ennuyeuses, c'est que l'ouverture noyau donnant accès au matériel permet aussi de manipuler certaines fonctionnalités dangereuses des processeurs i386, lesquelles permettent un accès total à l'espace mémoire (en fait aux 4 premiers Go) à l'insu du noyau. C'est suffisant pour permettre à un logiciel ayant les droits root de détourner toutes les protections noyau évoquées ci-dessus.
Appréciation personnelle (et sans rapport direct avec la dépêche): x.org est un logiciel énorme (plusieurs million de lignes de code) qui tourne presque totalement avec les droits root. En partie du fait de ce problème de conception, et en partie parce que les développeurs n'ont pas choisi d'intégrer certains mécanismes pour réduire la proportion de code tournant en root (d'où ma remarque amère sur la non intégration des patches d'OpenBSD. Bref, on est assis sur une bombe). Et les récentes failles d'x.org (CVE-2006-1526 et CVE-2006-0745) témoignent des problèmes qu'engendre un si gros programme suid root...
[^] # 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é à 10.
Mais bon, histoire de détourner les débats du journal vers ici ;), je vais essayer de faire une mini synthèse sur un point qui a été discuté dans le journal, et qui semblait pas naturel pour certains: sur les Unix modernes, le super utilisateur root n'est pas toujours censé avoir tout les droits.
En particulier, il est généralement admis qu'il est préférable que les utilisateurs (dont root) n'accèdent pas directement au matériel: on préfère qu'ils s'adressent au noyau (qui peut ensuite décider de dialoguer avec le matériel) via une interface bien définie (un appel système). Mais pour des raisons de commodité et de portabilité notamment, x.org et XFree86 dérogent à ce principe et accèdent directement au matériel. Le noyau doit donc ménager une ouverture pour permettre ce genre d'opérations.
Par ailleurs les Unix libres intègrent parfois des protections permettant de limiter les dégâts que peut causer (volontairement ou pas) les programmes ayant des droits root (acquis et utilisés légitimement ou pas). Par exemple les systèmes BSD incluent généralement un mécanisme appelé securelevel(7) qui peut permettre -entre autres- d'empêcher totalement (même pour root) la modification des fichiers ayant le drapeau "immuable", ou d'écrire sur /dev/mem, ou de modifier le paramétrage du pare feu, etc. En théorie, seul l'administrateur système (la personne physique, à ne pas confondre avec le concept informatique de "root") peut désactiver ces mécanismes lorsqu'il a accès à la console physique de la machine, et avant que le système d'exploitation ne passe en mode multi utilisateur. Le noyau Linux possède lui aussi des mécanisme de confinement (comme SELinux, GRSecurity ou encore RSBAC).
Mais là où les choses deviennent manifestement ennuyeuses, c'est que l'ouverture noyau donnant accès au matériel permet aussi de manipuler certaines fonctionnalités dangereuses des processeurs i386, lesquelles permettent un accès total à l'espace mémoire (en fait aux 4 premiers Go) à l'insu du noyau. C'est suffisant pour permettre à un logiciel ayant les droits root de détourner toutes les protections noyau évoquées ci-dessus.
Appréciation personnelle (et sans rapport direct avec la dépêche): x.org est un logiciel énorme (plusieurs million de lignes de code) qui tourne presque totalement avec les droits root. En partie du fait de ce problème de conception, et en partie parce que les développeurs n'ont pas choisi d'intégrer certains mécanismes pour réduire la proportion de code tournant en root (d'où ma remarque amère sur la non intégration des patches d'OpenBSD. Bref, on est assis sur une bombe). Et les récentes failles d'x.org (CVE-2006-1526 et CVE-2006-0745) témoignent des problèmes qu'engendre un si gros programme suid root...
Voilou.
Un peu de doc complémentaire:
Les récentes failles sécu d'x.org:
http://wiki.x.org/wiki/SecurityPage
L'implémentation des securelevel(7) sous OpenBSD:
http://www.openbsd.org/cgi-bin/man.cgi?query=securelevel
SELinux:
http://en.wikipedia.org/wiki/Security-Enhanced_Linux