accessibilité des variables d'environnement sous Linux
C'est peut-être une question banale, mais dans quelle mesure les variables d'environnement sont-elles accessibles sous Linux entre différents utilisateurs?
par exemple. si Alice s'exécute
export FAVORITE_FOOD=`cat /home/alice/fav_food.txt`
Eve peut-elle dire quelle est la nourriture préférée d'Alice? (En supposant qu'Alice et Eve sont des utilisateurs normaux et qu'Eve n'a pas accès en lecture à /home/alice/fav_food.txt)
Trouvons le flux des données confidentielles. Dans cette analyse, il est entendu que tout ce qu'Alice peut faire, root peut aussi le faire. Un observateur externe "un niveau plus haut" (par exemple avec un accès physique pour espionner sur le bus de disque, ou dans l'hyperviseur si le code s'exécute dans la machine virtuelle) pourrait être en mesure d'accéder aux données.
Tout d'abord, les données sont chargées à partir d'un fichier. En supposant que seule Alice dispose d'une autorisation de lecture sur le fichier et que le fichier ne soit pas divulgué autrement, seule Alice peut appeler cat /home/alice/fav_food.txt avec succès. Les données sont alors dans la mémoire du processus cat, où seul ce processus peut y accéder. Les données sont transmises via un canal de la commande cat au shell appelant; seuls les deux processus impliqués peuvent voir les données sur le tuyau. Les données sont alors dans la mémoire du processus Shell, à nouveau privées pour ce processus.
À un moment donné, les données se retrouveront dans l'environnement Shell. Selon le shell, cela peut se produire lorsque l'instruction export est exécutée, ou uniquement lorsque le shell exécute un programme externe. À ce stade, les données seront un argument d'un appel système execve . Après cet appel, les données seront dans l'environnement du processus enfant.
L'environnement d'un processus est tout aussi privé que le reste de la mémoire de ce processus (from mm->env_start à mm->env_end dans la carte mémoire du processus). C'est contigu à la pile du thread initial . Cependant, il existe un mécanisme spécial qui permet à d'autres processus d'afficher une copie de l'environnement: le fichier environ dans le processus /proc répertoire (/proc/$pid/environ). Ce fichier est uniquement lisible par son propriétaire , qui est l'utilisateur exécutant le processus (pour un processus privilégié, c'est l'UID efficace). (Notez que les arguments de ligne de commande dans /proc/$pid/cmdline, en revanche, sont lisibles par tous.) Vous pouvez auditer la source du noyau pour vérifier que c'est le seul moyen de fuir l'environnement d'un processus.
Il existe une autre source potentielle de fuite de l'environnement: pendant l'appel execve . L'appel système execve ne fuit pas directement l'environnement. Cependant, il existe un mécanisme générique d'audit qui peut consigner les arguments de chaque appel système, y compris execve. Donc, si l'audit est activé, l'environnement peut être envoyé via le mécanisme d'audit et se retrouver dans un fichier journal. Sur un système correctement configuré, seul l'administrateur a accès au fichier journal (sur mon installation Debian par défaut, c'est /var/log/audit/audit.log, uniquement lisible par root, et écrit par le démon auditd s'exécutant en tant que root).
J'ai menti ci-dessus: j'ai écrit que la mémoire d'un processus ne peut pas être lue par un autre processus. Ce n'est en fait pas vrai: comme tous les unices, Linux implémente l'appel système ptrace . Cet appel système permet à un processus d'inspecter la mémoire et même d'exécuter du code dans le contexte d'un autre processus. C'est ce qui permet aux débogueurs d'exister. Seule Alice peut retracer les processus d'Alice. De plus, si un processus est privilégié (setuid ou setgid), seul root peut le suivre.
Conclusion: l'environnement d'un processus n'est disponible que pour l'utilisateur (euid) exécutant le processus .
Notez que je suppose qu'il n'y a aucun autre processus qui pourrait divulguer les données. Il n'y a pas de programme racine setuid sur une installation Linux normale qui pourrait exposer l'environnement d'un processus. (Sur certains appareils plus anciens, ps était un programme racine setuid qui analysait la mémoire du noyau; certaines variantes afficheraient avec plaisir l'environnement d'un processus à tout le monde. Sous Linux, ps n'est pas privilégié et obtient son données de /proc comme tout le monde.).
(Notez que cela s'applique aux versions raisonnablement actuelles de Linux. Il y a très longtemps, je pense qu'à l'époque du noyau 1.x, l'environnement était lisible dans le monde entier.)
J'allais d'abord dire "non". Les valeurs des variables d'environnement sont par utilisateur et aucun autre utilisateur ne peut lire ou écrire dans l'environnement d'un autre utilisateur. vars. Cependant, il y a une friandise intéressante sur SO qui indique que root est capable au moins de lire ces informations via /proc/<pid>/environ. Je n'étais pas au courant de cette interface spécifique à Linux jusqu'à présent.
https://stackoverflow.com/a/532284/643314
Cela dit, il semble que cette interface soit toujours illisible pour les autres utilisateurs, même s'ils sont dans les mêmes groupes. Les autorisations sont définies sur 400 pour le fichier environ et/proc empêche chmod de l'affecter. Je soupçonne que le domaine de sécurité pour la séparation des variables d'environnement entre les utilisateurs est toujours intact et ne peut pas être contourné par des moyens normaux.
Malgré la réponse théoriquement correcte de Gilles: je ne mettrais pas de secrets dans les variables d'environnement.
- Les variables d'environnement sont généralement définies près du haut de l'arborescence des processus (par exemple via
$HOME/.profile). - Les utilisateurs ne traitent pas le contenu de l'environnement comme un secret.
Il suffit qu'un seul processus enregistre les variables d'environnement dans un fichier lisible par tout le monde: env >> env-traces.txt ou similaire. Vous ne pouvez pas le contrôler.
Dans la plupart des cas, un autre utilisateur ne peut pas lire vos variables d'environnement. Cependant, le trou de sécurité bien connu qu'une instance d'un programme setuid s'exécute comme le même utilisateur que toute autre instance d'un programme setuid peut être exploité. Cela signifie que si quelqu'un exécute un programme setuid et que quelqu'un d'autre peut exploiter un autre programme qui est setuid au même utilisateur pour lire à partir de /proc/<pid>/environ alors ils peuvent lire les variables d'environnement du programme. C'est une des raisons pour lesquelles vous devez utiliser un nouvel utilisateur pour tout démon que vous écrivez au lieu d'abuser de l'utilisateur nobody.
s'il n'y a pas de politiques strictes, THÉORIQUEMENT, il existe un moyen si cette exportation est effectuée dans un script utilisateur bash-login pour Alice: Eve crée un script pour imprimer env et définit les bits SETUIDGID dans chmod, puis le chown à Alice, s'exécute ensuite. Le script sera exécuté sous l'UID d'Alice et son exécution automatique bash sera celle d'Alice. Ensuite, il fuit les données via stdout =) Mais il doit y avoir une configuration système très faible pour effectuer de telles astuces. J'ai vu de telles boîtes terriblement configurées dans ma pratique médico-légale, donc ce n'est pas une blague.