Sur 32-bit, avec HIGHMEM ou non, la mémoire virtuelle par processus est limitée à 3B. Le dernier GB (à partir de l'adresse 0xc0000000) est mappé par le noyau, pour éviter de devoir flusher le TLB à chaque changement de contexte user mode/kernel mode.
Il existe un patch 2G/2G qui permet au noyau d'utiliser jusqu'à 2G de RAM sans HIGHMEM, mais n'est pas couramment utilisé.
Il exist(ait ?) aussi un split 4G/4G qui permettait d'utiliser jusqu'à 4G de mémoire, mais donc au prix d'un flush TLB à chaque changement de contexte.
C'est quoi ?
A mon avis il démarre dans un init qui ne démarre pas le réseau, d'où ton problème de résolution.
Démarre en init 3, en ajoutant "init 3" à la fin de ta ligne "boot" sous Grub.
Ainsi il n'y a aucune interaction possible entre les applications dans le display Xephyr et sous le compte utilisateur du navigateur et les applications de mon compte principal.
Ah, et si ton noyau est troué ?
Non, parce que ce n'est pas ce qui manque les failles locales menant à des élévations de privilège avec un noyau vanilla...
Il ne s'agit pas de hugepage, mais de plusieurs pages de 4K (sur x86).
Je viens de faire le test sur un 2.6.18, et c'est bien 64K.
Tu as refait le test avec un noyau récent ?
Attention, le comportement observé n'a rien avoir avec les buffer/page caches, c'est une histoire de bufferisation : avec la libc, il y a trois types de bufferisation :
- _IONBF : pas de bufferisation, on appelle tout de suite l'appel système write
- _IOLBF : bufferisation par ligne, on appelle write lorsqu'on rencontre '\n', utilisée par défaut lorsque le descripteur de fichier est lié à un tty (sauf stderr qui est _IONBF)
- _IOFBF : bufferisation complète, on bufferise jusqu'à ce que le buffer soit plein, utilisé par défaut pour les fichiers, les pipes, etc
Même sans bufferisation, une écriture via printf/fwrite n'entraine pas forcément un accès au disque, le noyau utilise le page cache pour des questions de performance. Pour forcer l'écriture sur disque (commit), il faut passer un un fflush pour flusher le buffer au niveau de la libc, mais aussi un fsync pour forcer un commit des données en cache.
Entre autres choses, la bufferisation au niveau de la libc permet de réduire le nombre d'appels systèmes, qui coutent cher.
La grosse différence c'est que tant qu'il y a des données bufferisées au niveau de la libc (FILE *), les modifications ne sont pas visibles par les autres processus. Par contre dès que write(2) est appelé, elles deviennent visibles.
Est-ce que la version de KDE intégrée à Squeeze est utilisable, en terme de ressources ?
Ce n'est pas un troll, mais mon pc n'est pas une bête de course, et cela me ferait chier de me retrouver avec KDE qui rame, alors que KDE 3.5 fonctionne parfaitement.
Je peux tojours rester avec Lenny, mais les mises à jour de sécurité ne dureront pas éternellement...
Un virus, c'est quand le programme a en plus une fonction de contamination d'ordinateur à ordinateur (ce qui n'est pas le cas ici).
Non, dans ce cas c'est un ver.
Un virus se contente d'infecter d'autres fichiers.
Faudra quand même sans doute revoir l'argument « c'est linux, donc il n'y a pas de virus ! » qui fait croire un peu facilement que tout est garanti sûr.
Jette un oeil aux travaux de Cohen par exemple, ça fait environ 30 ans qu'on a des résultats théoriques sur les virus, en gros tu peux en écrire pour n'importe quelle machine de Turing, et la détection est un problème indécidable.
Il n'y a qu'un idiot pour prétendre que Linux est immunisé aux virus et autres saloperies, par contre il est vrai qu'il y a moins de risques d'exploits, virus, vers, etc. Après si l'utilisateur exécute tout ce qui circule, et bien il ne faut pas pleurer...
de memoire, tu dois pouvoir forcer à syncrhoniser plus souvent le cache et les disques
Pour le commit des pages dirty sur disque, ça se modifie avec les sysctl vm.diry_ratio et vm.dirty_background_ratio.
J'essaye de jouer avec la swapiness et de vider le cache et ça a l'air de donner de bons résultats mais ce comportement anormal m'intrigue et ça reste un workaround pour maintenant mon serveur running.
C'est un comportement normal, après cela dépend de chaque cas d'utilisation. Si le noyau les swap, c'est que les pages ne sont pas utilisées souvent (algorithme de type LRU), donc autant utiliser la mémoire pour le page cache, c'est meilleur pour les performances. Là où ce genre de comportement pose problème, c'est pour des desktops, parce que l'interactivité en prend un coup (devoir re-charger OOO et firefox à cause d'un updatedb en background, c'est pas sympa).
Donc je te dirais que tu devrais laisser en l'état, sauf si tu as une bonne raison de changer le comportement par défaut.
Dans ce cas, tu pourrais abaisser la swappiness à 40 par exemple, avec diry_ratio à 10 et dirty_background_ratio à 5 (voire moins, mais trop bas c'est mauvais pour les performances).
Après, il faut le prendre avec des pincettes, cela ne veut absolument pas dire qu'un système est sécurisé, c'est juste une certification qui dépend de certains critères...
Tu noteras que tous les GPOS sont au niveau EAL4.
Quant à la remarque sur Linux, tu peux la prendre dans le sens où la sécurité n'a jamais été un des buts premiers du noyau, qui est plutôt axé sur les performances. Par exemple, il n'y a pas par défaut de protection du type W^X, pas de protection des stacks, l'entropie pour l'ASLR est assez faible, pas d'access crontrol, etc. Il n'y a pas de mesure de sécurité pro-active, ce qu'essaie de corriger grsec.
Personnellement, je trouve dommage que les développeurs principaux ne s'intéressent pas plus à la sécurité, on a quasiment toutes les semaines des failles, et pas mal de failles qui permettent à un utilisateur de passer root...
ps : le patch grsec, tu trouves pas qu'il fait un peu "démo", au final ?
(que toute la partie "configuration système" devrait être sortie d'un patch "noyau" ?)
Ah bon ?
Et pourquoi OpenBSD fait tourner la plupart de ses démons sous chroot par défaut ?
Je sais qu'il est facile de sortir d'un chroot lorsque le processus est root, mais lorsqu'il tourne en tant qu'user (fork, chroot, setuid...), ça permet déjà d'éviter toute une classe d'exploits (failles dans programmes setuid, symlinks dans /tmp/, etc). C'est certes plus faible qu'une jail FreeBSD, mais c'est déjà un début. Après, si ton noyau est troué, c'est un autre problème...
Tu as des arguments qui auraient pu justifier de laisser les banques faire faillites, avec notamment tous les particuliers qui perdent les économies qu'ils y avaient placés ?
Oui, un argument qui fait ses preuves depuis des milliards d'années : la sélection naturelle.
Renflouer des banques ou des entreprises qui ont des comportements irresponsables les encourage dans cette voie : pourquoi se réformer, se restructurer si l'état garantit de toute façon les pertes ? C'est valable pour les états comme pour les banques, et les particuliers.
Pour éviter de perdre ses économies, il y a un moyen simple : le solde d'un compte en banque, c'est juste un chiffre, c'est immatériel. Investis dans l'or, l'immobilier, etc. Sans compter qu'il existe des banques responsables, mais il faut bien réaliser qu'elles sont rares étant donné la façon dont on encourage les prises de risque inconsidérées...
J'ai toujours du mal à comprendre ce point que je relis régulièrement un peu partout. Ca te déplaît que l'état fasse un placement sans risque à 8% qui a rapporté à l'état 450 M€ ?
Certes, les intérêts ont rapporté 450M€. Je vais passer sur l'aspect moral de la chose, ce n'est pas la question. Mais combien leur comportement irresponsable nous a-t-il coûté ? Des milliards ? Des dizaines de milliards ?
Quand au placement sans risque, on nous serine la même chose au sujet du fonds de soutien européen, on a même des comiques de gauchistes qui ont crié au scandale car le taux du prêt accordé à la Grèce est plus élevé que le taux auquel nous empruntons. Sauf qu'il y a une chance non négligeable que nous ne revoyons jamais cet argent.
Moi, ce que je ne comprends pas, c'est pourquoi on s'entête à sauver des industries ou des états dont la situation économique catastrophique n'est pas due, comme on essaie de nous le faire croire, à la crise, mais bien à des dysfonctionnements structurels. C'est bien beau de pousser à la consommation et à l'endettement, sauf que ce n'est pas viable. Le mérite de la crise aura été de le mettre en exergue.
Effectivement, il vaudrait mieux garder ça hors du noyau.
Pourquoi ?
Parce qu'aujourd'hui la solution proposée est basée sur les ttys, mais demain on aura sûrement de meilleurs heuristiques pour la création de cgroups.
De façon plus générale, la tendance générale est d'implémenter les mécanismes dans le noyau, mais de laisser la politique au mode utilisateur, tout simplement parce qu'il est beaucoup plus simple et moins risqué d'avoir du code en mode utilisateur qu'en mode noyau.
Penser par exemple à udev, CPU governor, routage multicast, etc. Bien évidemment, pour des raisons de performances, on peut laisser une politique minimale dans le noyau, par exemple pour le module bonding, netfilter, etc.
ENFIN une chance que la souris ne rame plus quand une appli alakon fout le dawa.
Sauf que ce patch ne change rien à ce cas : sans le patch, tu as ton appli qui "fout le dawa", tu lances un autre processus, chacun aura 50% du temps processeur (sauf s'il y a une niceness). Avec le patch, chacun aura aussi 50% du temps processeur. Le patch crée implicitement des groupes en se basant sur le tty associé au processus, c'est tout. Donc à moins que ton processus n'ait une dizaine de threads qui "foutent le dawa", ça ne va rien changer.
Pour ce qui est de l'inclusion, on peut imaginer que cette option soit activée en mode CONFIG_PRREMPT (low latency desktop).
Je n'ai jamais eu de problème de latence (sur un desktop) à cause d'un processus qui monopolise le CPU.
Lorsqu'on a des latences observables, c'est très rarement l'ordonnenceur qui est en cause, mais beaucoup plus souvent l'ordonnenceur d'E/S ou une consommation trop importante de mémoire, et donc utilisation du swap.
Dans l'absolu, c'est le même principe, sauf que là les priorités sont ajustées automatiquement, alors qu'avec nice il faut les fixer manuellement, et la valeur idéale dépend du nombre de processus (par groupe et total). De plus, une niceness élevée implique un time slice faible, et donc une perte de CPU (context switch, ordonnencement). Mais effectivement, on devrait pouvoir arriver plus ou moins au même résultat avec un nice 19...
Parce que, comme expliqué, il n'y a pas d'infrastructure physique sous-jacente.
Le wifi c'est super, sauf que :
- on n'a pas assez de canaux
- ce n'est pas avec ça que tu vas traverser l'Atlantique
- ca impose que ton next hop soit à portée wifi
Donc je te laisse imaginer le nombre de hops pour joindre un autre pays, il va falloir passer le TTL sur 32 bits (et ton ping va se compter en secondes).
Cela ne peut pas passer à l'échelle d'Internet, je suis sûr qu'ils s'amusent bien dans leur campus, mais ce n'est rien d'autre qu'un projet de laboratoire...
Ca ne fonctionnera pas sur un binaire setuid, pour d'évidentes raisons de sécurité.
LD_PRELOAD permet de remplacer les appels aux bibliothèques, (pas les appels systèmes, mais comme la plupart des appels systèmes ont des wrappers...), ce qui est utile non seulement à un attaquant, mais aussi pour tracer, introduire des erreurs aléatoires (par exemple lors d'un appel à malloc), tracer l'occupation mémoire, et ce genre de choses.
D'autant plus que pour capturer le trafic (avec libpcap), l'exécutable doit tourner en tant que root (on peut se restreindre à CAP_NET_ADMIN et CAP_NET_RAW, mais en regardant vite fait le code j'ai l'impression qu'il vérifie un euid = 0).
Après je ne connais pas le fonctionnement précis, mais l'idée d'un module Firefox qui tourne en tant que root, j'aime moyen.
Sinon, ça fonctionne aussi avec un réseau sécurisé, tant qu'on est authentifié (mais il faut de toute façon que la carte wifi supporte le mode promiscuous, ce qui n'était pas toujours le cas il y a quelques années...).
[^] # Re: Question bête…
Posté par neologix . En réponse au message Erreur "Cannot allocate memory" généralisée. Évalué à 1.
Il existe un patch 2G/2G qui permet au noyau d'utiliser jusqu'à 2G de RAM sans HIGHMEM, mais n'est pas couramment utilisé.
Il exist(ait ?) aussi un split 4G/4G qui permettait d'utiliser jusqu'à 4G de mémoire, mais donc au prix d'un flush TLB à chaque changement de contexte.
# mode sans échec ?
Posté par neologix . En réponse au message Problemes apres passage a squeeze. Évalué à 1.
A mon avis il démarre dans un init qui ne démarre pas le réseau, d'où ton problème de résolution.
Démarre en init 3, en ajoutant "init 3" à la fin de ta ligne "boot" sous Grub.
[^] # Re: Un peu plus d'informations
Posté par neologix . En réponse au journal Virus autorun sous Linux par l'exemple. Évalué à 2.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4527
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4656
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4346
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4258
Ils sont toujours "under review", mais cherche 2 minutes sur Google et tu verras que ce n'est pas ce qui manque (cherche par exemple Brad Spengler).
[^] # Re: Un peu plus d'informations
Posté par neologix . En réponse au journal Virus autorun sous Linux par l'exemple. Évalué à 2.
Ah, et si ton noyau est troué ?
Non, parce que ce n'est pas ce qui manque les failles locales menant à des élévations de privilège avec un noyau vanilla...
[^] # Re: Understanding the linux Kernel
Posté par neologix . En réponse au message Pipe et hugepage. Évalué à 3.
Je viens de faire le test sur un 2.6.18, et c'est bien 64K.
Tu as refait le test avec un noyau récent ?
[^] # Re: simple
Posté par neologix . En réponse au message Écriture différée de &> log. Évalué à 8.
- _IONBF : pas de bufferisation, on appelle tout de suite l'appel système write
- _IOLBF : bufferisation par ligne, on appelle write lorsqu'on rencontre '\n', utilisée par défaut lorsque le descripteur de fichier est lié à un tty (sauf stderr qui est _IONBF)
- _IOFBF : bufferisation complète, on bufferise jusqu'à ce que le buffer soit plein, utilisé par défaut pour les fichiers, les pipes, etc
Même sans bufferisation, une écriture via printf/fwrite n'entraine pas forcément un accès au disque, le noyau utilise le page cache pour des questions de performance. Pour forcer l'écriture sur disque (commit), il faut passer un un fflush pour flusher le buffer au niveau de la libc, mais aussi un fsync pour forcer un commit des données en cache.
Entre autres choses, la bufferisation au niveau de la libc permet de réduire le nombre d'appels systèmes, qui coutent cher.
La grosse différence c'est que tant qu'il y a des données bufferisées au niveau de la libc (FILE *), les modifications ne sont pas visibles par les autres processus. Par contre dès que write(2) est appelé, elles deviennent visibles.
# KDE 4
Posté par neologix . En réponse au journal Debian Squeeze en février ?. Évalué à 1.
Ce n'est pas un troll, mais mon pc n'est pas une bête de course, et cela me ferait chier de me retrouver avec KDE qui rame, alors que KDE 3.5 fonctionne parfaitement.
Je peux tojours rester avec Lenny, mais les mises à jour de sécurité ne dureront pas éternellement...
[^] # Re: Deux questions
Posté par neologix . En réponse au message Deux questions sur le shell. Évalué à 6.
Par contre 'source' n'est pas POSIX, contrairement à '.'.
[^] # Re: Je cite Reuters
Posté par neologix . En réponse au journal Android et virus. Évalué à 7.
Non, dans ce cas c'est un ver.
Un virus se contente d'infecter d'autres fichiers.
Faudra quand même sans doute revoir l'argument « c'est linux, donc il n'y a pas de virus ! » qui fait croire un peu facilement que tout est garanti sûr.
Jette un oeil aux travaux de Cohen par exemple, ça fait environ 30 ans qu'on a des résultats théoriques sur les virus, en gros tu peux en écrire pour n'importe quelle machine de Turing, et la détection est un problème indécidable.
Il n'y a qu'un idiot pour prétendre que Linux est immunisé aux virus et autres saloperies, par contre il est vrai qu'il y a moins de risques d'exploits, virus, vers, etc. Après si l'utilisateur exécute tout ce qui circule, et bien il ne faut pas pleurer...
[^] # Re: GCC : goto en assembleur
Posté par neologix . En réponse à la dépêche Sortie de la version 2.6.37 du noyau Linux. Évalué à 1.
Bien sûr, il ne supporte pas autant d'architectures que GCC...
# TCP window scaling
Posté par neologix . En réponse au message mandriva 2010.1 wifi + certain site inaccessible. Évalué à 1.
# sysctl -w net.ipv4.tcp_window_scaling=0
Sinon, ça peut être dû à l'IPv6.
# Jessica Alba
Posté par neologix . En réponse au journal [cinéma] Machete. Évalué à 1.
# Konqueror
Posté par neologix . En réponse à la dépêche Prolongation du concours LinuxFr.org. Évalué à 1.
[^] # Re: contenu du cache => en partie les gestions de fichiers ouverts et au
Posté par neologix . En réponse au message Probleme de cache et de swap. Évalué à 5.
Pour le commit des pages dirty sur disque, ça se modifie avec les sysctl vm.diry_ratio et vm.dirty_background_ratio.
J'essaye de jouer avec la swapiness et de vider le cache et ça a l'air de donner de bons résultats mais ce comportement anormal m'intrigue et ça reste un workaround pour maintenant mon serveur running.
C'est un comportement normal, après cela dépend de chaque cas d'utilisation. Si le noyau les swap, c'est que les pages ne sont pas utilisées souvent (algorithme de type LRU), donc autant utiliser la mémoire pour le page cache, c'est meilleur pour les performances. Là où ce genre de comportement pose problème, c'est pour des desktops, parce que l'interactivité en prend un coup (devoir re-charger OOO et firefox à cause d'un updatedb en background, c'est pas sympa).
Donc je te dirais que tu devrais laisser en l'état, sauf si tu as une bonne raison de changer le comportement par défaut.
Dans ce cas, tu pourrais abaisser la swappiness à 40 par exemple, avec diry_ratio à 10 et dirty_background_ratio à 5 (voire moins, mais trop bas c'est mauvais pour les performances).
[^] # Re: chroot
Posté par neologix . En réponse au message Compte utilisateur avec droits TRES restreints. Évalué à 5.
En quelques mots, ce que tu en penses, et comment tu définis cette "catégorie sécurisée" (par exemple avec un pointeur vers des normes)
Par exemple :
http://en.wikipedia.org/wiki/Evaluation_Assurance_Level
Après, il faut le prendre avec des pincettes, cela ne veut absolument pas dire qu'un système est sécurisé, c'est juste une certification qui dépend de certains critères...
Tu noteras que tous les GPOS sont au niveau EAL4.
Quant à la remarque sur Linux, tu peux la prendre dans le sens où la sécurité n'a jamais été un des buts premiers du noyau, qui est plutôt axé sur les performances. Par exemple, il n'y a pas par défaut de protection du type W^X, pas de protection des stacks, l'entropie pour l'ASLR est assez faible, pas d'access crontrol, etc. Il n'y a pas de mesure de sécurité pro-active, ce qu'essaie de corriger grsec.
Personnellement, je trouve dommage que les développeurs principaux ne s'intéressent pas plus à la sécurité, on a quasiment toutes les semaines des failles, et pas mal de failles qui permettent à un utilisateur de passer root...
ps : le patch grsec, tu trouves pas qu'il fait un peu "démo", au final ?
(que toute la partie "configuration système" devrait être sortie d'un patch "noyau" ?)
Comprends pas la question. Tu parles du RBAC ?
[^] # Re: chroot
Posté par neologix . En réponse au message Compte utilisateur avec droits TRES restreints. Évalué à 6.
Et pourquoi OpenBSD fait tourner la plupart de ses démons sous chroot par défaut ?
Je sais qu'il est facile de sortir d'un chroot lorsque le processus est root, mais lorsqu'il tourne en tant qu'user (fork, chroot, setuid...), ça permet déjà d'éviter toute une classe d'exploits (failles dans programmes setuid, symlinks dans /tmp/, etc). C'est certes plus faible qu'une jail FreeBSD, mais c'est déjà un début. Après, si ton noyau est troué, c'est un autre problème...
[^] # Re: Banques
Posté par neologix . En réponse au journal Éloge du don. Évalué à 3.
Oui, un argument qui fait ses preuves depuis des milliards d'années : la sélection naturelle.
Renflouer des banques ou des entreprises qui ont des comportements irresponsables les encourage dans cette voie : pourquoi se réformer, se restructurer si l'état garantit de toute façon les pertes ? C'est valable pour les états comme pour les banques, et les particuliers.
Pour éviter de perdre ses économies, il y a un moyen simple : le solde d'un compte en banque, c'est juste un chiffre, c'est immatériel. Investis dans l'or, l'immobilier, etc. Sans compter qu'il existe des banques responsables, mais il faut bien réaliser qu'elles sont rares étant donné la façon dont on encourage les prises de risque inconsidérées...
[^] # Re: Banques
Posté par neologix . En réponse au journal Éloge du don. Évalué à 10.
Certes, les intérêts ont rapporté 450M€. Je vais passer sur l'aspect moral de la chose, ce n'est pas la question. Mais combien leur comportement irresponsable nous a-t-il coûté ? Des milliards ? Des dizaines de milliards ?
Quand au placement sans risque, on nous serine la même chose au sujet du fonds de soutien européen, on a même des comiques de gauchistes qui ont crié au scandale car le taux du prêt accordé à la Grèce est plus élevé que le taux auquel nous empruntons. Sauf qu'il y a une chance non négligeable que nous ne revoyons jamais cet argent.
Moi, ce que je ne comprends pas, c'est pourquoi on s'entête à sauver des industries ou des états dont la situation économique catastrophique n'est pas due, comme on essaie de nous le faire croire, à la crise, mais bien à des dysfonctionnements structurels. C'est bien beau de pousser à la consommation et à l'endettement, sauf que ce n'est pas viable. Le mérite de la crise aura été de le mettre en exergue.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par neologix . En réponse à la dépêche Patch pour le noyau Linux améliorant l'interactivité entre les applications console et Xorg. Évalué à 5.
Pourquoi ?
Parce qu'aujourd'hui la solution proposée est basée sur les ttys, mais demain on aura sûrement de meilleurs heuristiques pour la création de cgroups.
De façon plus générale, la tendance générale est d'implémenter les mécanismes dans le noyau, mais de laisser la politique au mode utilisateur, tout simplement parce qu'il est beaucoup plus simple et moins risqué d'avoir du code en mode utilisateur qu'en mode noyau.
Penser par exemple à udev, CPU governor, routage multicast, etc. Bien évidemment, pour des raisons de performances, on peut laisser une politique minimale dans le noyau, par exemple pour le module bonding, netfilter, etc.
[^] # Re: Testé et approuvé ;)
Posté par neologix . En réponse au journal Noël, noël, un patch miraculeux !. Évalué à 6.
Sauf que ce patch ne change rien à ce cas : sans le patch, tu as ton appli qui "fout le dawa", tu lances un autre processus, chacun aura 50% du temps processeur (sauf s'il y a une niceness). Avec le patch, chacun aura aussi 50% du temps processeur. Le patch crée implicitement des groupes en se basant sur le tty associé au processus, c'est tout. Donc à moins que ton processus n'ait une dizaine de threads qui "foutent le dawa", ça ne va rien changer.
Pour ce qui est de l'inclusion, on peut imaginer que cette option soit activée en mode CONFIG_PRREMPT (low latency desktop).
Je n'ai jamais eu de problème de latence (sur un desktop) à cause d'un processus qui monopolise le CPU.
Lorsqu'on a des latences observables, c'est très rarement l'ordonnenceur qui est en cause, mais beaucoup plus souvent l'ordonnenceur d'E/S ou une consommation trop importante de mémoire, et donc utilisation du swap.
[^] # Re: Testé et approuvé ;)
Posté par neologix . En réponse au journal Noël, noël, un patch miraculeux !. Évalué à 4.
[^] # Re: Mouahaha
Posté par neologix . En réponse à la dépêche Une alternative à Internet : Netsukuku. Évalué à 2.
Le wifi c'est super, sauf que :
- on n'a pas assez de canaux
- ce n'est pas avec ça que tu vas traverser l'Atlantique
- ca impose que ton next hop soit à portée wifi
Donc je te laisse imaginer le nombre de hops pour joindre un autre pays, il va falloir passer le TTL sur 32 bits (et ton ping va se compter en secondes).
Cela ne peut pas passer à l'échelle d'Internet, je suis sûr qu'ils s'amusent bien dans leur campus, mais ce n'est rien d'autre qu'un projet de laboratoire...
[^] # Re: Reiserfs
Posté par neologix . En réponse à la dépêche Première bêta du Debian-Installer de la prochaine version stable de Debian. Évalué à 3.
Ca se configure avec tune2fs (-c et -i), cela n'est en rien inhérent au système de fichier...
# quelques détails
Posté par neologix . En réponse à la dépêche Sortie de force_bind version 0.4. Évalué à 2.
LD_PRELOAD permet de remplacer les appels aux bibliothèques, (pas les appels systèmes, mais comme la plupart des appels systèmes ont des wrappers...), ce qui est utile non seulement à un attaquant, mais aussi pour tracer, introduire des erreurs aléatoires (par exemple lors d'un appel à malloc), tracer l'occupation mémoire, et ce genre de choses.
[^] # Re: Firesheep
Posté par neologix . En réponse à la dépêche Firesheep. Évalué à 3.
Après je ne connais pas le fonctionnement précis, mais l'idée d'un module Firefox qui tourne en tant que root, j'aime moyen.
Sinon, ça fonctionne aussi avec un réseau sécurisé, tant qu'on est authentifié (mais il faut de toute façon que la carte wifi supporte le mode promiscuous, ce qui n'était pas toujours le cas il y a quelques années...).