Comme Ubuntu désactive le compte root par défaut, pourquoi ne pas désactiver également l'accès au shell root?

12

Les valeurs par défaut actuelles du compte root dans /etc/passwdest root:x:0:0:root:/root:/bin/bash.

Pourquoi ne pas le régler sur root:x:0:0:root:/root:/usr/sbin/nologin?

command-line security root loongyh
la source
7
Pour que vous puissiez faire sudo -i?
AlexP
12
"désactive le compte root" est un peu une description vague: ce qu'il désactive vraiment, c'est l' authentification par mot de passe du compte root
steeldriver
1
@AlexP en effet je viens de le tester, sudo -i ne fonctionne pas avec le jeu de racine sur / usr / sbin / nologin.
loongyh

Réponses:

19

Si tel était le cas, vous ne pourriez exécuter des commandes qu'avec sudoune à la fois, mais vous ne pourriez pas démarrer un shell racine. Un shell root est pratique dans de nombreux cas, par exemple si vous prévoyez d'exécuter plusieurs commandes en tant que root dans une rangée.

Plus précisément, vous ne pouviez pas courir sudo -i, comme l'a noté AlexP. De man sudo:

-i, --login    Run the shell specified by the target user's password database entry as a login shell.
Alberto Santini
la source
7
Ça ne sudo /bin/bashmarche pas pour ça?
Federico Poloni
5
@FedericoPoloni qui serait plus comme sudo -sje pense (un shell root, mais pas un shell de connexion root ). C'est un bon point cependant - et en fait, sudo -scela semble fonctionner même lorsque la coque de la racine est/usr/sbin/nologin
steeldriver
1
Vous pouvez désactiver -i, -s, /bin/bashet ainsi de suite tout en permettant une liste blanche des commandes, consultez la documentation du fichier sudoers. C'est si fin qu'il est par exemple possible d'autoriser les utilisateurs à s'exécuter en /etc/init.d/someservice restarttant que root sans leur permettre de s'exécuter /etc/init.d/someservice stop. Mais la valeur par défaut d'ubuntu est de ne définir aucun mot de passe rootet de permettre aux utilisateurs administratifs de tout faire avec sudo. La justification est probablement a) plus d'un utilisateur administrateur et b) L'utilisateur administrateur n'a pas besoin de se souvenir d'un deuxième mot de passe pour le compte root.
allo
8

Outre la réponse sudo d'Alberto Santini, il y a une autre (bien meilleure) réponse. Si le shell de root est défini sur quelque chose qui n'est pas un shell, le démarrage d'un utilisateur unique ne fonctionne pas. Il y a une récupération suloginpour des choses comme un shell non existant ou un shell complètement cassé, mais cela ne fonctionnera pas si le shell semble être un shell valide mais n'est pas réellement un shell.

Vous pouvez toujours sudoobtenir directement un shell en spécifiant le shell pour sudoqu'il ne soit même pas une bonne protection.

Joshua
la source