Les fichiers utilisateur sont-ils toujours privés lorsque deux utilisateurs sudo existent dans Ubuntu?

31

Je partage mon PC Ubuntu personnel avec un de mes collègues.

J'ai créé un autre utilisateur avec un mot de passe différent (il le sait bien sûr) et l'ai ajouté à la sudoerliste.

Étant donné qu'il y a deux sudoutilisateurs dans un seul système Ubuntu:

  • Les fichiers privés (spécifiés par les propriétaires et les autorisations) de l'un de ces utilisateurs sont-ils toujours privés?

  • Puis-je modifier les fichiers de mon collègue via la sudocommande, même sudo suou vice versa?

permissions sudo Jizhou Huang
la source
Possible lié à: En utilisant un service VPS, puis-je empêcher mes données d'être accessibles par l'hôte VPS?
pa4080
6
Ubuntu permet de chiffrer un dossier personnel lors de la création de l'utilisateur. C'est peut-être exactement la fonctionnalité requise ici.
Thorbjørn Ravn Andersen
Connexes:   est-il possible de détenir un serveur en otage si quelqu'un dispose d'un accès root?
G-Man dit `` Réintègre Monica ''
@ ThorbjørnRavnAndersen Une fois que j'ai chiffré le dossier de départ, puis-je toujours accéder aux fichiers à l'intérieur aussi pratique qu'avant?
Jizhou Huang
3
Pourquoi ne supprimez-vous pas l'accès sudo de l'autre utilisateur et devenez-vous le seul administrateur? Quelles que soient les raisons pour lesquelles l'autre utilisateur a besoin de sudo, vous pouvez les corriger afin qu'ils n'aient pas besoin de sudo (montage, impression, mises à jour automatiques, etc.)
Xen2050

Réponses:

51

Si votre collègue est dans la liste des sudoers, il est root autant que vous s'il le veut (et il peut aussi vous imiter), puis il peut tout voir.

C'est la pire configuration que vous puissiez avoir si vous voulez la confidentialité des utilisateurs. Vous devriez définitivement lire comment fonctionne la gestion des utilisateurs sur Linux. Voici quelques articles avec lesquels vous pouvez commencer:

Et même si quelqu'un a un accès physique à la machine en question, il n'y a pas d'intimité, il pourrait tomber au démarrage dans un shell racine et tout voir quoi qu'il arrive, et si cela était protégé par mot de passe, il pourrait toujours utiliser une clé USB et allez dans cette voie.

Donc, la meilleure chose dans ce cas est une bonne gestion des utilisateurs, un mot de passe pour la racine et un lecteur chiffré et / ou des répertoires personnels chiffrés.

Videonauth
la source
2
Mais assurez-vous que sudo -icela ne fonctionne pas :)
Wilf
3
Alors que la configuration la plus simple et la plus courante des sudoers consiste à autoriser temporairement une liste d'utilisateurs à disposer des privilèges root, sudoers permet un contrôle fin de l'accès. Par exemple, vous pouvez spécifier qu'un utilisateur ne peut exécuter que certaines commandes spécifiques en tant que root. Si vous prenez soin d'autoriser uniquement un utilisateur à exécuter des commandes qui ne permettent pas de créer un shell racine ou de créer un accès root persistant au-delà de la portée des commandes que vous souhaitez autoriser, vous pouvez éviter de leur donner un accès root en général.
bgvaughan
19

