Pourquoi la sécurité root est-elle appliquée mais $ HOME n'est généralement pas protégé?
Venant des commentaires de cette question Pourquoi est-il mauvais de se connecter en tant que root? :
La mécanique Sudo étant utilisée, les outils non administratifs "ne peuvent pas endommager votre système". Je suis d'accord que ce serait assez mauvais si un projet github que j'ai cloné était capable d'injecter du code malveillant dans /bin. Cependant, à quoi ressemble le raisonnement sur un PC de bureau? Le même code github peut, une fois exécuté, sans droits Sudo, effacer tout mon dossier de départ, mettre un enregistreur de frappe dans ma session de démarrage automatique ou faire ce qu'il veut dans ~.
Sauf si vous avez des sauvegardes, le dossier de départ est généralement unique et contient des données précieuses, sinon sensibles. Cependant, les répertoires racine constituent le système et peuvent souvent être récupérés en réinstallant simplement le système. Certaines configurations sont enregistrées dans /var et ainsi de suite, mais elles ont tendance à avoir moins d'importance pour l'utilisateur que les photos de vacances de 2011. Le système d'autorisations root a du sens, mais sur les systèmes de bureau, il semble qu'il protège les mauvaises données.
N'y a-t-il aucun moyen d'empêcher un code malveillant de se produire dans $HOME? Et pourquoi personne ne s'en soucie?
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 faute. Je ne pense pas que ce soit le cas, car il existe des mécanismes pour gérer cela.
Le système d'autorisations root est logique, mais sur les systèmes de bureau, il semble qu'il protège les mauvaises données.
Les autorisations du superutilisateur existent pour protéger le système contre 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 des autorisations pour faire des choses avec votre UID. Étant donné que votre UID a un accès complet à votre répertoire personnel, vous avez transitoirement accordé au programme le même accès. Tout comme le superutilisateur a le droit d'apporter des modifications aux fichiers système qui nécessitent une protection contre les comportements malveillants (mots de passe, configuration, 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 dit que vous ne devez pas accorder plus d'accès que ce qui est absolument nécessaire. Le processus de décision pour exécuter n'importe quel programme doit être le même en ce qui concerne vos fichiers que pour les fichiers système. Si vous ne donnez pas un morceau de code auquel vous ne faites pas confiance en une utilisation illimitée du compte superutilisateur dans le but de protéger le système, il ne devrait pas être donné une utilisation illimitée de votre compte dans le but de protéger 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 il n'y a pas de protège-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 consiste à 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 ou non lui faire confiance.
Il existe d'autres façons de le faire, telles que les prisons chrootées, mais leur configuration demande plus de travail, et leur échapper n'est plus le défi que c'était autrefois.
Parce que le modèle de sécurité UNIX a 50 ans.
UNIX est à la base des systèmes d'exploitation les plus répandus, et même la grande exception que Windows en a été plus influencée qu'il n'y paraît. Cela remonte à une époque où les ordinateurs étaient de grandes machines coûteuses et lentes utilisées exclusivement par des spécialistes des arcanes.
À cette époque, les utilisateurs n'avaient tout simplement pas de vastes collections de données personnelles sur aucun ordinateur , ni leur serveur universitaire, ni 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 largement compensée par leur recalcul, certainement rien comme les conséquences des fuites de données d'aujourd'hui.
Personne n'aurait eu son journal, ses informations bancaires ou ses photos nues sur un ordinateur, donc les protéger contre les accès malveillants n'était pas quelque chose qui avait une priorité élevée - en fait, la plupart des étudiants de premier cycle dans les années 70 auraient probablement été ravis si d'autres avaient manifesté un 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 le contrôle d'accès.
Il s'agit d'une observation très astucieuse. Oui, les logiciels malveillants exécutés par votre 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:
- Installez un rootkit dans le noyau.
- Modifiez le chargeur de démarrage pour qu'il contienne une porte dérobée précoce pour la persistance.
- Effacez tous les blocs du disque dur, rendant vos données irrécupérables.
Honnêtement, je trouve que la séparation des privilèges sur les postes de travail est la plus utile pour protéger le poste de travail de son plus grand ennemi: moi. Cela rend plus difficile de foirer et de casser mon système.
De plus, vous pouvez toujours configurer un travail 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.
La conception originale de la sécurité Unix/Linux était de protéger un utilisateur des autres utilisateurs et les fichiers système des utilisateurs. Rappelez-vous qu'il y a 30 à 40 ans, la plupart des systèmes Unix étaient des configurations multi-utilisateurs avec de nombreuses personnes se connectant à la même machine en même temps. Ces systèmes coûtent des dizaines de milliers de dollars et il était extrêmement rare d'avoir votre propre machine personnelle, donc la machine était partagée dans un environnement de connexion multi-utilisateurs.
La conception n'a jamais été conçue pour protéger un utilisateur ou des fichiers d'utilisateurs contre un code malveillant, mais uniquement pour protéger les utilisateurs d'autres utilisateurs, les utilisateurs de modifier le système sous-jacent et les utilisateurs d'utiliser trop de ressources système. À notre époque actuelle, où tout le monde a son propre ordinateur, la conception s'est (pour la plupart) traduite en machines à utilisateur unique qui protègent un processus contre la surcharge de ressources système.
Pour cette raison, un programme exécuté par l'utilisateur a accès à tous les fichiers qu'il possède. Il n'y a aucun concept d'accès supplémentaire sur les propres fichiers d'un utilisateur. En d'autres termes, un processus exécuté en tant qu'utilisateur A a accès pour lire, modifier et supprimer tous les fichiers qui appartiennent à l'utilisateur A. Cela inclut (comme vous le notez) les fichiers de démarrage automatique.
Une approche plus moderne peut impliquer une forme de contrôle supplémentaire sur certains fichiers. Quelque chose comme "ré-authentification requise" pour accéder à ces fichiers, ou peut-être une autre forme de protection supplémentaire des fichiers d'un programme à partir d'un autre fichier de programme. AFAIK il n'y a (actuellement) rien de tel dans le monde du bureau Linux. Corrige moi si je me trompe?
N'y a-t-il aucun moyen d'empêcher le code malveillant de se produire dans $ HOME?
Pour répondre à cette question, certaines installations utilisent le cadre de sécurité existant en faisant en sorte qu'un utilisateur exécute spécifiquement le programme. Les programmes auront une option de configuration pour spécifier en tant qu'utilisateur qu'ils doivent exécuter. Par exemple, mon installation de PostgreSQL contient les fichiers de base de données appartenant à l'utilisateur postgres, et le serveur de base de données fonctionne comme postgres. Pour les commandes administratives de PostgreSQL, je changerais les utilisateurs en postgres. OpenVPN a également la possibilité de passer à un utilisateur sans privilège après avoir utilisé les pouvoirs administratifs de root (pour ajouter des interfaces réseau, etc.). Les installations peuvent avoir un utilisateur nommé nobody spécifiquement à cet effet. De cette façon, les exploits sur PostgreSQL ou OpenVPN ne conduiraient pas nécessairement au compromis de $HOME.
Une autre option consiste à utiliser quelque chose comme SELinux et à spécifier exactement à quels fichiers et autres ressources chaque programme a accès. De cette façon, vous pouvez même empêcher un programme exécuté en tant que root de toucher vos fichiers dans $HOME. Écrire une politique SELinux détaillée qui spécifie chaque programme est fastidieux, mais je pense que certaines distributions comme Fedora vont à mi-chemin et ont des politiques définies qui n'ajoutent que des restrictions supplémentaires aux programmes en réseau.
Pour répondre à la deuxième partie de votre question: Il existe des mécanismes sandbox, mais ils ne sont pas activés par défaut sur la plupart des distributions Linux.
Un très ancien et compliqué est selinux. Une approche plus récente et plus facile à utiliser est apparmor. Le plus utile pour un usage personnel (l'apparmeur et les systèmes similaires sont principalement utilisés pour protéger les démons) est firejail , qui isole les processus dans leur propre prison.
Un firefox ne peut par exemple qu'écrire son répertoire de profil et le répertoire Téléchargements. D'un autre côté, vous ne pourrez pas télécharger d'images si vous ne les placez pas dans le répertoire Téléchargements. Mais c'est par la conception d'un tel bac à sable. Un programme pourrait supprimer vos images ou les télécharger sur des sites aléatoires, donc la prison empêche cela.
L'utilisation de Firejail est facile. Vous l'installez et pour les programmes qui ont déjà un profil (regardez dans /etc/firejail) vous pouvez simplement faire (en tant que root) ln -s /usr/bin/firejail /usr/local/bin/firefox. Si vous n'êtes pas root ou souhaitez utiliser des arguments de ligne de commande pour firejail (par exemple, un chemin d'accès personnalisé aux fichiers de profil), vous pouvez exécuter firejail firefox.
Des systèmes comme le snap veulent également ajouter des mécanismes de sandboxing, vous pouvez donc exécuter un programme non fiable installé à partir d'un référentiel de snap aléatoire sans trop de conséquences. Avec tous ces mécanismes, gardez à l'esprit que les programmes non fiables peuvent toujours faire des choses comme envoyer du spam ou faire partie d'une attaque dDoS.
La présomption que les mauvaises données sont protégées est fausse.
La protection des activités root protège vos photos de vacances à partir de 2011. Et les miennes, celles de vos frères et de tous ceux qui utilisent l'ordinateur.
Même si vous avez implémenté un système d'exploitation avec un schéma qui protégeait le compte personnel en demandant un mot de passe à chaque fois qu'une application tentait d'accéder à un fichier et supprimait la protection par mot de passe root, je ne l'utiliserais pas car ce serait pire = pour ces photos de vacances.
Si mon frère compromet les fonctionnalités de base du système sur notre ordinateur personnel, mes photos de vacances sont supprimées, mises en garde contre rançon ou quoi que ce soit malgré les protections de votre répertoire personnel, car le système lui-même est désormais compromis et peut contourner les restrictions de niveau utilisateur que vous avez mises en œuvre .
Et la plupart des gens seraient très ennuyés s'ils devaient entrer un mot de passe chaque fois qu'ils choisissaient File -> Open dans leur traitement de texte.
De plus, nous avons rencontré trop souvent des problèmes de contrôle d'accès sur les ordinateurs personnels. Lorsque Microsoft a déployé pour la première fois son truc UAC (pour lequel vous n'avez même pas besoin d'entrer un mot de passe si vous utilisez le compte principal ... tout ce que vous avez à faire est d'appuyer sur un bouton ), cela est venu beaucoup et les gens se sont plaints suffisamment des 0,5 secondes de leur vie perdues 20 fois par jour que Microsoft a changé. Maintenant, ce n'est pas le type de protection dont vous parlez, mais cela nous montre que si les gens ne veulent pas cliquer sur un bouton de sécurité quelques dizaines de fois par jour pour la sécurité du système de Microsoft, ils ne voudront pas cliquer (ou pire, tapez un mot de passe) pour tout ce qui est mis en œuvre pour protéger leurs photos de l'application aléatoire qu'ils viennent d'exécuter.
La réponse de base est donc:
- La protection de root protège vos photos personnelles.
- Les gens se plaignent que ce type d'authentification soit trop souvent demandé.
D'autres réponses regardent pourquoi * nix est tel quel.
Mais il vaut la peine de noter qu'il est possible de faire un peu plus que la configuration "prête à l'emploi", pour protéger le répertoire personnel de l'utilisateur, les scripts et les fichiers.
La plupart des * nix modernes prennent en charge les ACL POSIX ou variantes, qui peuvent être configurées pour ajouter le type de contrôle d'accès granulaire que l'OP recherche. Vous devez les configurer manuellement et ils n'essaient pas de distinguer l'accès sur une base autre que le compte d'utilisateur/de groupe qui agit. Mais une fois configuré, vous pouvez être très précis sur les comptes qui peuvent effectuer quelles actions sur les fichiers et gagner au moins un contrôle supplémentaire en forçant les commandes à utiliser des comptes limités pour certaines commandes ou fichiers, plutôt qu'un seul compte utilisateur pour tout. Cependant, il aura une limite pratique assez serrée.
Un point clé de la sécurisation de la racine/du noyau est intégrité médico-légale. Dans le cas où le domaine contenant vos données précieuses (utilisateur de bureau avec des documents privés et des jetons d'authentification Web, serveur de développement avec un code/des ressources confidentielles, serveur Webapp avec une base de données d'utilisateurs, etc.) est compromis, vous vous avez toujours un sans compromis domaine à partir duquel évaluer le compromis, déterminer ce qui s'est passé, développer un plan pour se défendre contre la même chose se reproduisant, etc.
Ces privilèges n'existent pas car ils ne sont pas pratiques.
Le but des autorisations, en général, est d'empêcher les actions indésirables. Les types d'actions que root peut effectuer sont beaucoup plus insidieux. Une application de rançongiciel de niveau utilisateur peut être capable de crypter vos fichiers, mais ils ne peuvent pas cacher le fait qu'ils le font. Lorsque vous trouvez un fichier crypté, il s'ouvre comme d'habitude et révèle qu'il a été crypté. Avec un rançongiciel de niveau racine, il peut détourner l'intégralité de votre système de fichiers et créer l'illusion que les fichiers ne sont cryptés qu'au dernier moment, puis oublier la clé et bam! Tous vos fichiers deviennent inaccessibles en même temps.
Maintenant, évidemment, de nos jours, nous ne nous connectons pas en tant que root. Nous utilisons Sudo. Il s'agit d'une forme de privilège basé sur les rôles. Vous ne disposez pas des privilèges root tant que vous ne jouez pas le rôle "d'un utilisateur effectuant des tâches administratives". Ensuite, vous obtenez ces privilèges, jusqu'à ce que vous ayez terminé la commande.
Un pourrait créer des rôles à grain fin qui ont accès à différents dossiers. Peut-être que vous voulez que les "photos de vacances" soient en lecture seule sauf si vous entrez le rôle "ajouter/éditer des photos". Ce serait puissant, mais taxant. Comme Aaron l'a mentionné, l'UAC de Windows a été largement ignoré pour avoir perdu de précieuses secondes à demander la permission au lieu de simplement faire des choses. Votre ordinateur devrait demander l'autorisation plus souvent s'il devait changer de rôle pour protéger vos données. Les utilisateurs n'ont généralement pas trouvé cela utile, donc ce n'est pas pris en charge.
(Si vous étiez intéressé par de telles capacités et que vous vouliez utiliser Sudo pour les faire, vous pourriez créer une partition séparée qui pourrait être montée ro ou rw, selon ce que vous voulez faire, et y stocker vos photos).
L'une des tâches les plus difficiles à gérer dans ces cas est la granularité des rôles. Si le tilisateur entre dans un rôle ou un autre, c'est assez facile à gérer. Il est cependant plus difficile de gérer le cas où une application particulière doit assumer ce rôle. Peut-être que Firefox n'est pas autorisé à écrire sur vos photos, mais GIMP est autorisé à le faire. C'est délicat, car là où il y a des limites, vous ne pouvez pas avoir une intégration transparente cohérente. Et si Firefox profite d'un plugin GIMP pour faire de la retouche photo? La seule façon d'empêcher Firefox de le faire est de l'empêcher de parler à GIMP.
Je suppose que vous avez une certaine expérience avec Windows. Vous êtes-vous déjà demandé pourquoi l'écran s'assombrit lorsque l'UAC apparaît? C'est en fait pas pour une confirmation visuelle que vous faites quelque chose de spécial. C'est beaucoup plus important que ça. Les fenêtres au-dessus de la partie grisée font partie d'un écran différent, isolé des fenêtres ci-dessous. Pourquoi est-ce important? Eh bien, il s'avère que n'importe quelle fenêtre d'un écran est autorisée à manipuler n'importe quelle autre fenêtre sur ce même écran. Si l'UAC apparaissait sur le même écran que le programme d'installation demandant des autorisations, l'installateur pourrait littéralement simplement obtenir une poignée sur la fenêtre UAC et cliquer sur OK pour vous! Cela irait certainement à l'encontre du but d'une telle invite. La solution est que l'UAC est fourni sur un écran différent, donc aucune autre application ne peut cliquer sur OK seule. Le seul moyen de cliquer sur OK est si l'utilisateur déplace la souris et clique dessus. L'obscurcissement est vraiment juste là pour vous montrer que vous ne pouvez pas interagir avec l'une des fenêtres en dessous tandis que l'écran UAC a le contrôle du clavier/souris.
Voilà donc le niveau d'effort qui doit être fait pour l'isolement. Ce n'est pas facile. En fait, il est déjà assez difficile de protéger vos données clés en ayant plusieurs comptes d'utilisateurs et en donnant à chacun un accès différent aux données. Ensuite, vous pouvez utiliser la fonction de changement d'utilisateur pour basculer entre eux. Cela fournirait le type d'isolement dont vous avez besoin pour faire des privilèges décents basés sur les rôles.
Unix n'est pas vraiment un système de bureau. C'est un système fonctionnant sur un grand ordinateur qui coûte à peu près autant qu'une maison située quelque part dans le sous-sol de votre université. En tant que personne qui ne peut pas se permettre son propre ordinateur, vous devez partager l'ordinateur avec deux mille autres, et avec plusieurs dizaines d'utilisateurs simultanément, d'ailleurs.
Soit dit en passant, vous pouvez de nos jours également exécuter un système de type Unix sur votre ordinateur de bureau ou sur un SoC de la taille d'une carte de crédit qui coûte 20 $.
En principe, cependant, Unix n'est pas conçu pour les utilisateurs uniques. L'utilisateur unique n'est pas important. Ce qui se trouve dans votre répertoire personnel est votre problème, mais ce que root peut faire, c'est le problème de tout le monde. Par conséquent, seules les quelques tâches qui nécessitent vraiment que vous travailliez en tant que root doivent être effectuées avec cet utilisateur, et de préférence (pour limiter la fenêtre de temps pendant laquelle vous pouvez faire du mal) non pas en vous connectant avec ce compte, mais en en utilisant explicitement Sudo pour les commandes uniques qui en ont besoin. Il y a aussi beaucoup de religion là-dedans, c'est pourquoi certains distributeurs sont tellement arrogants qu'ils vous menacent lorsque vous tapez su plutôt que Sudo pour chacun des 10 différents apt commandes que vous devez exécuter pour installer une petite chose. Cet incident sera rapporté, eh bien dis quoi, putain de ton rapport. Certaines personnes savent vraiment ennuyer les autres.
Vous pouvez donc effacer toutes vos photos personnelles sans être root. C'est vrai. Les logiciels malveillants peuvent effacer tous les éléments de votre répertoire personnel, c'est vrai. Il peut refuser le service en remplissant votre disque jusqu'à ce que votre quota d'utilisateurs soit atteint, c'est vrai. Mais du point de vue du système, c'est juste votre problème, et personne d'autre ne s'en soucie. Aucun autre utilisateur n'est (en principe) affecté.
Maintenant, le problème avec un système moderne à utilisateur unique (ou peu) est que le modèle de sécurité logique bivalent est tout à fait inapplicable, tout comme l'idée "il y a des centaines d'utilisateurs".
Malheureusement, il est très difficile de trouver quelque chose de mieux. Regardez Windows si vous voulez voir comment ne pas voler une idée (ils ont vraiment réussi à aggraver une mauvaise approche).
Certains navigateurs Web et systèmes d'exploitation de téléphone (ou smart TV) tentent (et échouent) de fournir quelque chose de mieux, et Linux moderne a aussi un système plus fin (mais je ne saurais pas comment le configurer correctement sans dépenser - semaines de mon temps).
Le problème est que le modèle de sécurité bivalent suppose que les applications normales ne nécessitent aucun privilège (ce qui est faux parce que certaines choses pour la plupart inoffensives nécessitent des privilèges) tandis que les applications non normales nécessitent un accès complet au système informatique (ce qui est également faux, presque aucun programme n'a besoin d'un accès complet, jamais).
D'un autre côté, même des modèles de sécurité plus fins (qui sont encore assez grossiers) font l'hypothèse erronée que si une application demande un ensemble de privilèges, elle a vraiment besoin de cet ensemble complet et l'utilisateur est à l'aise de l'accorder.
Il n'y a, à ma connaissance, aucun système où une application peut demander les privilèges A, B et C, et l'utilisateur peut accepter d'accorder A (mais pas B et C), et l'application peut alors interroger les privilèges qui lui ont été accordés. et décidez s'il est capable d'exécuter la tâche demandée ou non.
Ainsi, vous avez généralement le choix d'accorder à XYZ-app "stocker des données sur un magasin permanent" (avec lequel vous êtes peut-être d'accord) et aussi permettant "d'accéder à ma position" et "d'accéder à mes données personnelles" ou "installer le pilote système" (avec lequel vous n'êtes pas d'accord), ou bien, vous ne pouvez pas exécuter le programme.
Ou, vous pouvez autoriser le programme XYZ à "apporter des modifications à votre ordinateur", quoi que cela signifie, ou vous pouvez choisir de ne pas l'exécuter. Et, vous devez le confirmer à nouveau à chaque fois. Ce qui, honnêtement, est vraiment nul du point de vue de l'utilisateur.
N'y a-t-il aucun moyen d'empêcher le code malveillant de se produire dans $ HOME?
En supposant que vous avez /home en tant que point de montage individuel, sur sa propre partition - vous pouvez alors simplement modifier /etc/fstab et ajoutez l'indicateur noexec aux options de montage. Cela désactive toute exécution de code sur cette partition, avec l'inconvénient que le code dans ~/bin (comme certaines installations par utilisateur peuvent le créer) ne fonctionnera plus non plus. cela n'empêchera néanmoins pas un exécutable situé ailleurs dans le système de fichiers de supprimer /home.
SE Linux est un système de sécurité à part entière, qui peut parfaitement isoler - tandis que AppArmor est juste pour l'isolement des applications. Linux sous-jacent d'Android le propose, depuis la version 5.0 quelque chose. Sous Windows, ils ont récemment introduit des "dossiers protégés" qui sont tout à fait les mêmes (une arnaque complète). ici, l'inconvénient est que lors de l'installation manuelle de quelque chose de nouveau, il faut souvent étiqueter et/ou définir les indicateurs appropriés, pour permettre cela, alors que le contexte dans lequel quelque chose s'exécute est le plus important là-bas. les gens suggèrent souvent de le désactiver, simplement parce qu'ils ne comprennent pas comment le gérer. eh bien, ce n'est pas exactement le point de choisir une distribution SE Linux pour un déploiement.
Je suis surpris que personne n'ait mentionné ce qui suit:
L'une des principales raisons de ne pas se connecter à une machine de bureau en tant que root est que de nombreuses activités changeront la propriété des fichiers pour devenir root. Cela signifie généralement que les utilisateurs "normaux" ne pourront pas exécuter de nombreuses applications car ils ne peuvent pas lire le fichier de configuration par défaut créé par root.
L'une des principales raisons pour lesquelles vous ne vous connectez pas à une machine serveur en tant que root est que, du point de vue de l'audit/de la traçabilité, il est préférable que quelqu'un se connecte en tant que lui-même, puis exécute les commandes en tant que root afin qu'il y ait un journal vérifiable qui indique que 'user1' connecté puis basculé vers root plutôt que de simplement savoir que "root" connecté à partir de l'adresse IP 10.2.1.2 qui peut être un terminal générique disponible pour de nombreuses personnes. Sur une machine serveur, il est plus courant d'avoir un accès Sudo limité à de nombreuses commandes pour tenter de garder les actions exécutées par un administrateur plus vérifiables et traçables.
Comme pour toutes les activités root, vous pouvez faire ce que vous voulez; rappelez-vous simplement que plus vous en faites, plus l'arme est pointée vers votre pied et il ne faut qu'une seule commande erronée pour appuyer sur cette détente.
rm -rf {uninitializedVariable}/*