J'aimerais avoir le compte root en toute sécurité même si mon utilisateur non privilégié est compromis.
Sur Ubuntu, vous ne pouvez utiliser sudo que pour des "raisons de sécurité" par défaut. Cependant, je ne suis pas sûr que ce soit plus sûr que d'utiliser simplement la connexion sur une console en mode texte. Il y a trop de choses qui peuvent mal tourner si un attaquant peut exécuter du code en tant qu'utilisateur normal. Par exemple, ajouter des alias, ajouter des éléments à mon PATH, définir des enregistreurs de frappe LD_PRELOAD et X11, pour n'en citer que quelques-uns. Le seul avantage que je vois est le délai d'attente, donc je n'oublie jamais de me déconnecter.
J'ai les mêmes doutes sur su mais il n'a même pas de limite de temps. Certaines opérations (en particulier la redirection d'E/S) sont plus pratiques avec su, mais du point de vue de la sécurité, cela semble être pire.
La connexion sur une console en mode texte semble être la plus sûre. Comme il est lancé par init si un attaquant peut contrôler PATH ou LD_PRELOAD il est déjà root. Les événements de pression de touche ne peuvent pas être interceptés par les programmes exécutés sur X. Je ne sais pas si les programmes exécutés sur X peuvent intercepter [ctrl]+[alt]+[f1] (et ouvrir une fenêtre plein écran qui ressemble à une console) ou il est sûr comme [ctrl]+[alt]+[del] sous Windows. En plus de cela, le seul problème que je vois est le manque de délai d'attente.
Alors est-ce que je manque quelque chose? Pourquoi les gars d'Ubuntu ont-ils décidé de n'autoriser que sudo ? Que puis-je faire pour améliorer la sécurité de l'une des méthodes ?
Qu'en est-il de SSH ? Traditionnellement, root ne peut pas se connecter via SSH. Mais en utilisant la logique ci-dessus, ce ne serait pas la chose la plus sûre à faire :
- autoriser root via SSH
- passer en mode texte
- connectez-vous en tant que root
- ssh vers l'autre ordinateur
- se connecter en tant qu'utilisateur root ?
Réponse acceptée :
La sécurité consiste toujours à faire des compromis. Tout comme le serveur proverbial qui est dans un coffre-fort, débranché, au fond de l'océan, root serait le plus sécurisé s'il n'y avait aucun moyen d'y accéder.
Les attaques LD_PRELOAD et PATH comme celles que vous décrivez supposent qu'un attaquant a déjà accès à votre compte, ou du moins à vos fichiers de points. Sudo ne protège pas du tout contre cela - s'ils ont votre mot de passe, après tout, pas besoin d'essayer de vous tromper pour plus tard... ils peuvent simplement utiliser sudo maintenant .
Il est important de considérer ce pour quoi Sudo a été conçu à l'origine :la délégation de spécifique commandes (comme celles pour gérer les imprimantes) aux "sous-administrateurs" (peut-être des étudiants diplômés dans un laboratoire) sans donner complètement racine. Utiliser sudo pour tout faire est l'utilisation la plus courante que je vois maintenant, mais ce n'est pas nécessairement le problème que le programme était censé résoudre (d'où la syntaxe ridiculement compliquée du fichier de configuration).
Mais, sudo-for-unrestricted-root fait résoudre un autre problème de sécurité :la gérabilité des mots de passe root. Dans de nombreuses organisations, ceux-ci ont tendance à être distribués comme des bonbons, écrits sur des tableaux blancs et laissés tels quels pour toujours. Cela laisse une grande vulnérabilité, car la révocation ou la modification de l'accès devient un grand nombre de production. Même garder une trace de quelle machine a quel mot de passe est un défi - sans parler de savoir qui sait lequel.
Connexe :Qu'est-ce que j'obtiendrais si sudo était un programme destructeur du noyau ?N'oubliez pas que la plupart des « cybercrimes » viennent de l'intérieur. Avec la situation de mot de passe root décrite, il est difficile de savoir qui a fait quoi - quelque chose de sudo avec la journalisation à distance se débrouille assez bien.
Sur votre système domestique, je pense que c'est vraiment plus une question de commodité de ne pas avoir à se souvenir de deux mots de passe. Il est probable que beaucoup de gens les configuraient simplement pour qu'ils soient identiques - ou pire, les configuraient initialement pour qu'ils soient identiques, puis les laissaient se désynchroniser, laissant le mot de passe root pourrir.
Utiliser des mots de passe du tout car SSH est dangereux, car des démons ssh reniflant les mots de passe sont mis en place dans quelque chose comme 90% des compromis système du monde réel que j'ai vus. Il est préférable d'utiliser des clés SSH, et cela peut également être un système utilisable pour l'accès root à distance.
Mais le problème est maintenant que vous êtes passé de la gestion des mots de passe à la gestion des clés, et les clés ssh ne sont pas vraiment très gérables. Il n'y a aucun moyen de restreindre les copies, et si quelqu'un en fait une copie, il a toutes les tentatives qu'il veut pour forcer brutalement la phrase secrète. Vous pouvez établir une politique stipulant que les clés doivent être stockées sur des périphériques amovibles et montées uniquement en cas de besoin, mais il n'y a aucun moyen de faire respecter cela - et maintenant vous avez introduit la possibilité qu'un périphérique amovible soit perdu ou volé.
La sécurité la plus élevée sera assurée par des clés à usage unique ou des jetons cryptographiques basés sur le temps/compteur. Celles-ci peuvent être effectuées dans un logiciel, mais le matériel inviolable est encore meilleur. Dans le monde open source, il y a WiKiD, YubiKey ou LinOTP, et bien sûr il y a aussi le poids lourd propriétaire RSA SecurID. Si vous faites partie d'une organisation de taille moyenne à grande, ou même d'une petite entreprise soucieuse de la sécurité, je vous recommande fortement d'examiner l'une de ces approches pour l'accès administratif.
C'est probablement exagéré pour la maison, cependant, où vous n'avez pas vraiment de soucis de gestion - tant que vous suivez des pratiques de sécurité raisonnables.