Retraçons le flux des données confidentielles. Dans cette analyse, il est entendu que tout ce qu'Alice peut faire, root peut aussi le faire. De plus, un observateur externe "un niveau supérieur" (par exemple, avec un accès physique pour espionner sur le bus du disque, ou dans l'hyperviseur si le code s'exécute dans la machine virtuelle) peut ê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 a l'autorisation de lecture sur le fichier et que le fichier n'est pas autrement divulgué, seule Alice peut appeler cat /home/alice/fav_food.txt avec succès. Les données sont alors dans la mémoire du cat processus, où seul ce processus peut y accéder. Les données sont transmises sur un tube à partir du cat commande 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ée pour ce processus.
À un moment donné, les données se retrouveront dans l'environnement du shell. Selon le shell, cela peut arriver lorsque le 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 execve appel système. 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 (de mm->env_start à mm->env_end dans la carte mémoire du processus). Il est contigu à la pile du thread initial. Cependant, il existe un mécanisme spécial qui permet à d'autres processus de visualiser une copie de l'environnement :le environ fichier dans le /proc du processus répertoire (/proc/$pid/environ ). Ce fichier n'est lisible que par son propriétaire, qui est l'utilisateur exécutant le processus (pour un processus privilégié, c'est l'UID effectif). (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 divulguer l'environnement d'un processus.
Il existe une autre source potentielle de fuite de l'environnement :pendant le execve appel. Le execve l'appel système ne fuit pas directement l'environnement. Cependant, il existe un mécanisme d'audit générique qui peut enregistrer les arguments de chaque appel système, y compris execve . Ainsi, 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 , lisible uniquement par root et écrit par le auditd démon exécuté en tant que root).
J'ai menti plus haut :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 unix, Linux implémente le ptrace appel système. 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 tracer.
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 pas d'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 unices plus anciens, ps était un programme racine setuid qui analysait une partie de la mémoire du noyau ; certaines variantes afficheraient volontiers l'environnement d'un processus à tous. Sous Linux, ps n'est pas privilégié et obtient ses 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 par tout le monde.)
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 de lire au moins 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 appartiennent aux 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 en haut de l'arborescence des processus (par exemple, via
$HOME/.profile). - Les utilisateurs ne traitent pas le contenu de l'environnement comme des secrets.
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.