En fait l'objectif des protections comme les securelevels n'est pas de déporter les droits sur un super-super utilisateur.
L'idée est plutôt de restreindre l'éxecution de certains privilèges à chaud (au runtime, ou plus précisément, lorsque le kernel tourne en mode multiutilisateur ).
Autrement dit, on considère qu'on a confiance dans le gars qui est derrière la console physique. Celui qui, par exemple, passe les paramètres activant les sécurisations en question au noyau lors du boot.
Exemple concret: l'admin boote son OpenBSD en init 1 (donc non multiuser, non réseau), active le niveau fort de restrictions (en écrivant "securelevel=2" dans le fichier /etc/rc.securelevel). Il met aussi un machdep.allowaperture=0 dans /etc/sysctl.conf vu que TdR vient de le lui recommander ;). Puis il pose le flag "immutable" sur certains fichiers cruciaux (au hasard: /etc/rc.securelevel, le kernel /bsd, /sbin/init, et le firewall /etc/pf.conf et /sbin/pfctl). Ensuite il passe le système en mode multiutilisateur. Et bien dès ce moment, root ne peut plus désactiver les protections du securelevel, ni rien modifier qui permette que ça soit désactiver au prochain reboot, etc. Sauf s'il a accès physique à la console, ou si on peut bypasser le noyau comme dans le cas qui nous intéresse.
Ce n'est donc pas une "remise en cause" de root. En une phrase: le noyau/arch idéal ne devrait pas permettre à un root "distant", lorsque le système est en mode mutlisateur/en prod, de se tirer une balle dans la tête, de griller son hardware, ou de voler des données les plus confidentielles de ses utilisateurs.
[^] # Re: Euh ...
Posté par herodiade . En réponse au journal Graves problèmes de sécurité dans x.org. Évalué à 4.
L'idée est plutôt de restreindre l'éxecution de certains privilèges à chaud (au runtime, ou plus précisément, lorsque le kernel tourne en mode multiutilisateur ).
Autrement dit, on considère qu'on a confiance dans le gars qui est derrière la console physique. Celui qui, par exemple, passe les paramètres activant les sécurisations en question au noyau lors du boot.
Exemple concret: l'admin boote son OpenBSD en init 1 (donc non multiuser, non réseau), active le niveau fort de restrictions (en écrivant "securelevel=2" dans le fichier /etc/rc.securelevel). Il met aussi un machdep.allowaperture=0 dans /etc/sysctl.conf vu que TdR vient de le lui recommander ;). Puis il pose le flag "immutable" sur certains fichiers cruciaux (au hasard: /etc/rc.securelevel, le kernel /bsd, /sbin/init, et le firewall /etc/pf.conf et /sbin/pfctl). Ensuite il passe le système en mode multiutilisateur. Et bien dès ce moment, root ne peut plus désactiver les protections du securelevel, ni rien modifier qui permette que ça soit désactiver au prochain reboot, etc. Sauf s'il a accès physique à la console, ou si on peut bypasser le noyau comme dans le cas qui nous intéresse.
Ce n'est donc pas une "remise en cause" de root. En une phrase: le noyau/arch idéal ne devrait pas permettre à un root "distant", lorsque le système est en mode mutlisateur/en prod, de se tirer une balle dans la tête, de griller son hardware, ou de voler des données les plus confidentielles de ses utilisateurs.