Une alternative simple consiste à conserver vos données privées dans un fichier crypté (pourrait être un fichier d'archive tar, que vous cryptez, par exemple avec gpg). Vous devez vous rappeler d'écraser et de supprimer les fichiers de texte clair après les avoir consultés.

Une autre alternative pour tous ceux qui partagent un ordinateur et un accès sudo (root) est d'utiliser la maison cryptée et le swap crypté.

Mais cela n'aidera pas si vous êtes connecté en même temps. En fait, vous devez redémarrer l'ordinateur pour vous débarrasser de vos fichiers au format texte clair même avec la maison cryptée.

En général, la sécurité est très difficile, et un système mono-utilisateur avec disque crypté (LVM avec cryptage) serait le moyen le plus simple de sécuriser les choses.

  • Ne stockez pas de données privées sensibles sur un ordinateur partagé
  • Ne stockez pas de données privées dans un ordinateur appartenant à votre employeur
sudodus
la source
3
Un conteneur dm-crypt / LUKS n'aurait pas à s'inquiéter de l'écrasement des fichiers en texte clair (sauf pour les fichiers temporaires et les ecryptfs-mount-private
échanges
6
Cela ne vous protège même pas des attaques malveillantes: l'autre utilisateur sudo peut modifier le système pour vous inciter à lui donner votre phrase secrète. Une telle question doit être lue comme "je soupçonne mon collègue d'être un espion russe. Dois-je lui donner des droits sudo sur mon ordinateur?"
sleblanc
Qu'en est-il d'une machine virtuelle avec une image disque chiffrée? blogs.oracle.com/scoter/…
leftaroundabout
1
Si vous avez besoin de confidentialité, vous avez besoin d'un système mono-utilisateur, c'est- à-dire aucun autre utilisateur, certainement aucun autre utilisateur sudo. Le LVM Ubuntu avec système de cryptage est vulnérable aux attaques malveillantes. Pourtant, je pense que c'est mieux que les autres alternatives faciles, y compris la maison cryptée. Bien sûr, si vous le souhaitez, vous pouvez avoir un disque crypté et un home crypté et un système mono-utilisateur, afin de rendre les choses plus difficiles pour un intrus, par exemple selon ce lien, iso.qa.ubuntu.com/qatracker/milestones / 363 / builds / 126342 /…
sudodus
Tout ce que le nouvel utilisateur root doit faire est d'installer un rootkit d'espace noyau comme la diamorphine. N'a même pas besoin de s'embêter avec les LD_PRELOADhacks de l' espace utilisateur : faites simplement un simple enregistreur de touches et lancez-le sur certains scripts python pour effectuer une segmentation floue de K-means en fonction du temps / du regroupement de la frappe et de l'analyse de texte, et terminé. Vous avez maintenant la phrase secrète de l'utilisateur et vous pouvez probablement accéder à ses données personnelles.
Cloud
8

Une fois que vous êtes en mesure d'obtenir des rootautorisations (par exemple à l' aide sudo, suetc.).
Vous avez un accès complet à tous les fichiers du système.

Ainsi, les deux utilisateurs qui ont l' sudoautorisation et peuvent devenir rootutilisateurs sudo bashauront un accès complet à tous les fichiers du système

Selon ce Q&A dans SE-Security: Vous pourriez être en mesure de modifier SELinux(ce qui n'est pas Ubuntu) afin de limiter l' rootaccès:

Si votre question est "puis-je le faire facilement et en toute sécurité maintenant?" La réponse est non. Si votre réponse est "Je suis prêt à en apprendre davantage sur SELinux, à me taire avec ma distribution et à supporter beaucoup de choses qui ne fonctionnent pas", la réponse est qu'il est possible de restreindre root beaucoup plus que votre installation moyenne. Cela dit, cela ne vous rend en aucun cas invulnérable aux exploits - cela ne rend pas impossible pour un utilisateur de contourner ce contrôle d'accès supplémentaire, que ce soit par logiciel ou physiquement.

Yaron
la source
2
Vous pouvez limiter root avec apparmor et selinux à la fois, cependant, quelqu'un avec un accès root complet ou un accès via le shell de récupération ou un CD live, avec l'un ou l'autre système (apparmor ou selinux) peut le modifier à nouveau.
Panther
1
Même si vous utilisez SELinux ou autre pour limiter ce que root peut faire directement, ils peuvent toujours être en mesure de modifier les utilitaires que les utilisateurs exécutent eux-mêmes. Et s'ils sont censés être en mesure d'exécuter des mises à niveau, ils auront besoin d'un accès pour modifier les binaires sur le système ...
ilkkachu
5

Pour que ce que les autres réponses disent déjà soit parfaitement clair: cet autre utilisateur n'est pas seulement "root autant que vous" (réponse de Videonauth), il peut aussi devenir vous (basculer vers votre compte utilisateur) .

En effet, avec les privilèges de superutilisateur, on peut basculer vers n'importe quel compte.

Vous savez probablement

sudo su

qui est une option pour ouvrir un shell root si root n'a pas de mot de passe défini (vous ne pouvez donc pas vous connecter directement en tant que root).

suest l'abréviation de "changer d'utilisateur". Vers quel utilisateur passe-t-il? Aucun n'est indiqué, non? Mais à partir de la page de manuel, nous pouvons apprendre que:

Appelé sans nom d'utilisateur, su par défaut devient le superutilisateur.

Donc, c'est effectivement

sudo su root

si vous n'avez pas renommé rootautre chose.

Si vous venez de courir su <someuser>, vous serez invité à entrer un mot de passe. Donc, si vous exécutez su root, vous êtes invité à entrer le mot de passe de root (qui n'existe pas dans Ubuntu par défaut, donc vous ne pouvez pas vous connecter (notez qu'aucun mot de passe défini ne signifie qu'il n'y a aucun moyen de se connecter via un mot de passe qui est différent du mot de passe étant la chaîne vide)). Mais si vous exécutez sudo su root, vous êtes invité à entrer votre propre mot de passe. Et vous n'y êtes invité que par sudo. Une fois sudovotre mot de passe reçu, il exécute la commande qu'il a reçue en tant que paramètres avec des privilèges de superutilisateur. Comme on peut basculer vers n'importe quel compte avec des privilèges de superutilisateur, une invite de mot de passe n'est pas nécessaire.

