Je constate qu'avec shm, les variables privées le restent sans avoir à utiliser de syscall à chaque fois qu'on y accède, ce qui serait évidemment très mauvais pour les performances.
Alors
a) accès ressources ou variables privées ?
b) séparation de privilèges ou isolations de processus ?
c) partage SHM protégé par GID/UID kernel ou autre de matériel ?
Non parceque là il va falloir choisir. Tu te places dans un cas pour lequel certes ma solution n'importe rien, mais qui d'un autre coté n'a rien a voir avec le problème posé initialement; dans le sous sous sous thread en cours je pensais naivement suite à ta correction que l'on parlait de ressources partagées en utilisant les méccanismes kernels de séparation de privilèges
Et tu contre mon argumentation en me parlant de variables privées protégés par hardware au niveau des processus.
Un syscall mutex ne permet absolument pas d'empecher les variables privées d'être accédées par une autre thread malicieuse.
Alors le syscall mutex, c'est celui qui fait des boucles atomiques ? Ou alors je joue encore sur les mots ? Et les variables privées de thread tu peux t'étendre un peu ?
On parle d'un Mutex (qui a été posé par un syscall et qui va être enlevé par un syscall certes, mais là il est présent il bouge pas).
On va dire que ce que tu voulais dire était Un kernel check sur un mutex ne permet absolument pas d'empecher une ressource partagée d'être accédées par une autre thread malicieuse.
A quoi on peut dire ceci :
a) si le mec est assez doué pour avoir suffisament pété les sécurités du systèmes pour pouvoir forcer un processus à spawner un nouveau thread malicieux on est pas beau. Si ce n'est pas un hacker surdoué c'est un programmeur bon à mettre à la poubelle.
b) On reprend rapidement le principe standard des mutex.
En mode normal : mutex M1 posé par le processus P1. Il existe aussi un processus P2. Lors de l'accès ressource le kernel vérifie si il y a un mutex dessus, et si il y a mutex il compare les droits du processus avec ceux du mutex.
Bref on a d'un coté (notation super cavalière mais ca ira)
M1$P1 et de l'autre P1. Si il y a accès de P1 su M1 ca passe., si il y a accès de P2 sur M1 ca casse.
Maintenant le même avec SELinux : On dit au kernel de ne pas tester seulement contre le processus, mais aussi contre le domaine.
Donc On a un seul process P1 avec T1 et T2. T1 appartient au domaine D1 et T2 au domaine D2.
Si T1 pose un mutex M1 sur une ressource celui ci aurait comme "clef" P1D1 donc pour reprendre notre affreuse notation :
M1$P1D1. Si T2 essaye de toucher à ce lock il se fera jeter car il arrivera du domaine D2 et aura donc une signature P1D2 incompatible avec M1.
D'ailleurs, juste avant un syscall, la thread T1 peut modifier les données qui seront envoyées en paramètre du syscall par T2.
Tout a fait, un process codé avec les pieds peut faire n'importe quoi. Mais j'ai du mal à y voir une spécificité des threads. Et ensuite, si le syscall est uen demande de pose de mutex, tu vas changer la demande de pose de mutex ? Tu vas faire faire un lock par T2 sur une autre ressource ? (si tant est qu'il peut). LOOOTTT !
Et juste après un syscall, la thread T1 peut modfier les données reçues du syscall par T2.
La faille ultime ! Au moment ou le kernel retourne le résultat du syscal vers le thread, tu interromps le kernel, tu redirige le thread cible sur toi Tu remplace le résultat par des marmottes, tu passe dans le Go kernel space et tu le renvoit au thread T2 en syscall. Noublie pas le papier cadeau autour c'est plus joli. Et là T2 sera persuadé que son syscal a échoué alors qu'en vrai il a réussi \o/.
Je pense que je vais me ranger à l'avis de pbpg et Frederic RISS ...
[^] # Re: Séparation des privilèges impossible avec threads actuelles !
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Alors
a) accès ressources ou variables privées ?
b) séparation de privilèges ou isolations de processus ?
c) partage SHM protégé par GID/UID kernel ou autre de matériel ?
Non parceque là il va falloir choisir. Tu te places dans un cas pour lequel certes ma solution n'importe rien, mais qui d'un autre coté n'a rien a voir avec le problème posé initialement; dans le sous sous sous thread en cours je pensais naivement suite à ta correction que l'on parlait de ressources partagées en utilisant les méccanismes kernels de séparation de privilèges
Et tu contre mon argumentation en me parlant de variables privées protégés par hardware au niveau des processus.
Un syscall mutex ne permet absolument pas d'empecher les variables privées d'être accédées par une autre thread malicieuse.
Alors le syscall mutex, c'est celui qui fait des boucles atomiques ? Ou alors je joue encore sur les mots ? Et les variables privées de thread tu peux t'étendre un peu ?
On parle d'un Mutex (qui a été posé par un syscall et qui va être enlevé par un syscall certes, mais là il est présent il bouge pas).
On va dire que ce que tu voulais dire était Un kernel check sur un mutex ne permet absolument pas d'empecher une ressource partagée d'être accédées par une autre thread malicieuse.
A quoi on peut dire ceci :
a) si le mec est assez doué pour avoir suffisament pété les sécurités du systèmes pour pouvoir forcer un processus à spawner un nouveau thread malicieux on est pas beau. Si ce n'est pas un hacker surdoué c'est un programmeur bon à mettre à la poubelle.
b) On reprend rapidement le principe standard des mutex.
En mode normal : mutex M1 posé par le processus P1. Il existe aussi un processus P2. Lors de l'accès ressource le kernel vérifie si il y a un mutex dessus, et si il y a mutex il compare les droits du processus avec ceux du mutex.
Bref on a d'un coté (notation super cavalière mais ca ira)
M1$P1 et de l'autre P1. Si il y a accès de P1 su M1 ca passe., si il y a accès de P2 sur M1 ca casse.
Maintenant le même avec SELinux : On dit au kernel de ne pas tester seulement contre le processus, mais aussi contre le domaine.
Donc On a un seul process P1 avec T1 et T2. T1 appartient au domaine D1 et T2 au domaine D2.
Si T1 pose un mutex M1 sur une ressource celui ci aurait comme "clef" P1D1 donc pour reprendre notre affreuse notation :
M1$P1D1. Si T2 essaye de toucher à ce lock il se fera jeter car il arrivera du domaine D2 et aura donc une signature P1D2 incompatible avec M1.
D'ailleurs, juste avant un syscall, la thread T1 peut modifier les données qui seront envoyées en paramètre du syscall par T2.
Tout a fait, un process codé avec les pieds peut faire n'importe quoi. Mais j'ai du mal à y voir une spécificité des threads. Et ensuite, si le syscall est uen demande de pose de mutex, tu vas changer la demande de pose de mutex ? Tu vas faire faire un lock par T2 sur une autre ressource ? (si tant est qu'il peut). LOOOTTT !
Et juste après un syscall, la thread T1 peut modfier les données reçues du syscall par T2.
La faille ultime ! Au moment ou le kernel retourne le résultat du syscal vers le thread, tu interromps le kernel, tu redirige le thread cible sur toi Tu remplace le résultat par des marmottes, tu passe dans le Go kernel space et tu le renvoit au thread T2 en syscall. Noublie pas le papier cadeau autour c'est plus joli. Et là T2 sera persuadé que son syscal a échoué alors qu'en vrai il a réussi \o/.
Je pense que je vais me ranger à l'avis de pbpg et Frederic RISS ...