GuiGui's Show

Il y a tellement de mises en prod' le vendredi à 16h un peu partout que ça ne veut plus rien dire le "ho noooon on ne met rien en prod' le vendredi". M'enfin bref ...

« J'utilise ici le terme “hacking” dans son sens noble: Comprendre le fonctionnement et modifier pour l'adapter à ses besoins.

Je vais donc décrire ici la manière d'examiner et modifier une application Android (fichier .apk). La motivation est double:
    - S'amuser à bidouiller et comprendre le fonctionnement des applications (en particulier le code machine Dalvik d'Android).
    - Protéger sa vie privée en coupant certaines fonctionnalités des applications (géolocalisation, etc.) »

« Multiple security issues have been found in Iceweasel, Debian's version of the Mozilla Firefox web browser: Multiple memory safety errors, buffer overflows, use-after-frees and other implementation errors may lead to the execution of arbitrary code, denial of service, the bypass of the same-origin policy or a loss of privacy.

[...]

In addition, this update also disables SSLv3. »

Jusque là c'est parfaitement légitime.

« This update updates Iceweasel to the ESR31 series of Firefox. The new release introduces a new user interface. »

WTF ?! Pardon ?! O_O Depuis quand une security update s'occupe d'autre chose que de sécurité ?! Une mise à jour de sécurité doit corriger les failles détectées, un point c'est tout. C'est ça pour moi, l'une des qualités de Debian stable : la production ne pète pas à la tronche de l'adminsys ! Quand bien même c'est l'interface graphique d'un des logiciels que j'utilise le plus sur mes machines hors prod'. Que j'apprécie ou pas l'interface Australis de Firefox n'entre pas en ligne de compte dans cette histoire. J'imagine qu'il y a une raison derrière (comme par exemple que la team Debian Security avait annoncé qu'elle n'allait plus s'occuper des navigateurs web car c'trop le bordel) mais quand même, je suis très déçu de voir ça.


ÉDIT du 01/11/2014 à 16h25 : même chose aujourd'hui avec le DSA 3061-1 sur Icedove :
« Multiple security issues have been found in Icedove

[...]

This update updates Iceweasel to the ESR31 series of Thunderbird. In addition Enigmail was updated to version 1.7.2-1~deb7u1 to ensure compatibility with the new upstream release.

Mozilla implemented TLS 1.2 in NSS version 3.15.1 and Thunderbird 31.0 uses this as the default. It won't fall back to older protocol versions.

This means every connection from Thunderbird/Icedove to a mail server will using TLS 1.2 with no fall back if you have configured TLS/SSL or STARTTLS for your connections. »

D'après mes tests, ce n'est pas aussi disruptif que ça en a l'air : en désactivant TLSv1.2 dans smtpd de Postfix, Icedove (configuré pour utiliser STARTTLS) accepte de négocier TLSv1.1 (cf le log Postfix :  « TLS connection established from <lala>: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) »). En désactivant TLSv1.2 et TLSv1.1, Icedove accepte de négocier TLSv1.0 . Je n'ai pas pu tester la partie IMAP/STARTTLS puisque Dovecot permet seulement de désactiver SSLv2, SSLv3 et TLSv1.  FIN DE L'ÉDIT.


ÉDIT du 08/12/2014 à 20h25 : même chose aujourd'hui avec Icedove qui ne supporte plus SSLv3 : « Due to the  BEAST vulnerability Icedove does not support SSLv3 encrypted connections by default any longer. ». C'est une bonne chose en soi mais est-ce à une màj de sécurité annoncée pour autre chose (cf le DSA ne parle pas de cette désactivation de SSLv3) de faire ce choix ? Par ailleurs, BEAST concerne aussi TLSv1.0 quand des ciphers CBC sont utilisés donc l'argument est un peu moisi ...  FIN DE L'ÉDIT.

POODLE, tout comme Heartbleed en son temps, fait couler beaucoup d'octets dans les internets ces derniers jours. Je vais donner mon avis sur ce que je pense être un effet de mode et surtout, une précipitation.