Donc en exécutant

sudo su <yourusername>

, l'autre sudoer peut se connecter en tant que vous.

UTF-8
la source
+1; Oui, je n'ai pas mentionné cela pour ne pas créer de confusion, le domaine de la protection d'une machine correctement est large et rempli de pierres sur lesquelles vous pouvez lutter. Encore un bon ajout à ce qui a déjà été donné comme réponses.
Videonauth
Pas sûr, mais n'est-ce pas sudo sutoujours par défaut UID 0 et GUID 0? Si oui, peu importe comment vous avez nommé «root».
Videonauth
@Videonauth Vous avez raison avec la deuxième phrase de votre deuxième commentaire. C'est pourtant la raison même pour laquelle j'ai inclus la phrase que vous critiquez. Si vous renommez rooten john, sudo suest désormais équivalent à sudo su johnet ne l'est plus sudo su root.
UTF-8
3

Il est possible de limiter les programmes pouvant être exécutés à l'aide de l'escalade de privilèges sudo en modifiant le fichier sudoers ( /etc/sudoers).

Voir la réponse acceptée à cette question sur Super User pour plus de détails et aussi ici sur Unix et Linux . Voir la réponse de slm pour une suggestion sur la limitation des privilèges dans /etc/sudoers.

Consultez également la manpage sudoers en tapant man sudoerset n'oubliez pas de la tester. N'oubliez pas qu'avec un accès sudo illimité, un utilisateur peut se faire passer pour n'importe quel autre utilisateur. par exemple, si l'utilisateur foodevait exécuter la commande

sudo exec su - bar

ils pourraient alors agir en tant qu'utilisateur bar, avec tous les privilèges de cet utilisateur.

charmeur
la source
6
Notez que les spécifiques sudoerslignes figurant dans ce slm et de mtak réponses ne fonctionnent pas pour donner la possibilité d'effectuer certaines actions et pas d' autres, comme il est facile trivialement de les utiliser pour exécuter une commande. (Voir les commentaires sur chacune de ces réponses pour des explications détaillées sur les raisons.) Cette réponse peut ne pas être strictement erronée dans la mesure où il est parfois possible d'autoriser les utilisateurs sudoà exécuter des commandes spécifiques en tant que root sans en faire des administrateurs. Mais il est très difficile de bien faire les choses .
Eliah Kagan
@EliahKagan Droite. Il serait nécessaire de s'assurer soigneusement que vous ne leur permettez pas d'atteindre un mécanisme qui leur permettrait d'exécuter n'importe quelle commande. Bien sûr, cela dépend du niveau de confiance que vous accordez à l'autre personne.
1
@EliahKagan D'où l'exhortation à lire la page de manuel et à tester toute implémentation. Limiter un utilisateur avec le privilège sudo est faisable. Cependant, comme vous le faites remarquer, ce n'est pas une solution entièrement sécurisée et un certain niveau de confiance doit être conféré aux utilisateurs qui bénéficient des droits sudo. Intéressant de voir les downvotes pour une réponse qui recommande l'utilisation du mécanisme (entrées du fichier sudoers) qui est spécifiquement conçu dans le but de limiter la portée de la commande sudo.
charmeur
Je pense qu'il ne s'agit pas de la recommandation d'utiliser un mécanisme intégré, alors permettez-moi d'en arriver à la critique constructive que je pourrais vous donner pour votre réponse. 1) Il contient des fautes de frappe et est mal formaté et semble étrange lorsque vous le lisez, ce qui en soi peut être réparé très facilement. 2) vous pointez vers d'autres réponses données en dehors de Ask Ubuntu , ici vous devez prendre les parties essentielles sous forme de citations de bloc et les publier ici, en faisant de vos liens une partie des citations pour pointer vers les sources à partir desquelles vous les avez tirées. J'espère que cela vous aidera à améliorer votre réponse.
Videonauth
Et comme je n'ai plus de personnages dans mon commentaire précédent: 3) Vous pourriez aller un peu plus loin dans l'explication, signalez les mises en garde @EliahKagan mentionnées.
Videonauth
0

