free2.org a écrit 2367 commentaires

Par défaut MUTE choisi tes "amis" (tes voisins immédiats) aléatoirement parmis des IPs d'utilisateurs postés sur des pages webs.
Il vaut donc mieux le configurer pour:
1. enlever le post automatique de ton IP sur ces pages webs
2. choisir toi-même tes amis (ce qui est bien normal :) )

Ce que tu cherches est là:
http://fr.wikipedia.org/wiki/Ami_%C3%A0_ami(...)
http://en.wikipedia.org/wiki/Friend-to-friend(...)

Le principe est que tu communiques directement avec tes amis, et indirectement (mais automatiquement et anonymement) avec les amis de tes amis.

WASTE est actuellement le plus simple à configurer (même si la version Linux basée sur WXwidgets a certains bugs, regarde les patches dans sf.net)
https://sourceforge.net/projects/waste/(...)

Dans la dernière ligne il faut lire:
alors ctrl-v collera texte1 (mémorisé dans le tampon spécial) et bouton-milieu collera texte2.

Tu as repéré certains détails à corriger dans cet article. Je te propose de les corriger tout de suite en cliquant sur "modier".

Comme tu as pu le constaté, j'ai facilement donné une période avec des failles critiques connues non-corrigées, donc avec des machines XP crackables instantanément. Comme par hasard, nous sommes dans une de ces périodes.

Vis à vis des utilisateurs de win qui ont légitimement le droit de se poser des questions très sérieuses en voyant cela, c'est à ton tour de trouver facilement une période où XP n'était pas exploitable par un cracker. Cela devrait même être très facile d'après tes propos précédents.

Si tu n'es pas capable de donner une période sans exploit maintenant, tu ne respectes pas les utilsiateurs de win qui sont inquiets par la facilité avec laquelle j'ai trouvé une période exploitable.

pour les flemmards, voici le nouveau thread:
https://linuxfr.org/comments/565312.html#565312(...)

(re-)Précisons que c'est aussi un des principaux auteurs de Samba. Donc il s'y connait en fabrication de logiciels pour assurer l'interopérabilité avec des softs propriétaires. Et il connait déjà des entreprises qui n'aiment pas ça :)

Désolé mais je peux pas tout faire.
Mais puisque toi tu aimes les archives, cite moi une période où il n'y avait pas de failles critiques non corrigées !

Comme par hasard, et alors que tu prétendais le contraire, on est dans une période où les failles crtiques connues sont pas corrigées.

Etant un lecteur régulier, je sais que ce n'est pas un hasard.

Mais de toutes façons tous ceux qui lisent ce thread ont bookmarké cette page et pourront voir par eux-même !

Le message est accessible en cliquant sur le lien qui correspond à l'article, et il n'est donc pas dans ce thread.

- Tu pretends que les failles sont dues aux threads, et hop, rien pour justifier
A quel endroit j'ai dit que toutes étaient dues au threads ?

Tu pretends qu'il y a plein de failles non corrigees dans Windows, et hop, rien pour justifier
Désolé que tu comprennes pas, mais tous ceux qui fréquentent régulièrement cette page Secunia ont compris, eux. Tous les jours où on visite cette page, on peut y constater que chaque jour on peut rentrer par effraction dans un systeme XP. Point.

Je n'ai pas d'archive du site Secunia. Et je ne vais pas en chercher une pour tes beaux yeux. Mais tous ceux qui visitent cette page régulièrement savent qu'il n'y a quasiment jamais de jour sans que XP soit crackable à l'aide d'une faille critique.

Mais même quand il y a une de corrigée, avec des retards funestes, il y en a toujours au moins une qui prend le relais !

Je n'ai jamais vu XP sans au moins une faille critique connue non corrigée présente.

Ca n'est pas alors un thread malicieux, mais une faille dans un thread existant.
Le résultat de l'exploit d'un overflow dans T1, c'est justement d'en faire un T1 malicieux !


Quand à la séparation des privilèges avec des schedulers internes en userspace qui évitent les changements de contexte, c'est ridicule:

Démonstration par l'absurde. Supposons que ce soit possible.
On a alors les conséquences suivantes:

1. Cela nécessite le stockage de la threadID courante en userspace, pour pouvoir changer cet ID, donc il est modifiable par une thread T1 malicieuse du userspace.

2. Si tu veux protéger l'accès à cet ID par un segfault, alors il y aura passage en kernelspace à chaque scheduling d'une nouvelle tache.
Ce qui contredit l'hypothèse d'origine.
CQFD

Je te réponds en ajoutant un nouveau message tout en bas de la page.

Parce que toi tu sais lire ?

Microsoft Windows XP Professional with all vendor patches installed and all vendor workarounds applied, is currently affected by one or more Secunia advisories rated Highly critical

Il y aura moins d'exceptions à la procédure de codécision, d'après un document de l'assemblée nationale française (et le parlement européen a voté la constitution, ils ne sont pas maso quand-même ! ).

a le droit de s'asseoir sur les textes votés par un parlement élu,
En fait c'est surtout le conseil des ministres (qui sont des membres de chaque gouvernement national) qui codécide.
La commission est choisie par eux, avec validation du parlement. Parlement qui élira seul le président de la commission. Et qui peut faire tomber la commission quand il le désire.

Je ne suis pas enthousiaste. Il n'y a aucune innovation économique dans ce traité (je pense à la traçabilité des biens/services/capitaux, pour la lutte contre les sweatshops, la corruption et l'argent sale).

