GNU/Linux >> Tutoriels Linux >  >> Linux

Pourquoi la sécurité racine est-elle appliquée alors que $HOME n'est généralement pas protégé ?

Je vais être en désaccord avec les réponses qui disent que l'âge du modèle de sécurité Unix ou l'environnement dans lequel il a été développé sont en cause. Je ne pense pas que ce soit le cas car il existe des mécanismes en place pour gérer cela.

Le système d'autorisations racine a du sens, mais sur les systèmes de bureau, on a l'impression qu'il protège les mauvaises données.

Les autorisations du superutilisateur existent pour protéger le système de ses utilisateurs. Les autorisations sur les comptes d'utilisateurs sont là pour protéger le compte des autres comptes non root.

En exécutant un programme, vous lui donnez la permission de faire des choses avec votre UID. Étant donné que votre UID a un accès complet à votre répertoire personnel, vous avez transitivement donné au programme le même accès. Tout comme le superutilisateur a le droit d'apporter des modifications aux fichiers système qui doivent être protégés contre les comportements malveillants (mots de passe, configuration, fichiers binaires), vous pouvez avoir des données dans votre répertoire personnel qui nécessitent le même type de protection.

Le principe du moindre privilège stipule que vous ne devez pas donner plus d'accès que ce qui est absolument nécessaire. Le processus de décision pour l'exécution de tout programme doit être le même en ce qui concerne vos fichiers qu'il l'est pour les fichiers système. Si vous ne donnez pas un morceau de code auquel vous ne faites pas confiance pour une utilisation illimitée du compte superutilisateur dans l'intérêt de la protection du système, il ne devrait pas être utilisé sans restriction de votre compte dans l'intérêt de la protection de vos données.

N'y a-t-il aucun moyen d'empêcher le code malveillant de se produire dans $HOME ? Et pourquoi personne ne s'en soucie ?

Unix n'offre pas d'autorisations aussi granulaires pour la même raison qu'il n'y a pas de protection de lame autour de la commande rm :les autorisations ne sont pas là pour protéger les utilisateurs d'eux-mêmes.

Le moyen d'empêcher le code malveillant d'endommager les fichiers de votre répertoire personnel est de ne pas l'exécuter à l'aide de votre compte. Créez un utilisateur distinct qui ne dispose d'aucune autorisation spéciale et exécutez le code sous cet UID jusqu'à ce que vous ayez déterminé si vous pouvez lui faire confiance ou non.

Il existe d'autres moyens de le faire, comme les prisons chrootées, mais les mettre en place demande plus de travail, et y échapper n'est plus le défi qu'il était autrefois.


Parce que le modèle de sécurité basé sur UNIX a 50 ans.

UNIX est à la base des systèmes d'exploitation les plus répandus, et même la grande exception Windows en a été influencé plus qu'il n'y paraît. Cela remonte à une époque où les ordinateurs étaient de grosses machines coûteuses et lentes exclusivement utilisées par des spécialistes des arcanes.

À cette époque, les utilisateurs ne disposaient tout simplement pas de vastes collections de données personnelles sur tout ordinateur, pas leur serveur universitaire, pas leur ordinateur personnel (et certainement pas leur téléphone portable). Les données qui variaient d'un utilisateur à l'autre étaient généralement des données d'entrée et de sortie de processus de calcul scientifique - les perdre pourrait constituer une perte, mais en grande partie une perte qui pourrait être compensée en les recalculant, certainement rien à voir avec les conséquences des fuites de données d'aujourd'hui.

Personne n'aurait eu son journal, ses informations bancaires ou ses photos de nu sur un ordinateur, les protégeant ainsi des accès malveillants n'était pas quelque chose qui avait une grande priorité - en fait, la plupart des étudiants de premier cycle dans les années 70 auraient probablement été ravis si d'autres montraient de l'intérêt pour leurs données de recherche. Par conséquent, la prévention de la perte de données était considérée comme la priorité absolue en matière de sécurité informatique, et cela est assuré de manière adéquate par des sauvegardes régulières plutôt que par un contrôle d'accès.


C'est une observation très judicieuse. Oui, les logiciels malveillants exécutés en tant qu'utilisateur peuvent endommager/détruire/modifier les données de votre répertoire personnel. Oui, la séparation des utilisateurs sur les systèmes mono-utilisateur est moins utile que sur les serveurs. Cependant, il y a encore certaines choses que seul l'utilisateur root (ou équivalent) peut faire :

  • Installer un rootkit dans le noyau.
  • Modifier le chargeur de démarrage pour contenir une porte dérobée précoce pour la persistance.
  • Effacer tous les blocs du disque dur, rendant vos données irrécupérables.

Honnêtement, je trouve la séparation des privilèges sur les postes de travail la plus utile pour protéger le poste de travail de son plus grand ennemi :moi. Il est plus difficile de bousiller et de casser mon système.

De plus, vous pouvez toujours configurer une tâche cron en tant que root qui effectue une sauvegarde de votre répertoire personnel (avec, par exemple, rsnapshot ) et le stocke de sorte qu'il ne soit pas accessible en écriture par votre utilisateur. Ce serait un certain niveau de protection dans la situation que vous décrivez.

xkcd obligatoire


Linux
  1. Espace réservé pour la racine sur un système de fichiers - Pourquoi ?

  2. Désactiver le shell utilisateur pour des raisons de sécurité ?

  3. La fonction de la racine du groupe d'utilisateurs ? ?

  4. Installer WordPress sur un compte utilisateur en tant que root

  5. Utilisateur non root par défaut de Kali

Pourquoi l'utilisateur racine a-t-il besoin d'une autorisation Sudo ?

Linux – Pourquoi Archlinux conserve-t-il certains utilisateurs/groupes après la désinstallation du paquet ?

Différence entre l'utilisateur Sudo et l'utilisateur root ?

Pourquoi ne trouve-t-on pas Read /run/user/1000/gvfs même s'il s'exécute en tant que root ?

Où les applications stockent-elles généralement les données ?

Comment limiter l'utilisateur root dans CentOS