En réalité, et contrairement à ce qu'on pourrai croire, root de devrait pas avoir *tout les droits* sur les Unix modernes. En particulier, il n'est pas censé pouvoir lire/modifier arbitrairement toutes les structures de données du noyau.
Voilà quelques exemples simples qui montrent que root (ou disons, un root illégitime, autre que la personne qui a choisi les options au boot) ne devrait pas pouvoir faire, sans quoi le problème excède largement le fait d'avoir une machine compromise:
- Accéder à la clef, au mot de passe de la clef ou au message déchiffré d'un utilisateur qui utilise GPG sur le système.
- Idem pour les transaction SSL en cours (root ne devrait pas avoir accès à mon numéro de carte bleu lorsque je consulte le site de ma banque).
- S'évader d'une cage chroot() dans lequel ce processus root est confiné (eg. daemon chrooté qui s'est fait pwned) ou autre protection de ce type (systrace, jail, ...).
- Accéder au hardware, lui injecter cochonneries et le griller (ou accéder aux fonctionnalités de mise à jour du bios depuis l'OS etc).
- Avoir la possibilité de modifier la visibilité de certains infos sur l'état de la machine (eg. cas d'une rootkit qui masque certains processus sur une machine compromise). Si on est pwned, pouvoir s'en apercevoir (ou pas), ça fait une grosse différence.
- S'évader d'une pseudo "machine virtuelle" (penser à l'hébergement mutualisé virtuel) telle que jail sous FreeBSD ou uml sous Linux ou qemu/vmware ...
etc.
Étant donné la sophistication des Unix modernes, pour pouvoir s'assurer de ça, on a besoin de polices qui empêchent certaines actions (comme le chargement de modules noyau, sous linux). Donc ça rajoute une série de protections contre ce type de droits roots -eg.empêcher le chargement de modules du noyau si telle option a été passée au boot- (SELinux, securelevel, Capabilities etc.), qui elles mêmes ne doivent pas être modifiables/désactivables par root.
[^] # Re: Risque réel?
Posté par herodiade . En réponse au journal Graves problèmes de sécurité dans x.org. Évalué à 0.
Voilà quelques exemples simples qui montrent que root (ou disons, un root illégitime, autre que la personne qui a choisi les options au boot) ne devrait pas pouvoir faire, sans quoi le problème excède largement le fait d'avoir une machine compromise:
- Accéder à la clef, au mot de passe de la clef ou au message déchiffré d'un utilisateur qui utilise GPG sur le système.
- Idem pour les transaction SSL en cours (root ne devrait pas avoir accès à mon numéro de carte bleu lorsque je consulte le site de ma banque).
- S'évader d'une cage chroot() dans lequel ce processus root est confiné (eg. daemon chrooté qui s'est fait pwned) ou autre protection de ce type (systrace, jail, ...).
- Accéder au hardware, lui injecter cochonneries et le griller (ou accéder aux fonctionnalités de mise à jour du bios depuis l'OS etc).
- Avoir la possibilité de modifier la visibilité de certains infos sur l'état de la machine (eg. cas d'une rootkit qui masque certains processus sur une machine compromise). Si on est pwned, pouvoir s'en apercevoir (ou pas), ça fait une grosse différence.
- S'évader d'une pseudo "machine virtuelle" (penser à l'hébergement mutualisé virtuel) telle que jail sous FreeBSD ou uml sous Linux ou qemu/vmware ...
etc.
Étant donné la sophistication des Unix modernes, pour pouvoir s'assurer de ça, on a besoin de polices qui empêchent certaines actions (comme le chargement de modules noyau, sous linux). Donc ça rajoute une série de protections contre ce type de droits roots -eg.empêcher le chargement de modules du noyau si telle option a été passée au boot- (SELinux, securelevel, Capabilities etc.), qui elles mêmes ne doivent pas être modifiables/désactivables par root.