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
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

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
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
source