Mais je ne veux pas laisser inchangés les mauvais textes actuels en votant non ...

Et combien il y en a qui sont "highly critical" et qui ne sont pas corrigees ?
La question n'est pas combien. Une seule faille critique connue et exploitable suffit amplement à bousiller toute la sécurité d'un système.

Si tu arrives à créer un thread malicieux bravo.
Ce n'est pas plus dur de provoquer des overflows (et d'autres failles) dans un thread que dans un process !

Si ton privilège est sur un groupe ou un user et non sur le process,
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é. Et ça ne coute rien en CPU supplémentaire.

Si tu as envie de placer des signaux dans tous les sens pour protéger tes variables dans les threads, c'est possible.
T2 ne peut pas empêcher un T1 malicieux d'accéder à une variable privée de T2 avec un signal.

) 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.
En userspace, tu ne peux pas empêcher T1 de modifier les variables privées de T2 pour forcer T2 à utiliser R malicieusement.

on parlait de ressources partagées en utilisant les méccanismes kernels de séparation de privilèges
Il est évident que les shm permettent à 2 processus P1 et P2 de communiquer via des variables partagées tout en protégeant les variables privées de P1 et P2.
Par conséquent si P1 est malicieux, il ne pourra pas accéder aux variables privées de P2 pour détourner les privilèges de P2 sur la ressource R non partagée (par exemple R est un fichier accessible uniquement à P2).
Ceci étant ma définition (pas que la mienne) de séparation de privilèges. Un privilège étant, par définition, une ressource qui n'est pas partagée par tous.

Tu retrouves ce système de séparation (avec communications par shm ou pipes ou sockets) dans de nombreux softs Unix sécurisés.

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.

C'est sur que si tu veux des variables privées ET une protection granulaire kernel ET pas de syscall ca va être dur.
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.

Un syscall mutex ne permet absolument pas d'empecher les variables privées d'être accédées par une autre thread malicieuse.

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. Et juste après un syscall, la thread T1 peut modfier les données reçues du syscall par T2.

Aucun syscall ne peut permettre la séparation des privilèges pour les threads.

Highly critical , par définition, ça veut dire exploitable.
La plupart des gens sérieux qui proposent des failles à bugtraq/CVE/secunia mettent un point d'honneur à prouver que ce qu'ils disent est vrai en fournissant un exploit à qui le demande.
En l'absence d'un "proof of concept", une faille peut difficilement être considérée highly critical. A moins d'être particulièrement évidente. Ce qui n'est pas le cas quand il faut une "race condition" pour que la faille existe. Prouver que la race condition peut se produire dans la pratique, et pas seulement en théorie, est très difficile si on a pas un exploit à proposer.

Restons calme et poli, surtout quand on ne donne pas d'argument précis pour se justifier.

Puisque tu as parfaitement compris comment fonctionne SELinux (gestion de droits d'accès supplémentaires au moment de chaque syscall), 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.

Répond avec une argumentation précise, pas une insulte.

La bonne nouvelle c'est qu'on peut enregistrer deux threads d'un même process dans deux domaines différents.
Je ne sais pas si tu réalises à a quelle point cette protection serait foireuse !
Prenons le cas d'une thread T1 qui n'a pas accès à la ressource R à laquelle accède la thread T2 du même process. T1 n'a qu'à modifier la mémoire utilisée par T2 pour pouvoir accéder indirectement à R.

C'est catastrophique au niveau sécurité.

Il y a la notion de charge minimale contaminante qui entre en jeu: il faut souvent une quantité non négligeable de microbes pour que les premières défenses immunitaires (globules blancs deja fabriqués et imperméabilité naturelle de la peau ou des muqueuses) soient débordées. Peu probable avec un préservatif, même s'il laisse passer quelques petites molécules avec un débit forcément ultra réduit.

>On peut [échanger des données sans recopie, entre 2 entités avec des privilèges différents, avec un signal], mais c'est très con.
>>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)
Et tu appelles ça un échange de données sans recopie par le noyau ? Euh...

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.

Quand des process communiquent par shm, chacun peut avoir ses propres uid et gid.

un lock qui génère un sigsev si tu passes outre
Qui a parlé de lock qui génère un sigsegv ?
J'ai surtout parlé de variables privées qui génèrent des sigsegv dans les cas des process concurents utilisant shm. Toutes les variables qui ne sont pas dans le shm, pour être précis, sont donc privées et protégées par sigsegv.

Quasiment tous les locks de synchronisation pour accéder à des zones mémoires partagées dépendent de la bonne volonté des parties en présence, puisque si la ressource est vraiment partagée, les parties peuvent y accéder sans faire appel à une fonction de lock, et donc passer outre cette fonction de lock. La seule exception notable étant les locks des fichiers, que personne n'est obligé d'utiliser. Et quand je parle de shm, j'en parle au sens large, pas seulement au sens de shm_open qui associe les shm à des fichiers. Il y a aussi shmget et mmap(MAP_ANONYMOUS) qui n'obligent pas à se servir de fichiers.

Bref:
Les futex sont utilisables pour les shm sans compromettre les variables privées des process (évidemment !) . Ils ont d'ailleurs été pensés pour ça:
"while the addresses for the same memory in separate processes may not be equal, the kernel maps them internally so the same memory mapped in differ-
ent locations will correspond for futex calls."