Disclaimer :
    1) Je ne suis pas un security guru.
    2) Ce que je vais dire s'applique dans le cadre de petits serveurs (auto-hébergés ou non) sans trop de trafic et sans contrainte. J'veux dire que je ne tiendrais pas le même discours s'il s'agissait du site web d'une banque ou d'un site web d'e-commerce ou d'un site web à très fort trafic (sur la partie ECDSA versus RSA). On constate d'ailleurs que, dans ces contextes-là, la réalité est toute autre que celle que je vais décrire car il y a le côté opérationnel à prendre en compte : https://imirhil.fr/ssl.html ;)


Commençons par POODLE (voir, entre autres http://seenthis.net/messages/302666) : il s'agit d'une faille dans le protocole SSLv3, pas d'un bug dans une implémentation particulière (comme OpenSSL). Ça m'en touche une sans faire bouger l'autre dans le sens où TLSv1.0 c'est so 1999 et que SSL est déprécié depuis fort longtemps. C'est un problème humain (adminsys consciencieux) et opérationnel (gérer les vieux clients dans certains contextes comme banques/e-commerce, frilosité au changement, ...). Sur nos petits serveurs persos, ça devrait être désactivé sans soucis à moins que les parts de marché d'IE6, 3,8 % au niveau mondial et 0.8 % en France en septembre 2014 revendiquées par Microsoft (https://www.modern.ie/en-us/ie6countdown), la réalité doit être légèrement supérieure ainsi que des appliances/automates proprios désuets ne vous intéressent. Après si le raffut inutile de ces derniers jours permet des  prises de conscience, pourquoi pas ...




L'ennui, c'est que je vois, principalement sur IRC, des adminsys se questionner sur la conf' TLS de leurs logiciels serveurs, ce qui est une bonne chose comme je viens de le dire, mais en poussant le vice trop loin. Mon plus grand conseil sera le suivant : gardez la raison, ne faites pas n'importe quoi, n'affaiblissez pas vos confs en croyant les renforcer. La sécurité dans l'urgence ne marche jamais. N'écoutez pas aveuglément toutes les ressources sur le web, n'écoutez pas aveuglément un validateur quand bien même il est aussi bien foutu que celui de ssllabs (https://www.ssllabs.com/ssltest/) ! À ce sujet, voir, par exemple, l'illustration avec BEAST : https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat - « Unfortunately, the only way to mitigate the BEAST attack is to enforce the use of RC4 suites whenever TLS 1.0 and earlier protocols are used (which is most of the time at this point). I say "unfortunately", because very shortly after we had started requiring server-side mitigations, new research about RC4 came out and we found out that this cipher was much weaker than previously thought. The weaknesses were not of immediate concern, but it was clear that RC4 was on the way out. » :)


Parmi ces questionnements, on retrouve les questions liées au résultat du test (ssllabs ou autre) et des débats plus profonds : ECDSA ou RSA ? SHA-1 ou SHA256 pour condenser mon certificat ? Quelle liste d'algorithmes cryptographiques autoriser ? Je déploie DANE, HSTS et compagnie ? ... C'est un vice de raisonnement, à mon humble avis. La priorité, ce n'est pas de passer en ECDSA comme si RSA vivait ses derniers instants ou de passer immédiatement à SHA256 pour condenser son certificat ou de passer à RSA 4096 bits au lieu de 2048 bits parce qu'un validateur vous l'a *conseillé* (« When renewing, ensure [...] »). L'important à l'heure actuelle, à mon humble avis, et ça sera mon deuxième grand conseil, c'est de garder la confiance et pour ça, de ne pas générer d'erreurs du côté de l'utilisateur et pour ça, de ne pas casser vos certificats x509 et les configurations de vos logiciels serveurs. On corrige donc les failles bien actuelles comme Poddle et, si l'on en a la motivation, on durcit la conf' TLS de ses logiciels serveurs en douceur.


Je vais quand même donner mon avis sur ces questionnements, ça serait idiot de dénigrer au lieu de guider.
    - Courbes elliptiques (ECDSA) versus RSA : c'est un débat théorique qui amuse les cryptologues mais ça n'a aucune réalité pratique. Les limites de la cryptographie interviennent sur des choses beaucoup plus connes et concrètes (générateur de nombres pseudos aléatoires pas assez aléatoires, bug logiciel, cryptographie mal utilisée (de la crypto avec IE6 sous XP, comment dire ...), ...) Les deux procédés sont toujours d'actualité. Le seul argument de plus en faveur des courbes elliptiques est leur faible taille (à niveau de sécurité jugé équivalent) et des temps de traitement plus courts donc une montée en charge des sessions TLS avec de nombreux clients facilitée. Les algos ECDHE-* sont moins gourmands que leurs homologues DHE-*. Sur des serveurs persos, ce gain n'a pas d'intérêt. Ce n'est pas pour autant que je crache sur ECDSA. Quant à utiliser les courbes elliptiques dans les certificats x509, le gain est encore moins évident : la validation du certificat se fait au début de la session TLS, pas en continu et sur le client (usage standard). Ne cassez pas vos certificats actuels parce qu'on vous a dit que RSA c'est fini à cause de POODLE, ça serait contre-productif !


    - SHA-1 / SHA256 comme fonction de condensation dans les certificats x509. SHA-1 sera peut-être dans les prochains algos cryptographiques à tomber donc il faut préparer la migration vers mieux (SHA256) mais, pour l'instant, on n'a aucune attaque efficace et imminente contre SHA-1.  Alors oui, je sais, le méchant Google a annoncé qu'ils vont favoriser de pas beaucoup les sites web accessibles en HTTPS puis qu'ils vont virer SHA-1 à eux tous seuls (voir : http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html) ... Tout ça pour se racheter suite aux révélations de Snowden, ce qu'il ne faut pas faire. :)

        1) On ne panique pas et je ne suis pas seul à tenir ce discours :  https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know . De plus, Google vont pénaliser d'abord les certificats auto-signés, ne nous faisons pas d'illusions donc SHA-1 versus SHA256, ça se place là dans l'ordre des priorités quoi.
        2) Google est-il vraiment indispensable pour la survie de nos sites web persos pas monétisés ?
        3) On regarde les certificats des AC (oui, toute la chaîne de confiance doit être SHA256, pas que les certificats finaux, sinon c'est stupide) présents dans le magasin de certificats Debian (ça serait pareil avec celui de Mozilla, juste ce check s'automatise bien) et on voit que la messe est dite :
                Total : 960 - 100 %
                        md5 (/!\ depuis le temps que MD5 est *mort* ce qui n'est même pas encore le cas de SHA-1)  : 66 - ~ 7 %
                        sha1 : 744 - 77,5 %
                        sha256 : 114 - ~ 12 %
                        sha384 : 36 - 3,75 %

        Donc, passer à SHA256 lors du prochain renouvellement normal de votre certificat (car il va expirer), c'est une bonne idée, bien sûr. Dans le contexte actuel, crise/peur (avérée ou imaginée, ça revient au même), c'est une mauvaise idée pour si peu : maintenir la confiance est primordiale (surtout avec les certificats autosignés ou AC autosignée) comme je l'ai écrit plus haut.


    - Je pense le plus grand bien de DANE (voir http://shaarli.guiguishow.info/?y6WIyg) mais déployons déjà DNSSEC (qui est un pré-requis) convenablement, avec des procédures (roulement des clés) éprouvées et on pourra ensuite se mettre à DANE. Il n'y a aucun serveur/client dans sa branche stable (au sens Debian, lala :D) qui utilise ces enregistrements donc rien ne presse : le gain de sécurité ne sera pas imminent. Mais là encore, ajouter ça sur sa TODO des choses à faire à moyen terme est une bonne idée.


    - HSTS (voir : http://www.bortzmeyer.org/6797.html) est encore une bonne idée. Mais réfléchissez bien avant de déployer : la configuration doit être parfaite car la moindre erreur est bloquante et mise en cache quand on active HSTS ! Par ailleurs, les certificats autosignés génèrent des erreurs donc ça va plutôt mal se passer avec HSTS.


    - Faut-il tuner le cache des sessions TLS ? S'il n'y a aucun inconvénient à l'activer, Il faut mesurer le gain d'aller le tuner finement. Sur un service avec 10 connexions (css/images inclues pour un site web) par tranche de 30 mns, bof, le cache va pas servir des masses donc aller tuner ça comme pour un site à fort trafic, c'est sans grand intérêt, àmha, autant se reposer sur les paramètres par défaut des logiciels serveurs. Sur un serveur mail, avec la concentration des acteurs, l'abonnement à des ML, ... ça se justifie déjà plus mais stay relax quand même. :D




Pour les confs TLS de mes logiciels (elles sont disponibles à la fin de ce shaarli et valent ce qu'elles valent), je me base sur ces ressources déjà pointées dans d'autres de mes shaarlis :
    - Conf' « SSL/TLS » par Benjamin Sonntag à Il était une fois Internet. Les configurations présentées après un exposé plus général sont détaillées et expliquées. http://confs.fr/ssltls-benjamin-sonntag/
    - Pour des configurations clé en main de logiciels serveurs courants et une liste d'algorithmes à privilégier (attention, Mozilla, ça peut être biaisé pour garder la compatibilité avec les anciennes versions de Firefox/Thunderbird/autre) : https://wiki.mozilla.org/Security/Server_Side_TLS


Enfin, àmha, la priorité (en général, pas POODLE), ce n'est pas tellement nos petits serveurs web qui servent des sites web à contenu informatif (donc pas e-commerce / banque / dépôt de  données personnelles / contenu "sensible" où sensible se défini du point de vue du visiteur, pas du nôtre). Non, la priorité c'est nos serveurs mails (SMTP *ET* IMAP) et nos serveurs XMPP (C2S et S2S). C'est là qu'est le vrai contenu privé que l'on veut protéger. D'ailleurs, pour tester la conf' TLS votre serveur XMPP, voir : http://shaarli.guiguishow.info/?AKSlXA .

Donc, pour résumer : -SSLv2/-SSLv3, -RC4 (oui, je sais, BEAST mais sur nos petits serveurs persos, je pense qu'on peut ignore l'usage de TLSv1.0), +PFS (Perfect Forward Secrecy, confidentialité persistante, les échanges sécurisés précédant une compromission d'une clé privée ne sont pas eux-mêmes compromis et restent donc secrets. Donc Diffie-Hellman éphémère donc algos DHE-*, ECDHE-*) et on se relaxe. \o/




Les configurations TLS de mes logiciels serveurs :

ÉDIT DU 03/01/2016 À 23H00 : J'ai mis à jour ces configs avec les dernières directives de configuration disponibles dans les versions packagées dans Debian GNU/Linux Jessie. FIN DE L'ÉDIT.

Apache2 :
    SSLEngine on
   
    SSLCertificateFile    /etc/apache2/ssl/viki.crt
    SSLCertificateKeyFile /etc/apache2/ssl/viki.key

    SSLProtocol All -SSLv2 -SSLv3
       
    SSLCipherSuite ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
    SSLHonorCipherOrder on

    # Par defaut
    SSLCompression off
    SSLSessionCacheTimeout 300

    # Parametres DH - Ils sont auto generes selon la taille de la cle
    # utilisee. Si l'on veut des dhparam personnalises, cela necessite
    # openssl 1.0.2 pas encore dans Jessie ou de les concat a la fin du
    # fichier contenant le certif x509 aka c'est crade...
    # SSLOpenSSLConfCmd DHParameters "/etc/apache2/ssl/dh_4096.pem"

    # Cache partages des sessions TLS : mod_socache_* sont necessaires
    # mais pas encore dispo dans Debian stable (01/02/2014)
    # Un cache partages des sessions TLS ne se justifie pas ici :
    # contenu simple : pas besoin de plusieurs connexions simultanees
    # et utilisateurs qui ne reviennent pas dans des delais brefs, en majorite




nginx :
    ssl on;

    ssl_certificate /etc/nginx/ssl/pokedex.crt;
    ssl_certificate_key /etc/nginx/ssl/pokedex.key;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    ssl_ciphers ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM;
    ssl_prefer_server_ciphers on;

    # Compression TLS desactivee par defaut dans nginx

    # Parametres DH
    ssl_dhparam /etc/nginx/ssl/dh2048.pem;

    # Par defaut
    ssl_session_timeout 5m;

    # Un cache partages des sessions TLS ne se justifie pas ici :
    # contenu simple : pas besoin de plusieurs connexions simultanees
    # et utilisateurs qui ne reviennent pas dans des delais brefs, en majorite




Dovecot :
    ssl = required

    ssl_cert = </etc/postfix/ssl/pokedex.crt
    ssl_key = </etc/postfix/ssl/pokedex.key

    ssl_protocols = !SSLv2 !SSLv3

    ssl_cipher_list = ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
    ssl_prefer_server_ciphers = yes

    # Parametres DH. 4096 bits dans cet exemple car
    # ca correspond a la taille de ma cle
    ssl_dh_parameters_length = 4096

    # Dovecot ne propose aucune autre option




ejabberd :
    ## c2s (bloc listen)
    -
      port: 5222
      ip: "::"
      module: ejabberd_c2s
      max_stanza_size: 65536
      shaper: c2s_shaper
      access: c2s

      # TLS est obligatoire entre un client XMPP (gajim par ex) et le serveur
      starttls: true
      starttls_required: true

      # attention, il faut chainer le certificat x509 et la cle privee.
      # Exemple : cat pokedex.crt pokedex.key > pokedex.crt+key
      certfile: "/etc/ssl/mycert/pokedex.crt+key"
     
      protocol_options:
        - "no_sslv2"
        - "no_sslv3"
        - "cipher_server_preference"

      ciphers: "ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM"

      # Parametres DH. Pas avant ejabberd 15.06 qui n'est pas dans Debian Jessie
      # J'utilise des parametres de 4096 bits car en accord avec la taille
      # de la cle utilise dans mon certificat x509
      dhfile: "/etc/ejabberd/ssl/dh_4096.pem"

    [...]

    # s2s (pas de bloc specifique)

    # TLS est obligatoire entre deux serveurs XMPP. Attention, beaucoup de
    # serveurs XMPP ne supportent pas TLS (exemple : Google) donc ça peut
    # empecher de parler a des contacts. On peut mettre la valeur a optional
    # dans ce cas
    s2s_use_starttls: required

    # Voir la remarque ci-dessus pour certfile
    s2s_certfile: "/etc/ssl/mycert/pokedex.crt+key"

    # Voir la remarque ci-dessus pour protocol_options
    s2s_protocol_options:
      - "no_sslv2"
      - "no_sslv3"
      - "cipher_server_preference"

    s2s_ciphers: "ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM"

    # Voir la remarque ci-dessus pour dhfile
    s2s_dhfile: "/etc/ejabberd/ssl/dh_4096.pem"




Postfix :

ÉDIT DU 20/06/2020 : cette configuration est erronée. Voir la nouvelle ici : http://shaarli.guiguishow.info/?m68qkQ . FIN DE L'ÉDIT.

    # TLS - serveur
    smtpd_tls_security_level = may

    # On n'accepte pas d'auth si pas de TLS
    smtpd_tls_auth_only = yes

    smtpd_tls_cert_file = /etc/postfix/ssl/pokedex.crt
    smtpd_tls_dcert_file = $smtpd_tls_cert_file
    smtpd_tls_key_file = /etc/postfix/ssl/pokedex.key
    smtpd_tls_dkey_file = $smtpd_tls_key_file

    smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

    smtpd_tls_protocols = !SSLv2, !SSLv3

    smtpd_tls_mandatory_ciphers = medium
    tls_medium_cipherlist = ALL:!aNULL:!eNULL:!EXP:!RC4:!3DES:!MD5:!LOW:+HIGH:+MEDIUM
    smtpd_tls_exclude_ciphers = aNULL, eNULL, EXP, RC4, 3DES, MD5, LOW
    tls_preempt_cipherlist = yes

    # Parametres DH. Oui, 1024 -> 4096 ... ça vient de la doc Postfix
    # J'utilise des parametres de 4096 bits car en accord avec la taille
    # de la cle utilise dans mon certificat x509
    smtpd_tls_dh1024_param_file = /etc/postfix/ssl/dh_4096.pem

    # Cache partages des sessions TLS (expire au bout d'une heure par defaut)
    smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_tls_cache

    smtpd_tls_loglevel = 1


    # TLS - client
    smtp_tls_security_level = $smtpd_tls_security_level

    smtp_tls_cert_file = $smtpd_tls_cert_file
    smtp_tls_dcert_file = $smtpd_tls_dcert_file
    smtp_tls_key_file = $smtpd_tls_key_file
    smtp_tls_dkey_file = $smtpd_tls_dkey_file

    smtp_tls_CAfile = $smtpd_tls_CAfile

    smtp_tls_protocols = $smtpd_tls_protocols

    smtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
    smtp_tls_exclude_ciphers = $smtpd_tls_exclude_ciphers

    # Cache partages des sessions TLS (expire au bout d'une heure par defaut)
    smtp_tls_session_cache_database = btree:${data_directory}/smtp_tls_cache

    smtp_tls_loglevel = $smtpd_tls_loglevel




Quelques précisions :
    - Oui, je ne me fais pas chier avec une liste de ciphers longue comme le bras car c'est, àmha, trop chiant à maintenir pour un gain de sécurité pas évident du tout à mesurer par rapport à utiliser les groupements OpenSSL (ou GnuTLS, c'est bien pareil) et à exclure quelques suites d'algos. Du coup, je vire simplement les algos pourris (RC4, 3DES, MD5, ceux classés en LOW dans OpenSSL) ou inexistants (aNULL, eNULL) et j'utilise les algos classés comme HIGH puis comme MEDIUM. L'ordre sera celui du serveur : le client prendra la suite d'algos la plus forte qu'il supporte.

    - Vu que j'ai un seul certificat x509 par machine, les /etc/<logiciel_serveur_>/ssl/lala.(crt|key) sont des liens symboliques vers /etc/ssl/mycert/ . Factorisation toussa.

    - Oui, je ne fais pas encore le chaînage des certificats pour fournir une chaîne de confiance complète à mes visiteurs, c'est sur ma TODO pour le prochain renew des certificats.

    - Rappel des valeurs par défaut dans mes confs c'est juste pour m'en souvenir / retrouver facilement.

Sur une machine GNU/Linux, on observe plein de fichiers /dev/ttySx même sur les machines qui ne sont pas équipées d'un port série (RS232).

Comment savoir sur quel device (/dev/ttyS?) a été mappé le port série de votre ordinateur ?

find /sys/ -name 'ttyS*' ! -path "/sys/class/tty/*" ! -path "*serial8250*"
  - Pourquoi j'exclu les fichiers dans /sys/class/tty/ ? Pour ne pas avoir les devices eux-mêmes
  - Pourquoi j'exclu les fichiers qui se trouvent dans un chemin contenant "serial8250" ? La ressource pointée par ce shaarli l'explique très bien : « ttyS* under "serial8250" probably doesn't exist (they are present by default because it's hard to detect if they are present or not)  »

Exemples :
  - Sur une machine sans port série :
    $ find /sys/ -name 'ttyS*' ! -path "/sys/class/tty/*" ! -path "*serial8250*"
    $ [ Aucun résultat ]

  - Sur une machine avec un port série soudé sur la carte mère :
    $ find /sys/ -name 'ttyS*' ! -path "/sys/class/tty/*" ! -path "*serial8250*"
    /sys/devices/pnp0/00:08/tty/ttyS0 [ notre port série est donc mappé sur /dev/ttyS0 ]

  - Sur une autre machine avec un port série soudé sur la carte mère :
    $ find /sys/ -name 'ttyS*' ! -path "/sys/class/tty/*" ! -path "*serial8250*"
    /sys/devices/pnp0/00:0b/tty/ttyS0  [ notre port série est donc mappé sur /dev/ttyS0 ]

:D

« We're looking for someone with the wisdom of a 50-year-old, the experience of a 40-year-old, the drive of a 30-year-old and the pay scale of a 20-year-old. »

C'pas un scoop mais c'est toujours aussi vrai.

Via http://sebsauvage.net/links/?a04rcA

Ok donc mailman (gestionnaire de ML) propose un système anti-spam basé sur les headers « To » et « Cc » : si l'adresse de la ML n'est pas dans ces champs, le mail est placé en attente de modération. Ça évite les bots qui mettent plein de ML en « Bcc ». C'est activé par défaut mais débrayable.

Une telle option n'est pas activée de base dans Sympa. Je suis sceptique sur l'efficacité d'une telle méthode : je gère des ML avec Sympa et les spams que j'ai reçu contenaient bien XXXX adresses de ML en Cc ... Les spammeurs vont à la simplicité car c'est un gage d'efficacité et donc de rentabilité.

Du coup, quand une ML doit envoyer un mail à une autre ML (mailman), ça ne marche pas puisque l'émetteur original a mis l'adresse de la première ML en « To » ou « Cc » (il ne sait pas que ça va être cascadé dans une autre ML). Heureusement, mailman propose un système de liste blanche en fonction du header « To » : « acceptable_aliases ».

« Installer Windows 10 Technical Preview sur son ordinateur donne à Microsoft à peu près tous les droits, y compris celui de collecter des informations sur votre historique de navigation ou ce que vous saisissez sur votre clavier.

[...]

Le but est d'alimenter un véritable centre de télémétrie qui serait appelé en interne "Asimov", pour permettre aux équipes de développement de Windows 10 de voir en temps réel comment s'adaptent les utilisateurs, et quels sont les éventuels problèmes à régler.

[...]

Mais pour y parvenir, selon la politique de vie privée spécifique à la Technical Preview, Microsoft s'autorise à collecter énormément de données (il faudrait chercher ce qu'il ne collecte pas)

[...]

En réponse aux réactions, Microsoft a tenu à rappeler qu'il s'agit d'une preview destinée aux tests technologiques (d'où le nom : "Technical Preview"), et qu'au moins une partie  [NDLR : MDR] de ces informations ne seront plus collectées lors de la version finale ou des prochaines versions bêta.

Par ailleurs, "toutes les données envoyées de Windows 10 Technical Preview vers Microsoft sont chiffrées en transit et nous stockons les informations que vous fournissez sur des systèmes informatiques qui sont en accès limité et dans des centres contrôlés" [NDLR : des centres contrôlés par la NSA ? :D ], veut rassurer la firme de Redmond. »

C'est mignon tout plein. :')

Vous avez une image disque (obtenue avec dd, par exemple) qui contient plusieurs partitions dont une luks + lvm et vous voulez accéder au contenu d'un LV dans cette partition ? Aucun problème avec kpartx, l'outil qui « Create device maps from partition tables. ».

Ça marche aussi pour accéder au contenu d'un LV contenu dans un VG contenu dans un PV qui serait lui-même dans un LV (cas d'une virtualisation, par exemple : chaque VM à un LV dans le VG hôte et est libre de faire du LVM dedans).