Les réponses précédentes ne s'appliquent pas entièrement, si vous avez marqué encrypt home folderlors de l'installation d'Ubuntu. Cela garantit des dossiers de départ chiffrés pour chaque utilisateur, même si root ne peut pas lire les données sans le mot de passe correct de l'utilisateur / propriétaire de ce dossier de départ. Votre collègue devrait changer votre mot de passe pour lire les fichiers, ce qui serait remarqué.

Et bien sûr, les gens ont raison, que partager des machines avec des données précieuses ou sensibles dessus et en plus de l'accès root avec des collègues, n'est pas une bonne idée.

Selon la valeur de ces données, je vous suggère de demander votre propre machine.

s1mmel
la source
1
Cela pourrait ne pas empêcher un utilisateur root de faire une "su -" ou une manœuvre similaire dès que la "victime" est connectée et que le lecteur chiffré est monté .... il peut également y avoir un script cron ou un autre déclencheur en attente pour cela se passer. De plus, un utilisateur root pourrait facilement remplacer le binaire qui gère l'entrée du mot de passe pour déverrouiller le répertoire personnel chiffré par une version qui stocke le mot de passe en texte clair et attendre. Tout mécanisme de sécurité empêchant de telles attaques pourrait toujours être mis à profit en changeant un binaire que la victime utilisera en quelque chose qui fait ce que vous voulez.
rackandboneman
5
Je downvoting cette réponse en tant que répertoire personnel chiffré n'aide que si vous n'êtes pas actuellement connecté. Dès que vous vous connectez, vos données sont déchiffrées et disponibles pour l'autre utilisateur avec un accès sudo.
Panther
2
Mais pourquoi devraient-ils l'être? Même si les connexions simultanées ne sont jamais effectuées à distance (par exemple, SSH) ou avec des consoles virtuelles, deux utilisateurs ne peuvent-ils pas être connectés graphiquement en même temps et basculer entre? J'utilise Lubuntu (qui a LXDE) et je ne suis jamais connecté graphiquement avec plusieurs utilisateurs en même temps, mais j'ai l'impression que des environnements de bureau plus riches en fonctionnalités le prennent en charge depuis quelques années et l'activent par défaut. Suis-je dans l'erreur? Alternativement, les fichiers ne sont-ils plus déchiffrés et lisibles par root lorsque l'écran est verrouillé?
Eliah Kagan
2
IRRC, les clés de chiffrement des utilisateurs sont stockées ouvertement sur la machine pour fournir le chiffrement et le déchiffrement, de sorte qu'un utilisateur sudo su - <username>qui n'a pas besoin du mot de passe des autres utilisateurs réussisse normalement à déchiffrer le répertoire des autres utilisateurs. Mais je peux me tromper ici, je dois le tester dans une machine virtuelle et je le ferai plus tard. Quoi qu'il en soit, dans 99% des cas, cela revient à ceci: "Si j'ai un accès physique à votre machine, vous êtes arrosé!".
Videonauth
1
Un super utilisateur peut modifier la procédure de connexion pour enregistrer les noms d'utilisateur et les mots de passe qu'il voit. Attendez que l'autre utilisateur se connecte et que le problème soit résolu.
Stig Hemmer