De deux choses l'une :
Soit la licence a été violée, auquel cas la personen qui te vend le produit, n'a aucun droit pour le faire. En ne respectant pas la GPL par exemple il perd TOUS les droits, donc il ne peut pas te les retransmettre. De fait tu ne peux pas à ton tour faire valor la GPL pour redistribuer, vu que tu n'as aucun droit sur le logiciel.
C'est la version suivante de leur panneau de protection. On y trouve un firewall (il y était déjà), un système back-up restore (il y était déjà, mais planqué et il vaut pas un clou) et un anti-virus/spyware (c'est nouveau) ainsi que le windows update automatique (il y était déjà aussi).
Il y a des rumeurs comme quoi certains éditeurs pourraient remonter les mises à jour de leur produits comme c'est le cas aujourd'hui avec la mise à jour des pilotes via windows update. Mais vu la qualité du truc pour les pilotes ca fait peur.
J'arrive un peu parès la bataille, mais je me permettrait de rajouter :
si vous travaillez avec des fichiers NTSC utilisez -vf scale=720:480 Sinon ca ne sera pas beau.
être une copie et pas une autre version. Ici il s'agit d'une autre version, sans les logiciels démo et tout. Ce n'est pas une copie - ne pas avoir pour but de remplacer l'originale et n'être utilisée qu'à défaut de l'originale, ce qui n'est pas bon ici non plus
OURF si c'est le cas, tous mes backups sont donc illégaux ? Je n'ai pas le droit de réinstaller mon windows à partir de l'image que j'ai faite de mon disque la semaine dernière ?
Dans ce cas je m'inscrit allégrement au club des joyeux pirates. Déjà qu'il faut 25h de boulot/téléchargement pour transformer les auto-install windows OEM livrés en avec les PC en OS utilisables, si en plus on est obligé à chaque panne de recommencer de 0...
Sans rire, en informatique une licence me donne le droit d'utiliser une (ou plusieurs) version d'un produit sur une ou plusieurs machines. Avec des limitations sur le nombre d'utilisation simultanées et le type de machine. La Licence OEM est la plus restrictive, mais même en OEM si j'installe 17 partitions windows OEM sur mon disque et que je les utilise les unes après les autres je ne crois pas que qui que se soit puisse trouver quoi que ce soit à redire.
b) tu dois avoir dans IIS un truc du style
- Un site (zrag) avec comme configuration
Dans "home directory" redirection to a URL : /monapp avec directory below URL entered coché.
Dans Website/Advanced la réponse sur www.zragg.com sur le port 80
- un site virtuel (jakarta) avec
* index.jsp (ou autre) dans le document/enable default content page
* Virtual directory : a directory located on this computer avec comme path le path vers tomcat/isapi
ATTENTION : Ici c'est IIS qui gère la virtualisation du nom de domaine : Il ne doit donc pas y avoir de virtaul host dans Tomcat. Tomcat doit juste se contenter de répondre sur le port 8080 de son adresse IP.
En France oui.
Maintenant le truc c'est que si le TCE passe tous les pays de l'UE auront un système du même type (avec des droits un peu moins fort tout de même). La France gardera les textes de référence de sa constitution (donc pas d'amoindrissement) et les autres pays gagneront des textes que bien souvent ils n'avaient pas.
Quelle sanction ?
Il faudra attendre la jurisprudence pour savoir exactement. Mais je pense que le plus logique serait une éviction définitive de l'U.E. Je ne vois pas le tribunal Européen pousser le cynisme jusqu'à faire payer une ammende par personne torturée par un Etat.
Ceci est une grossière erreur car les déclarations des droits de l'homme ont une valeur juridique supérieure aux lois et non inférieure.
N'étant pas juriste je ne peux pas savoir exactement ce qu'il en est. Par contre je sais uen chose, la Chine qui est membre de l'ONU et donc signataire de la charte universelle des droits de l'homme a tendance à les respecter à sa façon.
Là tu parles clairement de la Comission
Non, non du conseil. C'est bien la commission qui a (avait si le TCE passe) l'initative des propositions d elois, mais c'est le conseil qui avalise ou non. Sans le feu vert du conseil, la proposition reste dans le tirroir.
Là je pense que tu parles de la Commission, mais je n'ai pas bien compris.
Si la procédure de codécision oscille trop longtemps (ie si le parlement et la comission se corrigent l'une l'autre plus de trois fois) c'est le conseil qui tranche. Bien sur pour éviter celà, le parlement comme le conseil peuevnt rejeter la proposition de loi.
Euh... Non. Je connais assez bien els différences pour ne pas me faire avori normalement.
Par contre tu peux citer le passage qui te pose problème ? parceque poru moi le troisième paragraphe c'est Pour ceux qui voudraient quand même comprendre le TCE par eux-même, je vous donne la recette.
Ce n'est pas plus dur de provoquer des overflows (et d'autres failles) dans un thread que dans un process !
J'ai prétendu le contraire ? Ca n'est pas alors un thread malicieux, mais une faille dans un thread existant. Par contre injecter un thread malicieux dans un processus ets infiniment plus complexe que d'injecter un processus malicieux dans un système.
Tous les programmes utilisant la séparation de privilèges (comme ssh ou X) utilisent évidemment des uid/groups spéciaux pour le process privilégié.
Donc la séparation des droits se fait au niveau logiciel et non au niveau matériel et c'est aussi sensible aux attaques que les threads
T2 ne peut pas empêcher un T1 malicieux d'accéder à une variable privée de T2 avec un signal.
Si cf les trois exemples dans les posts précédents.
En userspace, tu ne peux pas empêcher T1 de modifier les variables privées de T2 pour forcer T2 à utiliser R malicieusement.
Si, cf les trois exemples dans les posts précédents.
Tu ne peux pas faire cela pour R avec des threads T1 et T2 appartenants au meme process. Il n'y a donc pas de séparation de privilèges possible avec les threads.
Alors
a) Si tu arrives à créer un thread malicieux bravo.
b) Si ton privilège est sur un groupe ou un user et non sur le process, tu auras exactement les mêmes failles sur deux process P1 et P2 ayant même GID et même UID. (N.B si ce n'est pas le cas ce n'est pas un privilège, c'est une donnée privée)
c) Si tu as envie de placer des signaux dans tous les sens pour protéger tes variables dans les threads, c'est possible.
d) Si tu as un environement SE Linux tu peux protéger tes ressources/variables/accès aussi finement sur des threads que sur des process.
e) Inutile de hurler des définitions que je connais déjà quand je pars du principe que tu confonds deux choses distinctes, surtout si il s'avère quatre posts plus bas que j'avais raison.
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 ...
tu vas m'expliquer comment SELinux peut détecter lors d'une slice se déroulant en userspace, que la thread T1 a modifié des variables privées de la thread T2 afin de lui faire faire des choses non voulues avec la ressource R.
C'est sur que si tu veux des variables privées ET une protection granulaire kernel ET pas de syscall ca va être dur.
Par contre si on s'autorise les appels systèmes, un mutex (au sens système du terme, par un lock informatif pthread) posé par un thread d'un domaine peut parfaitement devenir totalement insensible au niveau kernel à une demande de retrait par les threads des autres domaines.
Par contre dans ce cas là impossible de faire sauter le syscall.
On a pas la même définition de privilèges. Je parlais de l'uid (user id) et du gid (group id) associé à un process.
Pour toutes les taches d'un meme process pid et gid sont évidemment identiques.
Ce qui veut dire que si une tache a une faille de sécurité, les autres sont compromises aussi. Ainsi que toutes les ressources du système auquelles les autres sont censé avoir accès via leur uid/gid.
Euh.... Tu laggues ?
Tous les threads d'un process ont le même uid et le même gid si tu veux, mais c'est pas pour autant qu'on ne peut pas les protéger les uns des autres. La protection uid/gid est une spécificité Linux. La mmu s'en balance, la seule chose qu'elle connaisse c'est pid. Tout le reste c'est logiciel. Et niveau logiciel on a fait de très gros progrès que ce soit dans le monde Linux ou dans le monde Windows. SE-Linux permet par exemple de définir des domaines, très pratique pour la séparation des taches. On se loggue en root, mais dans un domaine particulier et on a les droits root que sur un sous ensemble du système (éventuellement nul).
La bonne nouvelle c'est qu'on peut enregistrer deux threads d'un même process dans deux domaines différents. Je crois (PBPG confirmera ou infirmera) que l'on peut faire le même genre de chose avec Windows 2003.
La dessus je vais pas pouvoir m'étendre, je sais que c'est possible mais je n'ai pas encore jeté un oeuil approfondi sur les implémentations.
C'est le problème, si ton lcteur de salon sait lire çà, c'ets que c'est un mauvais lecteur. Un lecteur de salon qui tient compte des corrections d'erreur et/ou qui fait du read-ahead se vautrera neuf fois sur dix. Le mien me recrahce le seul CD protégé qui me reste à la gueule.
Je garde ce CD (une démo donnée "gratuitement") pour tester les platines "hautes-fidélités" en magasin. Si le CD passe, c'est qu'il y a neuf chances sur dix que la platine soit mauvaise. C'est hallucinant le temps que ca fait gagner quand on cherche une
Ca fait un an que je n'ai aps acheté un seul CD produit/copyrighté par une major ou un sous-fifre. Je m'en porte très bien. J'invite tout le monde à faire de même. Il y a d'excellents produits chez les indés/mouvements alternatifs/site web autoproduits.
Après un test and set réussi, la variable est modifiée !
Désolé d'être pointilleux, mais entre la boucle atomique, le spinlock qui locke et les futex au final, j'étais un peu perdu.
Mais là ca va mieux.
Mais dans le cas de Linux, les futex permettent d'éviter ce dilemne sans utiliser un sous-scheduler interne
Ce qui permet de passer à la question piège : a ton avis les futex, c'est un lock qui génère un sigsev si tu passes outre ou un lock informatif façon NPTL ? (Hint : la NPTL utilise massivemetn les futex)
Tu as un problème de mise en cache local.
Pour voir les modifications en temps réel il va falloir définir précisément les droits pour chaque répertoire partagé et gicler tous les caches samba sur ces répertoires.
Par contre en samba 3 je ne sais pas comment on fait.
Peut-on avoir une indication pour éclairer notre lanterne ?
Tu as déjà joué au ping-pong ?
Ben la même chose avec deux porcess qui se lancent des alarmes (j'avais dit que c'était très con)
Là aussi, peux-tu expliquer comment 2 threads d'un meme process peuvent séparer leur privilèges ?
En théorie ils ne peuvent pas, en pratique c'est pas grave.
Méthode du gros rouge qui tache.
le thread t1 veut une variable privée A
il pose un write-lock dessus
il pose une variable de condition signal sur la présence write-lock
Au cas ou il recoit un signal sur cette condition, ils ait qu'un autre thread a enlevé le write-lock pour aller écrire dans la variable. De rage il termine le processus.
Méthode plus subtile, mais à peine :
Le scheduler a une variable en readlock qui contient le dernier thread appelé
le thread veut une variable privée B
il créé deux variables B1 et B2
il write-lock les deux variables
il les mets à la même valeur
il pose 3 variables de condition signal : 2 sur la présence de chacun des writelock et un sur l'égalité de B1 et B2
Au cas ou il recoit un signal sur une des trois conditions
a) detach du dernier thread appelé
b) constatation des dégats : peut-on dire qu'une des copies est fiables ? (généralement : oui)
c) réparation des dégats : on reduplique la copie fiable et on remet les locks.Si la réparation est impossible exit.
Le gros problème c'est que c'ets lourd, lent et qu'il y a des pièges de synchros et des conditions de courses dans tous les sens. Je laisserais pas çà dans un code en prod, mais pour le débug ca marche pas mal du tout. En y passant du temps il doit être possible de faire une implémentation "propre" sur la même idée (ie un truc dans lequel on est sur à 100% qu'un thread n'a pas pu enlever les deux write-lock, changer les valeurs des deux variables et remettre les deux write-lock à l'identique sans que les variables de conditions n'aient le temps d'être mise à jour.)
Les signaux sont des interruptions, pas un échange de donnée. Tu fais comment pour échanger des données sans recopie entre 2 entités ayant des privilèges différents , avec un signal ?
On peut, mais c'est très con. Ceci étant je croyais que le but était de séparer les privilèges, dans ce cas là ca marche très bien.
Boucle atomique.... ??? Mais pourquoi aurait-elle besoin d'être atomique ?
C'est marrant c'est exactement la question que je me posais. Donc ton spinlock atomique sur processeurs récents on est d'accord tous les deux pour dire que ça ne veux rien dire (vu que spinlock => boucle)
2. Après un test and set réussi, le lock est pris !
J'ai l'impression que tu te perds. dans l'ordre :
a) un spinlock n'est pas un lock. C'est un retry constant d'une opération sur une ressource. Dès que l'opération passe , le spinlock se termine, la ressources peut être lue/écrite/modifiée sans jamais avoir été lockée. Même si le test qui permet de savoir que le spinlock c'est terminé se déroule plus tard.
b) On peut utiliser un spinlock pour faire comme opération atomique un lock. Mais autant faire l'opération de lock directement et récupérer le résultat (erreur ou OK). Ca revient exactement au même vu que la pose d'un lock est une opération atomique.
[^] # Re: Questions pour les juristes.
Posté par Jerome Herman . En réponse à la dépêche La saga Maui X-Stream continue. Évalué à 2.
De deux choses l'une :
Soit la licence a été violée, auquel cas la personen qui te vend le produit, n'a aucun droit pour le faire. En ne respectant pas la GPL par exemple il perd TOUS les droits, donc il ne peut pas te les retransmettre. De fait tu ne peux pas à ton tour faire valor la GPL pour redistribuer, vu que tu n'as aucun droit sur le logiciel.
# Euh...
Posté par Jerome Herman . En réponse au journal Synaptic porté sous Windows.... Évalué à 9.
Il y a des rumeurs comme quoi certains éditeurs pourraient remonter les mises à jour de leur produits comme c'est le cas aujourd'hui avec la mise à jour des pilotes via windows update. Mais vu la qualité du truc pour les pilotes ca fait peur.
[^] # Re: La solution !
Posté par Jerome Herman . En réponse au journal Convertir une vidéo en DV ?. Évalué à 5.
J'arrive un peu parès la bataille, mais je me permettrait de rajouter :
si vous travaillez avec des fichiers NTSC utilisez -vf scale=720:480 Sinon ca ne sera pas beau.
[^] # Re: Administration des PC
Posté par Jerome Herman . En réponse au journal Microsoft récidive.... Évalué à 2.
- ne pas avoir pour but de remplacer l'originale et n'être utilisée qu'à défaut de l'originale, ce qui n'est pas bon ici non plus
OURF si c'est le cas, tous mes backups sont donc illégaux ? Je n'ai pas le droit de réinstaller mon windows à partir de l'image que j'ai faite de mon disque la semaine dernière ?
Dans ce cas je m'inscrit allégrement au club des joyeux pirates. Déjà qu'il faut 25h de boulot/téléchargement pour transformer les auto-install windows OEM livrés en avec les PC en OS utilisables, si en plus on est obligé à chaque panne de recommencer de 0...
Sans rire, en informatique une licence me donne le droit d'utiliser une (ou plusieurs) version d'un produit sur une ou plusieurs machines. Avec des limitations sur le nombre d'utilisation simultanées et le type de machine. La Licence OEM est la plus restrictive, mais même en OEM si j'installe 17 partitions windows OEM sur mon disque et que je les utilise les unes après les autres je ne crois pas que qui que se soit puisse trouver quoi que ce soit à redire.
[^] # Re: On va essaye run truc :
Posté par Jerome Herman . En réponse au message IIS, Tomcat et virtual host (2). Évalué à 2.
# On va essaye run truc :
Posté par Jerome Herman . En réponse au message IIS, Tomcat et virtual host (2). Évalué à 2.
http://xx.xx.xx.xx:8080/monapp(...)
b) tu dois avoir dans IIS un truc du style
- Un site (zrag) avec comme configuration
Dans "home directory" redirection to a URL : /monapp avec directory below URL entered coché.
Dans Website/Advanced la réponse sur www.zragg.com sur le port 80
- un site virtuel (jakarta) avec
* index.jsp (ou autre) dans le document/enable default content page
* Virtual directory : a directory located on this computer avec comme path le path vers tomcat/isapi
ATTENTION : Ici c'est IIS qui gère la virtualisation du nom de domaine : Il ne doit donc pas y avoir de virtaul host dans Tomcat. Tomcat doit juste se contenter de répondre sur le port 8080 de son adresse IP.
[^] # Re: Bravo pour ton changement de veste !
Posté par Jerome Herman . En réponse au journal Yet Another Stupid Journal sur le @#~&!! de TCE. Évalué à 3.
Maintenant le truc c'est que si le TCE passe tous les pays de l'UE auront un système du même type (avec des droits un peu moins fort tout de même). La France gardera les textes de référence de sa constitution (donc pas d'amoindrissement) et les autres pays gagneront des textes que bien souvent ils n'avaient pas.
[^] # Re: sanction
Posté par Jerome Herman . En réponse au journal Yet Another Stupid Journal sur le @#~&!! de TCE. Évalué à 3.
Il faudra attendre la jurisprudence pour savoir exactement. Mais je pense que le plus logique serait une éviction définitive de l'U.E. Je ne vois pas le tribunal Européen pousser le cynisme jusqu'à faire payer une ammende par personne torturée par un Etat.
[^] # Re: s/Conseil/Commission/ ?
Posté par Jerome Herman . En réponse au journal Yet Another Stupid Journal sur le @#~&!! de TCE. Évalué à 1.
Il les écrits, mais c'est le conseil qui décide si c'est étudié ou non. (cf plus haut.)
[^] # Re: Bravo pour ton changement de veste !
Posté par Jerome Herman . En réponse au journal Yet Another Stupid Journal sur le @#~&!! de TCE. Évalué à 2.
N'étant pas juriste je ne peux pas savoir exactement ce qu'il en est. Par contre je sais uen chose, la Chine qui est membre de l'ONU et donc signataire de la charte universelle des droits de l'homme a tendance à les respecter à sa façon.
[^] # Re: s/Conseil/Commission/ ?
Posté par Jerome Herman . En réponse au journal Yet Another Stupid Journal sur le @#~&!! de TCE. Évalué à 4.
Non, non du conseil. C'est bien la commission qui a (avait si le TCE passe) l'initative des propositions d elois, mais c'est le conseil qui avalise ou non. Sans le feu vert du conseil, la proposition reste dans le tirroir.
Là je pense que tu parles de la Commission, mais je n'ai pas bien compris.
Si la procédure de codécision oscille trop longtemps (ie si le parlement et la comission se corrigent l'une l'autre plus de trois fois) c'est le conseil qui tranche. Bien sur pour éviter celà, le parlement comme le conseil peuevnt rejeter la proposition de loi.
[^] # Re: s/Conseil/Commission/ ?
Posté par Jerome Herman . En réponse au journal Yet Another Stupid Journal sur le @#~&!! de TCE. Évalué à 2.
Par contre tu peux citer le passage qui te pose problème ? parceque poru moi le troisième paragraphe c'est Pour ceux qui voudraient quand même comprendre le TCE par eux-même, je vous donne la recette.
[^] # 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.
J'ai prétendu le contraire ? Ca n'est pas alors un thread malicieux, mais une faille dans un thread existant. Par contre injecter un thread malicieux dans un processus ets infiniment plus complexe que d'injecter un processus malicieux dans un système.
Tous les programmes utilisant la séparation de privilèges (comme ssh ou X) utilisent évidemment des uid/groups spéciaux pour le process privilégié.
Donc la séparation des droits se fait au niveau logiciel et non au niveau matériel et c'est aussi sensible aux attaques que les threads
T2 ne peut pas empêcher un T1 malicieux d'accéder à une variable privée de T2 avec un signal.
Si cf les trois exemples dans les posts précédents.
En userspace, tu ne peux pas empêcher T1 de modifier les variables privées de T2 pour forcer T2 à utiliser R malicieusement.
Si, cf les trois exemples dans les posts précédents.
[^] # 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) Si tu arrives à créer un thread malicieux bravo.
b) Si ton privilège est sur un groupe ou un user et non sur le process, tu auras exactement les mêmes failles sur deux process P1 et P2 ayant même GID et même UID. (N.B si ce n'est pas le cas ce n'est pas un privilège, c'est une donnée privée)
c) Si tu as envie de placer des signaux dans tous les sens pour protéger tes variables dans les threads, c'est possible.
d) Si tu as un environement SE Linux tu peux protéger tes ressources/variables/accès aussi finement sur des threads que sur des process.
e) Inutile de hurler des définitions que je connais déjà quand je pars du principe que tu confonds deux choses distinctes, surtout si il s'avère quatre posts plus bas que j'avais raison.
[^] # 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 ...
[^] # Re: boah tout le monde peut copier
Posté par Jerome Herman . En réponse à la dépêche La justice confirme la légalité des systèmes anticopie sur les CD audio. Évalué à 1.
Apparament le "CD physical spécification" est décrit dans le red book.
[^] # 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.
C'est sur que si tu veux des variables privées ET une protection granulaire kernel ET pas de syscall ca va être dur.
Par contre si on s'autorise les appels systèmes, un mutex (au sens système du terme, par un lock informatif pthread) posé par un thread d'un domaine peut parfaitement devenir totalement insensible au niveau kernel à une demande de retrait par les threads des autres domaines.
Par contre dans ce cas là impossible de faire sauter le syscall.
[^] # Re: boah tout le monde peut copier
Posté par Jerome Herman . En réponse à la dépêche La justice confirme la légalité des systèmes anticopie sur les CD audio. Évalué à 1.
Non il ne répondent pas non plus au white book sur les CD en général.
Ce sont de vrais purs ovnis.
[^] # Re: séparation des privilèges
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Pour toutes les taches d'un meme process pid et gid sont évidemment identiques.
Ce qui veut dire que si une tache a une faille de sécurité, les autres sont compromises aussi. Ainsi que toutes les ressources du système auquelles les autres sont censé avoir accès via leur uid/gid.
Euh.... Tu laggues ?
Tous les threads d'un process ont le même uid et le même gid si tu veux, mais c'est pas pour autant qu'on ne peut pas les protéger les uns des autres. La protection uid/gid est une spécificité Linux. La mmu s'en balance, la seule chose qu'elle connaisse c'est pid. Tout le reste c'est logiciel. Et niveau logiciel on a fait de très gros progrès que ce soit dans le monde Linux ou dans le monde Windows. SE-Linux permet par exemple de définir des domaines, très pratique pour la séparation des taches. On se loggue en root, mais dans un domaine particulier et on a les droits root que sur un sous ensemble du système (éventuellement nul).
La bonne nouvelle c'est qu'on peut enregistrer deux threads d'un même process dans deux domaines différents. Je crois (PBPG confirmera ou infirmera) que l'on peut faire le même genre de chose avec Windows 2003.
La dessus je vais pas pouvoir m'étendre, je sais que c'est possible mais je n'ai pas encore jeté un oeuil approfondi sur les implémentations.
[^] # Re: boah tout le monde peut copier
Posté par Jerome Herman . En réponse à la dépêche La justice confirme la légalité des systèmes anticopie sur les CD audio. Évalué à 10.
C'est le problème, si ton lcteur de salon sait lire çà, c'ets que c'est un mauvais lecteur. Un lecteur de salon qui tient compte des corrections d'erreur et/ou qui fait du read-ahead se vautrera neuf fois sur dix. Le mien me recrahce le seul CD protégé qui me reste à la gueule.
Je garde ce CD (une démo donnée "gratuitement") pour tester les platines "hautes-fidélités" en magasin. Si le CD passe, c'est qu'il y a neuf chances sur dix que la platine soit mauvaise. C'est hallucinant le temps que ca fait gagner quand on cherche une
Ca fait un an que je n'ai aps acheté un seul CD produit/copyrighté par une major ou un sous-fifre. Je m'en porte très bien. J'invite tout le monde à faire de même. Il y a d'excellents produits chez les indés/mouvements alternatifs/site web autoproduits.
[^] # Re: vs POSIX shared memory, read-only
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Désolé d'être pointilleux, mais entre la boucle atomique, le spinlock qui locke et les futex au final, j'étais un peu perdu.
Mais là ca va mieux.
Mais dans le cas de Linux, les futex permettent d'éviter ce dilemne sans utiliser un sous-scheduler interne
Ce qui permet de passer à la question piège : a ton avis les futex, c'est un lock qui génère un sigsev si tu passes outre ou un lock informatif façon NPTL ? (Hint : la NPTL utilise massivemetn les futex)
# C'est assez simple
Posté par Jerome Herman . En réponse au journal problème de migration : pas de notification des modifications de fichiers distant. Évalué à 3.
Pour voir les modifications en temps réel il va falloir définir précisément les droits pour chaque répertoire partagé et gicler tous les caches samba sur ces répertoires.
Par contre en samba 3 je ne sais pas comment on fait.
[^] # Re: séparation des privilèges
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Tu as déjà joué au ping-pong ?
Ben la même chose avec deux porcess qui se lancent des alarmes (j'avais dit que c'était très con)
Là aussi, peux-tu expliquer comment 2 threads d'un meme process peuvent séparer leur privilèges ?
En théorie ils ne peuvent pas, en pratique c'est pas grave.
Méthode du gros rouge qui tache.
le thread t1 veut une variable privée A
il pose un write-lock dessus
il pose une variable de condition signal sur la présence write-lock
Au cas ou il recoit un signal sur cette condition, ils ait qu'un autre thread a enlevé le write-lock pour aller écrire dans la variable. De rage il termine le processus.
Méthode plus subtile, mais à peine :
Le scheduler a une variable en readlock qui contient le dernier thread appelé
le thread veut une variable privée B
il créé deux variables B1 et B2
il write-lock les deux variables
il les mets à la même valeur
il pose 3 variables de condition signal : 2 sur la présence de chacun des writelock et un sur l'égalité de B1 et B2
Au cas ou il recoit un signal sur une des trois conditions
a) detach du dernier thread appelé
b) constatation des dégats : peut-on dire qu'une des copies est fiables ? (généralement : oui)
c) réparation des dégats : on reduplique la copie fiable et on remet les locks.Si la réparation est impossible exit.
Le gros problème c'est que c'ets lourd, lent et qu'il y a des pièges de synchros et des conditions de courses dans tous les sens. Je laisserais pas çà dans un code en prod, mais pour le débug ca marche pas mal du tout. En y passant du temps il doit être possible de faire une implémentation "propre" sur la même idée (ie un truc dans lequel on est sur à 100% qu'un thread n'a pas pu enlever les deux write-lock, changer les valeurs des deux variables et remettre les deux write-lock à l'identique sans que les variables de conditions n'aient le temps d'être mise à jour.)
[^] # Re: scheduler intra-processus, voir plus haut, sécurité/rapidité
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
On peut, mais c'est très con. Ceci étant je croyais que le but était de séparer les privilèges, dans ce cas là ca marche très bien.
[^] # Re: vs POSIX shared memory, read-only
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
C'est marrant c'est exactement la question que je me posais. Donc ton spinlock atomique sur processeurs récents on est d'accord tous les deux pour dire que ça ne veux rien dire (vu que spinlock => boucle)
2. Après un test and set réussi, le lock est pris !
J'ai l'impression que tu te perds. dans l'ordre :
a) un spinlock n'est pas un lock. C'est un retry constant d'une opération sur une ressource. Dès que l'opération passe , le spinlock se termine, la ressources peut être lue/écrite/modifiée sans jamais avoir été lockée. Même si le test qui permet de savoir que le spinlock c'est terminé se déroule plus tard.
b) On peut utiliser un spinlock pour faire comme opération atomique un lock. Mais autant faire l'opération de lock directement et récupérer le résultat (erreur ou OK). Ca revient exactement au même vu que la pose d'un lock est une opération atomique.