OK j'avoue, quand j'ai vu un compte qui n'avait posté que des journaux et des commentaires sur Ubuntu, et qui agressait sauvagement Linux Mint, j'ai voulu jouer.
Bien esquivé et bien argumenté de ta part.
Tu gagnes donc un phoque d'officine de qualité :
pour ton absence totale de fanboyisme.
Là tu as tous les packages dispo dans les repos Mint, avec leur source, leur version etc. Tu aurais vu, par exemple, qu'on peut parfaitement installer un desktop complet même si les infras Ubuntu se vautrent comme une loutre bourrée à la bierre. Certes tout n'est pas audité/copié/recompilé par Mint - mais il y a de quoi faire une machine end-user sans soucis.
Par contre tout ce qui est environnement de compilation/base de données/serveurs c'est un poil vide.
Au sens large du terme, je persiste donc à dire que Mint est Ubuntu.
Si tu veux. Au sens personnel du terme (qui est partagé par d'autres) je trouve Ubuntu lamentable ces dernières années (à peu de chose prêt quelque soit la version) et Mint très bien. Pour plagier Sartre parlant de Malraux : Ubuntu, il ne lui manque pas grand chose pour être une excellente distrib, mais ça lui manque beaucoup.
Après il y a la quantité de hit sur les gros sites linux comme slashdot ou linuxfr. Mais bon c'est un peu tricher, c'est normal quand on a une Ubuntu de passer beaucoup plus de temps sur les forums…
Il y a aussi la Mint Debian, mais je la connais peu.
s/peu/encore moins/
Pour information c'est une Debian testing en rolling release avec quelques paquets supplémentaires (quelques codecs et des versions parfois plus récentes de Mate/Cinamon)
En tout cas, ça n'ai pas le cas ici, ça me fait toujours marrer de voir des gens qui disent ne pas aimer Ubuntu/Canonical et qui utilisent Mint.
Autre bonne blague, Linux Mint est la distribution la plus utilisée au monde, et ce depuis 2011. Il y a pas mal de gens qui préfèrent Mint à Ubuntu.
il faut obligatoirement que le certificat soit valide pour ce nom
Non.
Tu te connecte à ce que tu veux - la validation du VPN ce fait après. Tu confonds avec SSL.
La plupart des systèmes VPN utilisent un certificat X509 - mais il est rarissime qu'il y ait une architecture PKI derrière. De toutes façons la première étape de quasiment tous les VPN est de créer un tunnel puis de faire la validation par ce tunnel.
Tout ce qui se passe dans le tunnel est déjà privé. J'ai des VPN vers des domaines locaux, à savoir tu te connectes au VPN par IP ou par un DN classique, mais une fois le VPN monté ta carte virtuelle est sur mondomaine.local. Le certificat signe mondomaine.local et c'est le seul certif que le client valide.
Donc ZMAP ne peut rien faire.
Encore une fois, la doc de CloudFlare n’est pas de la mitigation d’attaque, mais de la diminution d’amplification d’attaque.
Non plus, ils parlent aussi (brièvement) des cas d'amplification d'attaque (auquels ils ne participent pas grâce à différentes techniques qu'ils aimeraient bien voir se rependre) - mais ils se focalisent surtout sur les signatures dynamiques avec ECDSA qui permettent d'éviter les énumérations de domaine.
Très rapidement, on peut effectivement envisager de faire fonctionner un VPN comme ça - mais je n'ai jamais vu ce type de config être faite.
De façon générale, le serveur de VPN est directement devant le réseau ciblé - on pourrait s'amuser à faire du routage/vlan via des réseaux tiers, mais ça serait un peu aller contre le principe même du VPN.
Le plus souvent un VPN va fonctionner soit avec échange direct des clefs (IE la société qui fournit le VPN paramètre aussi la machine et du coup en profite pour faire l'échange de certificat/clef publiques à ce moment là) - soit on pousse le client à créer sa propre paire clef publique/clef privée et on ajoute lui demande de transmettre la clef publique par mail/site web/ftp - Ou alors on se contente de filer bêtement un couple login/mot de passe, par exemple par téléphone.
Il est rarissime qu'un service VPN utilise un tiers de confiance (type verisign) et des certificats contre signés - Ça arrive parfois en bancaire, sur certaines plateformes de trading - généralement sur des réseaux dédiés (IE non routés sur internet).
Tout ça pour dire que mon serveur peut avoir comme reverse truc.chose.tld, comme nom de domaine accédé par le client waouh.super.net, comme domaine cible (IE une fois la connexion VPN établie) un.deux.test et avoir un certificat avec comme DN : CN=tutu, CN=titi, DC=pipo, DC=root - du moment que le certificat est reconnu par le client comme valide pour le domaine cible ça va passer.
En ce qui concerne la mitigation d'attaque - tu n'es pas obligé de me croire sur parole (encore heureux) - mais je t'invite à lire les docs que j'ai linké chez CloudFlare qui sont raisonnablement accessibles (Oui parce que les docs sur les systèmes de cryptographie ça devient vite pénible pour le non initié).
Si le subject(alt)name ne matche pas le TEXTE saisi par le client (et non pas sa résolution ni même son existence DNS ou reverse)
Il faut en effet que les DN/CN coté client correspondent à ceux coté serveurs. A aucun moment on est obligé de déranger un DNS pour ça. (Généralement d'ailleurs, on fait sans.)
Je ne vois toujours pas en quoi ça permettrait à ZMAP de trouver des reverses alternatifs sur mon serveur VPN…
Si ce domaine héberge un VPN, il devrait obligatoirement présenté un certificat contenant abcdefghijkl123.mondomaine.com, sous peine de casser l’authentification côté client.
GNI ??? Déjà de quel type de VPN tu parles ? OpenVPN ? IPSec (et lequel ?) L2TP ? PPTP ? Parce que ces différents systèmes VPN ne nécessitent pas franchement de certificats avec correspondances des noms - en fait ils ne nécessitent même pas de nom résolus au niveau DNS - en IP pure ça passe. Du moment que tu valider le certificat…
En VPN 999 fois sur 1000 le nom de domaine ne sert qu'à simplifier l'installation ou la migration du service vis à vis des collaborateurs.
ne serait-ce que pour éviter une erreur flippante si un client se connecte directement dessus. C’est par exemple le cas chez CloudFlare.
CloudFlare c'est du frontal, c'est à dire un truc sur lequel le client est supposé se connecter directement - donc je ne comprend pas trop ta remarque. Bien entendu sur un serveur frontal il faut que le SSL contienne tous les alt name. On parle de serveurs back-end là
Non, ils indiquent juste qu’effectivement avec de la puissance de frappe on peut énumérer les domaines d’un serveur, et que ECDSA permettrait de minimiser la taille des réponses donc les facteurs d’amplification si ton résolveur DNS sert de vecteur d’attaque DDOS (et non s’il est la cible finale).
GNIIII ????
Ce qu'ils disent c'est que c'est casse pied d'avoir tout ses noms de domaines accessibles sur simple requête - que la parade est de passer par de la signature dynamique (au lieu de renvoyer un fichier générique statique - on signe une réponse qui correspond exactement à la demande) - sauf que bien sur la signature dynamique oblige à avoir les clefs privées sur tous les résolveurs (perso je suis pas fan) et qu'en plus l'algo par défaut pour la signature est RSA (c'est d'ailleurs le seul algo obligatoire) - sauf que RSA ça bouffe du CPU comme un goret, et que du coup si tu te prends une attaque - ton résolveur va exploser.
Donc ils demandent à ce que la signature par défaut passe par de l’elliptique qui va quand même 10 fois plus vite - ce qui permet de rester serein un peu plus longtemps quand on se prend une attaque par réflexion.
Est-ce que la sécurité de ton installation dépend du fait que personne ne connaît ou ne peux trouver le nom abcdefghijkl123.mondomaine.com ?
Non, la sécurité de l'installation ne varie pas. La qualité de service ainsi que la résistance à certaines attaques de type déni de service est améliorée par contre.
Pour être clair, ça n'a aucun impact sur la sécurité des données, la sécurisation des systèmes d'authentification et les injections/corruptions/poisoning - par contre ça empêche de faire de la mitigation. Donc un attaquant qui n'aurait pas les moyens de faire un DDoS sur dix serveurs simultanément, pourrait par contre en choisir trois et les noyer (ce qui aurait un beaucoup plus gros impact sur la qualité du service ressenti).
A noter cependant qu'il ne s'agit pas de "mon" installation. Si je devais faire du DNSSEC, je le ferai très probablement via CloudFlare aujourd'hui. Principalement parce qu’ils ont réussi a encaisser de grosses attaques sur DNSSEC sans s'effondrer.
Non.
A moins d'essayer en force brute toutes les possibilités d'entrées DNS, ZMAP n'a aucune chance de tomber sur abcdefghijkl123.mondomaine.com si celui ci n'est pas référencé ailleurs que sur les DNS. Si aucun autre site ne le mentionne, et si son reverse est différent (voire sur un autre domaine) alors c'est grillé.
Ensuite L'immense majorité des entrées DNS sont publiques. C'est clair que si je scanne toutes les adresses du monde et que je regarde pour chaque adresse son reverse, je vais tomber un paquet de noms de domaines (honnêtement je suis même surpris que ce ne soit "que" 33%) - mais ça n'apporte pas vraiment grand chose au débat. La on parle d'un frontal avec une entrée DNS "connue" qui discute avec pleins de serveurs back-end via des entrées DNS qui ne sont normalement pas connues du public et qui ont des reverses qui divergent des noms utilisés par les serveurs frontaux.
Ensuite il ne s'agit pas de sécurité par l'obscurité, la sécurité par l'obscurité consiste à ne pas dévoiler la méthode utilisée - de peur que par l'analyse de la méthode on puisse casser la méthode elle-même et donc rendre nulle la sécurité. La non divulgation, qui consiste non pas à masquer la méthode, mais à ne pas dévoiler l'ensemble des éléments utilisés par l'implémentation spécifique de la méthode est parfaitement normale. Au hasard je dirais, par exemple, que si tu veux utiliser un chiffrement asymétrique RSA, tu ne vas pas divulguer ta clef. Ce n'est pas de la sécurité par l'obscurité, c'est du bon sens.
Ben dans le cas présent c'est la même chose - la méthode est exposée clairement (le reverse est différent des noms utilisés par les serveurs frontaux, les serveurs frontaux sont les seuls (ou presque) à utiliser certains nom de domaines.)
Étant donné qu’il est très simple et très rapide de scanner toute la plage IP (cf ZMap et son utilisation la plus efficace, Shodan), avoir un DNS obscurci ne sert à rien : on trouvera facilement quel serveur (= IP) héberge un VPN, au mieux on aura scanné toute ta plage de port, au pire tout l’Internet :P
Ben vas-y scanne tout internet, fait un reverse lookup de toutes les IP et fait la corrélation. Je ne pense pas qu'il existe de machine capable de faire ce que tu proposes. Surtout qu'en plus il n'y a qu'un seul reverse par IP alors qu'il peut y avoir plusieurs noms de domaine.
Si tu fais un reverse sur tout internet tu vas tomber sur pas mal de CDN par exemple, mais bonne chance pour savoir lesquels sont utilisé par tel ou tel domaine (et donc lesquels tu dois cibler si tu veux faire un DDoS)
J'ai jamais compris cet argument. Y en a qui nomment leurs serveurs avec leurs numéros de CB ? La sécurité du backoffice repose sur le postulat que personne ne tapera lebackoffice.maboite.com ?
Il y a plusieurs cas ou tu n'as vraiment pas envie d'exposer tous les noms DNS possibles et imaginables.
Par exemple si tu as un cluster de serveur derrière un load balancer. Pour tout un tas de raisons tu peux vouloir que les clients passent par ton load balancer (server.mondomaine.tld) , mais avoir besoin d'exposer tes machines directement pour la maintenance (srv1.mondomaine.tld, srv2.mondomaine.tld etc.)
Autre exemple, en cas de migration de serveur ou de montée de version - tu peux vouloir que les clients passent par un autre serveur (par exemple un serveur de maintenance) sans pour autant que le dit serveur soit normalement visible.
Pour finir quand tu donnes la liste des serveurs accessibles depuis l'extérieur via DNS, tu files au passage les IP desdits serveurs - ça peut permettre à des personnes mal intentionnées de voir chez qui tu es hébergé, ou sont tes peerings, quelles sont les parties les moins redondées de ton réseaux (SPOF entre autres) et ça simplifie grandement les attaques.
Inconvénients :
- Cela ne règle pas le problème des DNS des FAI/Entreprises qui refusent d'être
compatibles avec cette norme.
Tous les TLD n'ont pas un top level signé liste TLD ce qui oblige à passer par des DLV DNSSEC Lookaside Validationqui va créer des trusts anchor à droite à gauche - au cas ou.
Du fait du truc précédent, il redevient possible de faire du DNS poisonning (c'est un poil plus compliqué certes)
Il faut parfois deux mois pour renouveler/changer une clef et la remonter vers les DLV et les racines TLD. Et il n'existe pas de façon simple de révoquer une clef. Très cool si un admin sys un peu escroc sur les bords par en claquant la porte.
Si votre clef est corrompue sur le disque et/ou en mémoire - ben plouf. J'espère que vous avez un backup de la clef et une bonne connaissance des adresses IP des serveurs autoritaires, sinon vous prenez le risque de passer un poil pour un guignol.
De base DNSSEC permet assez facilement de récupérer l'ensemble de votre zone, il y a des "bricolages" qui permettent de protéger vos fichiers zones (Universal DNSSEC, Online signing, NSEC3) mais bon ils ont tous des inconvénients et sont des degrés de protection variable (Universal DNSSEC n'est pas formalisé, Online signing oblige à laisser trainer les clefs privées sur tous les resolveurs et NSEC3 est déjà cassé)
La théorie des nombres (hash, chiffrement, certaines formes d'indexation, compression sans perte etc.)
La théorie du signal (quasiment toute l'informatique s'appuie dessus - mais bon on peut citer l'ensemble des transmissions, les mécanismes de contrôles d'erreur, les évitements de collisions, certaines compressions (avec ou sans perte), a peu près tous les filtres possibles et imaginables)
Les processus stochastiques (génération d'entropie, calcul de risque, répartition de risque, nombreuses applications statistiques )
Ça c'est juste pour les parties qui ont des impacts directs depuis le fin fonds des mathématiques théoriques vers le bout du bout de l'informatique.
Après si on prend des domaines comme la théorie des graphes (en fait toute la topologie ou presque), la théorie de l'information ou encore l'algèbre linéaire - on a pas fini.
Dans mon travail de tout les jours je suis très loin de toute considération mathématique.
C'est vrai que la plupart des informaticiens sont utilisateurs des briques mathématiques pré-traduites par leurs ainés. Mais bon quand on met un index sur une base de données, ou même simplement que l'on ouvre une image PNG pour l'afficher à l'écran - il faut bien se rendre compre qu'il y a derrière un gros bagage mathématiques qui débarque (même si il est discret).
Ne serait-ce qu'un programme qui fait appel à des ondelettes ou à une transformée de Fourrier - ça ramasse des maths velues…
La dette c’est la différence entre les dépenses et les recettes. Si l’état met en place un programme qui coûte 100.000€ financé par une levée de 100.000€ de taxes, ça te fait un financement par la dette du programme de… 0.
Si la collecte de la taxe est immédiate, si elle est immédiatement mise à disposition des services usagers et qu'il n'y avait pas besoin de verser d’acompte, voire de payer d'avance tout ou partie des biens oui. Dans les faits il y a quasiment une année fiscale de décalage entre la mise à disposition des biens et/ou des services et le versement de la taxe dans les caisses de l'état.
Et rappelons que dans la situation de ce journal, c’est pas « l’état qui dépense » vs « les particuliers qui dépensent », mais « l’état qui dépense » (en salaires de fonctionnaires) vs « l’état qui dépense » (en achats auprès de Microsoft).
Tout à fait, j'intervenais juste sur la partie "masquage" de dette tel qu'évoqué par thamieu. Du genre de ce que l'on a avec les mutuelles obligatoires cumulées en France. Dans ce type de relations, l'état n'intervient plus du tout - ce sont les entreprises qui effectuent le travail de collecte et de reversement.
Dans ton scénario précédent le PIB augmente également. Rappel: la dépense publique entre dans le PIB.
Oui mais sur l'opération visée, dans un cas on a un ratio ( augmentation de dette publique ) / ( augmentation de PIB ) de 100% - tant que la dette publique est inférieure au PIB ça va venir augmenter le ratio dette publique sur PIB.
Dans le second cas seul le PIB va augmenter, la dette publique ne bronchera pas. La dette privée peut augmenter, mais la BCE se moque de la dette privée (ou alors elle a peur de chopper le vertige).
Par exemple si on a un produit à 100€ acheté tous les ans par l'état pour 1000 citoyens via une taxe. Mettons que cet état ait un PIB de 1 000 000€ (petit état) et une dette de 850 000€.
La banque autorise 80% de PIB en dette, le petit état a donc un problème de 50 000€.
Si l'état conserve un mécanisme de taxe, il va collecter 100 000€ qui vont venir en plus sur le PIB et il va dépenser 100 000€ qui vont venir en plus sur la dette.
On aura donc un PIB de 1 100 000€ et une dette de 950 000€. la banque autorise toujours 80% de dette soit 880 000€ maximum.
Notre petit état a maintenant un problème de 80 000€
Par contre si on passe par le mécanisme de dépense privée obligatoire, le PIB va toujours augmenter de 100 000€, mais la dette publique ne va pas broncher.
On aura un PIB de 1 100 000€ et une dette de 850 000€. Le seuil maximal d'endettement est comme à l'exemple précédent toujours à 880 000€.
Notre petit état a donc non seulement résolu son problème de 50 000€ du départ, mais en plus il se paye le luxe de récupérer 30 000€ de capacité d'endettement supplémentaire.
J'aurais du détailler plus, et j'ai pris pas mal de raccourcis dans mon énoncé précédent. Mais l'idée générale est là, la PIB augmente sans toucher à la dette publique ce qui permet de dégager une nouvelle capacité d'endettement (ou au moins de sauver les meubles).
Dans le public en tant qu’usager ce qui sort de ma poche c’est le coût de fonctionnement de l’administration, qu’on appelle « dépense publique ». C’est donc normal de plus s’intéresser à la dépense du service public qu’aux dépenses des entreprises privée.
Supposons que l'état mette à disposition de ses citoyens des voitures, via financement par une taxe. Ce serait une dépense publique, donc un déficit qui viendrait aggraver la dette du pays.
A l'inverse si la dépense est effectuée par le citoyen lui même sur le territoire français il s'agit alors d'une opération commerciale qui accroit le PIB du pays et qui permet au contraire à l'état d'augmenter sa dette (puisque seul le ratio dette/PIB est pris en compte).
Donc au final même si toi ça te coute la même chose et que tu as vraiment besoin d'une voiture dans un cas le pays s'endette et dans l'autre cas le PIB du pays augmente - ce qui proportionnellement fait baisser sa dette.
Ben c'est pareil pour les mutuelles de santé, l'entretien des routes, l'école et les autres services "publics".
De fait l'état décale de plus en plus de dépenses du public vers le privé - C'est purement artificiel, en vrai ça ne change pas grand chose pour le contribuable (entre une taxe et une dépense obligatoire, la différence au niveau du portefeuille est nulle), mais ça baisse la dépense publique tout en faisant augmenter le PIB sans avoir à remettre en cause quoi que ce soit (Bon il y a bien quelques syndicats qui râlent des fois - mais ça se gère bien)
Non car les chartes sont un contrat pouvant même avoir valeur juridique.
Généralement si tu trahis une charte tout ce qui va se passer c'est que tu n'auras plus le droit d'afficher le macaron vert et mauve de l'ecolo-entrepreneur responsable sur le mur de ta salle de réunion.
En tout cas ca a fait du bruit sur internet à l'époque et ça n'a pas été démenti.
Il y a eu pas mal de discussion sur Quora à ce sujet. Zuckerberg a d'ailleurs admis que d'Angelo lui avait appris pas mal de truc en programmation.
En ce qui concerne Bill Gates, les retours que j'ai viennent de personnes qui ont bossé pour Microsoft - PBPG entre autres, mais pas que. Bien qu'il ne code plus depuis un moment, il est resté capable d'assimiler des page set des pages de specs et de notions techniques en un temps record, y compris sur des sujets pointus comme le système de fichier ou la gestion protocoles réseaux.
Mais là c'est plus dur de trouver des sources fiables - il y avait une page avec un texte parlant d'une nouvelle fonctionnalité Office, et d'une correction à faire sur laquelle Bill Gates aurait ingurgité l'équivalent de 450 pages de doc technique en quelques heures et aurait posé des questions très pointues et pertinentes avant de donner son GO. Mais je ne la trouve plus.
Parce que ce n'est pas la même chose ?
Appelle Hacker les personnes qui utilisent des outils facilement disponibles pour créer quelque chose d'innovant ou résoudre un problème technique - de préférence de façon soit rigolote soit spectaculaire.
Un hacker n'est pas forcément lié au domaine informatique, même si c'est là ou il y en a le plus je pense. Le monde de l’électronique et de la téléphonie regorgent de hackers.
Le Hack tient parfois de la jonglerie (je lance quatre truc en l'air dans le noir et je parie que j'arrive à les rattraper avant qu'ils ne touchent le sol), parfois du bricolage++ (façon Angus MacGyver), parfois de l'obstination statistique (ça a une chance sur 1 million de marcher ? Bon ben je créé un truc qui fait 10 000 essais par secondes - et j'attends).
Moins connus que Steve Jobs par exemple, ou moins connu que Mark Zuckerberg.
Malgré la définition très floue (et très disputée) du mot hacker, je ne considère ni l'un ni l'autre comme des hackers.
Jobs pas du tout, et Zuckerberg à peine. A la limite Moskovitz ça peut se discuter pour Facebook. Pour Apple le hacker "célèbre" c'est Wozniak.
Même Bill Gates (qui est très loin au niveau technique devant Jobs et Zuckerberg) peine à rentrer dans la catégorie "hacker".
Je m'attendais plus à du Seymour Cray, du Tanenbaum, ou du Linus Torvalds (même si son status de hacker est un peu en hiatus en ce moment, de son propre aveu)
J'avoue volontiers ne pas connaitre Ilya Zhitomirskiy, mais les autres il sont quand même très largement dans les 100 hackers les plus connus.
On a juste dans l'ordre l'inventeur de l'IHM, du HTTP et de la souris, l'auteur du langage C et le petit génie inventeur du RSS et de créative common très médiatisé de part son suicide suite aux pressions de la justice américaine.
Si pour toi se sont des "seconds couteaux", je serais curieux de savoir qui tu mets en tête de liste.
Enfin j'imagine que ça veux surtout dire que même si on change la vie de milliards de gens (Zhitomirskiy pas encore) on ne devient pas forcément célèbre.
Tu as visiblement un gros problème à comprendre qu'il y a un facteur humain là dedans.
Et tu as visiblement un gros problème à comprendre qu'il y a DEUX facteurs humains.
Parce que le l'administré il veut bien comprendre pleins de choses, mais le niveau d'incompétence chronique dont font preuve les différentes administrations atteint en ce moment des records. Alors parfois c'est sur ordre (faut pas payer, faut prélever), mais dans l'immense majorité des cas il s'agit simplement d'un désintéressement total des choses du légal et du social quand ça avantage ou arrange l'administré et lui seul.
La création de documents numériques éditables et imprimable par toute personne qui le souhaite est un problème qui a bientôt vingt ans et qui a été résolu dans toutes les entreprises du monde. Beaucoup de sociétés qui n'ont aucune obligation à le faire ont de nombreux formulaires que l'on peut remplir en ligne, hors ligne ou manuellement.
Créer un PDF valide, un formulaire en ligne ou feuillet imprimable chez monsieur tout le monde ça n'est plus un problème. Même des sociétés très modestes arrivent à créer ou à faire créer des formulaires sécurisés compatibles avec les navigateurs des divers téléphones portables.
Par contre l'administration, qui a obligation de résultat, obligation de non discrimination et toutes les obligations afférentes liées au RGI se permet de t'envoyer balader quand par hasard tu fais remarquer que 7 manquements sur 6 obligations c'est quand même un joli score.
Donner des directives pour que les documents produits soient conformes à minima avec des lignes directrices, c'est long, c'est complexe humainement et tout ce que tu veux - mais c'est leur boulot. C'est une administration, bon sang, produire et valider des documents conformes c'est 95% de leur boulot.
Et l'administré en face il a autre chose à faire que de bricoler des documents dégénérés pour essayer de leur donner un sens, autre chose à faire que de recoller les informations pour comprendre ce que l'on attend de lui et autre chose à faire que de multiplier les aller retours à tel ou tel service public pour pousser un dossier qui n'avance pas parce que trop éloigné des dossiers "simples" à traiter.
Donc oui produire des documents conforme c'est complexe, mais
a) Aujourd'hui tout le monde y arrive sauf nos administrations
b) C'est le métier qu'ils ont choisit de faire en entrant dans cette section de la fonction publique - il serait bon qu'il fasse un peu semblant de s'y intéresser de temps à autre.
C'est pas pour troller, mais j'avais entendu dire que, dorénavant, c'est systemd qui allait gérer l'ensemble des cgroups. Donc est-ce que ces manipulations ne risque pas de perturber notre PID 1 préféré ?
Oui et non.
Si il s'agit d'un processus lancé depuis un terminal ou un pseudo terminal, ça ne change pas grand chose. Il y a des projets de nouvelle interface pour les cgroups qui forcera une interface centralisée. Dans les systèmes utilisant le framework systemd c'est celui-ci qui s'occupera de gérer les cgroups.L'api et les commandes seront différentes, mais dans l'ensemble les fonctionnalités devrait être sensiblement les mêmes.
Par contre si il s'agit d'un processus détaché (daemon ou autre) géré par l'init, ça devient plus compliqué. Et c'est déjà le cas aujourd'hui, même sans la nouvelle interface.
Si le processus a été lancé par systemd il a nécessairement été placé dans une slice, c'est à dire une tranche de ressources configurée dans systemd. Par défaut il y a trois grande catégories de slice présente dans systemd
- la slice system, qui lance tous les services "classiques".
- la slice user, qui lance tous les services "utilisateurs" - c'est à dire ayant besoin d'avoir accès à logind)
- la slice machine qui gère les machines virtuelles et les containers (dans une certaine mesure, tout n'est pas supporté et tout ce qui est supporté n'est pas recommandé)
Il faut bien comprendre trois choses :
- Un processus ne peut appartenir qu'à un cgroup et un seul
- Quand un processus change de hiérarchie il devient littéralement invisible aux yeux des processus qui ne sont pas dans une hiérarchie ancêtre.
- Certains processus (par exemple logind) et certains devices (les cartes réseaux notamment) ne peuvent pas être déplacés, ré-alloués ou même relancés dans un autre cgroup sans heurts. (Et par heurts je veux dire passage de systemd en mode panique totale, avec tentative de relance en boucle de certains services)
A noter que le troisième point n'est en aucun cas une faute de systemd, simplement le résultat d'un choix qui a été fait dans un soucis de simplification. La nouvelle interface résoudra ce problème via la centralisation des appels.
De fait certaines opérations sur les cgroups qui sont possibles sans systemd deviennent très complexe avec systemd.
Par exemple supposons que je veuille mettre à disposition d'un client une machine virtuelle avec une carte réseau dédiée, et en plus une interface web de monitoring sur laquelle il peut se loguer en utilisant ses identifiants utilisateurs local (ou domaine).
Maintenant supposons que je veuille mettre des restrictions à tout ça en utilisant les cgroups. La transversalité du bignou va m'obliger à créer plusieurs tranches avec systemd et à composer avec les différents éléments.
Sans systemd je peux parfaitement créer une hiérarchie globale pour le client et mettre les restrictions dessus.
En plus certaines opérations, comme allouer un coeur CPU ou une carte réseau à un cgroup défini, geler un processus ou encore taguer les paquets en fonction de leur cgroup ne sont pas encore supportées par systemd.
Pour faire court :
- Pour l'instant sur tous les processus lancés depuis un tty, ça marche et ça devrait continuer de marcher - mais peut-être avec une API différente, et peut-être avec certains manques sous le framework systemd si les fonctionnalités manquantes aux slides en sont pas implémentées.
- En ce qui concerne les processus rattachés au PID 1,à aujourd'hui il y a des limitations - elles n'impactent probablement pas grand monde (mais j'en suis et ca me casse les pieds gravement)
Pour le futur ca dépendra du controlleur de cgroups au final, sous le framework systemd il y aura très probablement des manques dus aux choix architecturaux. Mais on ne sait jamais, il faut attendre les nouvelles interface et leur intégration pour être sur.
Adopté par tous les pays, y compris par l'Irlande en mode référendum.
Pas mal de pays ont fait l'impasse sur un second référendum, de peur que les idiots désinformés, abreuvés de flots populistes, ne votent mal une seconde fois. Ça se comprend note bien, la technique en vigueur du "On reproposera la même loi jusqu'à ce que vous la votiez" est très complexe à mettre en place à 27 pays.
[^] # Re: LinuxMint
Posté par Kaane . En réponse au sondage Quelle est votre distribution préférée ?. Évalué à 10.
OK j'avoue, quand j'ai vu un compte qui n'avait posté que des journaux et des commentaires sur Ubuntu, et qui agressait sauvagement Linux Mint, j'ai voulu jouer.
Bien esquivé et bien argumenté de ta part.
Tu gagnes donc un phoque d'officine de qualité :
pour ton absence totale de fanboyisme.
[^] # Re: LinuxMint
Posté par Kaane . En réponse au sondage Quelle est votre distribution préférée ?. Évalué à 1.
Houla, tu t'es donné beaucoup de mal pour pas grand chose, il suffisait de cliquer sur le lien donné et d'aller là :
http://packages.linuxmint.com/list.php?release=Rosa
Là tu as tous les packages dispo dans les repos Mint, avec leur source, leur version etc. Tu aurais vu, par exemple, qu'on peut parfaitement installer un desktop complet même si les infras Ubuntu se vautrent comme une loutre bourrée à la bierre. Certes tout n'est pas audité/copié/recompilé par Mint - mais il y a de quoi faire une machine end-user sans soucis.
Par contre tout ce qui est environnement de compilation/base de données/serveurs c'est un poil vide.
Si tu veux. Au sens personnel du terme (qui est partagé par d'autres) je trouve Ubuntu lamentable ces dernières années (à peu de chose prêt quelque soit la version) et Mint très bien. Pour plagier Sartre parlant de Malraux : Ubuntu, il ne lui manque pas grand chose pour être une excellente distrib, mais ça lui manque beaucoup.
Ca va être dur de trouver une source moins critiquable que DistroWatch
- Gartner ? Ils ne distinguent pas vraiment les différents linux (dèjà ils ont écartés android, c'est toujours ca de pris)
- Linux Mint eux-même ? http://www.linuxmint.com/about.php - Douteux.
- ZDNet ? http://www.zdnet.com/article/the-5-most-popular-linux-distributions/ - Pas toujours très rigoureux
Après il y a la quantité de hit sur les gros sites linux comme slashdot ou linuxfr. Mais bon c'est un peu tricher, c'est normal quand on a une Ubuntu de passer beaucoup plus de temps sur les forums…
[^] # Re: LinuxMint
Posté par Kaane . En réponse au sondage Quelle est votre distribution préférée ?. Évalué à 3.
Qui lui même n'est pas beaucoup plus qu'un skin au dessus de Debian.
Non : http://packages.linuxmint.com/
s/peu/encore moins/
Pour information c'est une Debian testing en rolling release avec quelques paquets supplémentaires (quelques codecs et des versions parfois plus récentes de Mate/Cinamon)
Autre bonne blague, Linux Mint est la distribution la plus utilisée au monde, et ce depuis 2011. Il y a pas mal de gens qui préfèrent Mint à Ubuntu.
Mais non pense-tu.
[^] # Re: Juste pour compléter la liste
Posté par Kaane . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 2.
Non.
Tu te connecte à ce que tu veux - la validation du VPN ce fait après. Tu confonds avec SSL.
La plupart des systèmes VPN utilisent un certificat X509 - mais il est rarissime qu'il y ait une architecture PKI derrière. De toutes façons la première étape de quasiment tous les VPN est de créer un tunnel puis de faire la validation par ce tunnel.
Tout ce qui se passe dans le tunnel est déjà privé. J'ai des VPN vers des domaines locaux, à savoir tu te connectes au VPN par IP ou par un DN classique, mais une fois le VPN monté ta carte virtuelle est sur mondomaine.local. Le certificat signe mondomaine.local et c'est le seul certif que le client valide.
Donc ZMAP ne peut rien faire.
Non plus, ils parlent aussi (brièvement) des cas d'amplification d'attaque (auquels ils ne participent pas grâce à différentes techniques qu'ils aimeraient bien voir se rependre) - mais ils se focalisent surtout sur les signatures dynamiques avec ECDSA qui permettent d'éviter les énumérations de domaine.
[^] # Re: Juste pour compléter la liste
Posté par Kaane . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 2.
Très rapidement, on peut effectivement envisager de faire fonctionner un VPN comme ça - mais je n'ai jamais vu ce type de config être faite.
De façon générale, le serveur de VPN est directement devant le réseau ciblé - on pourrait s'amuser à faire du routage/vlan via des réseaux tiers, mais ça serait un peu aller contre le principe même du VPN.
Le plus souvent un VPN va fonctionner soit avec échange direct des clefs (IE la société qui fournit le VPN paramètre aussi la machine et du coup en profite pour faire l'échange de certificat/clef publiques à ce moment là) - soit on pousse le client à créer sa propre paire clef publique/clef privée et on ajoute lui demande de transmettre la clef publique par mail/site web/ftp - Ou alors on se contente de filer bêtement un couple login/mot de passe, par exemple par téléphone.
Il est rarissime qu'un service VPN utilise un tiers de confiance (type verisign) et des certificats contre signés - Ça arrive parfois en bancaire, sur certaines plateformes de trading - généralement sur des réseaux dédiés (IE non routés sur internet).
Tout ça pour dire que mon serveur peut avoir comme reverse truc.chose.tld, comme nom de domaine accédé par le client waouh.super.net, comme domaine cible (IE une fois la connexion VPN établie) un.deux.test et avoir un certificat avec comme DN : CN=tutu, CN=titi, DC=pipo, DC=root - du moment que le certificat est reconnu par le client comme valide pour le domaine cible ça va passer.
En ce qui concerne la mitigation d'attaque - tu n'es pas obligé de me croire sur parole (encore heureux) - mais je t'invite à lire les docs que j'ai linké chez CloudFlare qui sont raisonnablement accessibles (Oui parce que les docs sur les systèmes de cryptographie ça devient vite pénible pour le non initié).
[^] # Re: Juste pour compléter la liste
Posté par Kaane . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
Il faut en effet que les DN/CN coté client correspondent à ceux coté serveurs. A aucun moment on est obligé de déranger un DNS pour ça. (Généralement d'ailleurs, on fait sans.)
Je ne vois toujours pas en quoi ça permettrait à ZMAP de trouver des reverses alternatifs sur mon serveur VPN…
[^] # Re: Juste pour compléter la liste
Posté par Kaane . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
GNI ??? Déjà de quel type de VPN tu parles ? OpenVPN ? IPSec (et lequel ?) L2TP ? PPTP ? Parce que ces différents systèmes VPN ne nécessitent pas franchement de certificats avec correspondances des noms - en fait ils ne nécessitent même pas de nom résolus au niveau DNS - en IP pure ça passe. Du moment que tu valider le certificat…
En VPN 999 fois sur 1000 le nom de domaine ne sert qu'à simplifier l'installation ou la migration du service vis à vis des collaborateurs.
CloudFlare c'est du frontal, c'est à dire un truc sur lequel le client est supposé se connecter directement - donc je ne comprend pas trop ta remarque. Bien entendu sur un serveur frontal il faut que le SSL contienne tous les alt name. On parle de serveurs back-end là
GNIIII ????
Ce qu'ils disent c'est que c'est casse pied d'avoir tout ses noms de domaines accessibles sur simple requête - que la parade est de passer par de la signature dynamique (au lieu de renvoyer un fichier générique statique - on signe une réponse qui correspond exactement à la demande) - sauf que bien sur la signature dynamique oblige à avoir les clefs privées sur tous les résolveurs (perso je suis pas fan) et qu'en plus l'algo par défaut pour la signature est RSA (c'est d'ailleurs le seul algo obligatoire) - sauf que RSA ça bouffe du CPU comme un goret, et que du coup si tu te prends une attaque - ton résolveur va exploser.
Donc ils demandent à ce que la signature par défaut passe par de l’elliptique qui va quand même 10 fois plus vite - ce qui permet de rester serein un peu plus longtemps quand on se prend une attaque par réflexion.
[^] # Re: Juste pour compléter la liste
Posté par Kaane . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 2.
Est-ce que la sécurité de ton installation dépend du fait que personne ne connaît ou ne peux trouver le nom abcdefghijkl123.mondomaine.com ?
Non, la sécurité de l'installation ne varie pas. La qualité de service ainsi que la résistance à certaines attaques de type déni de service est améliorée par contre.
Pour être clair, ça n'a aucun impact sur la sécurité des données, la sécurisation des systèmes d'authentification et les injections/corruptions/poisoning - par contre ça empêche de faire de la mitigation. Donc un attaquant qui n'aurait pas les moyens de faire un DDoS sur dix serveurs simultanément, pourrait par contre en choisir trois et les noyer (ce qui aurait un beaucoup plus gros impact sur la qualité du service ressenti).
A noter cependant qu'il ne s'agit pas de "mon" installation. Si je devais faire du DNSSEC, je le ferai très probablement via CloudFlare aujourd'hui. Principalement parce qu’ils ont réussi a encaisser de grosses attaques sur DNSSEC sans s'effondrer.
Je conseille vivement la lecture de ceci https://www.cloudflare.com/dnssec/ecdsa-and-dnssec/ et de cela https://www.cloudflare.com/dnssec//dnssec-complexities-and-considerations/ pour bien comprendre que le couple DNSSEC RSA + pleins de sous domaines = DDoS gratos pour un assaillant.
[^] # Re: Juste pour compléter la liste
Posté par Kaane . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
C’est exactement ce que permet ZMap.
Non.
A moins d'essayer en force brute toutes les possibilités d'entrées DNS, ZMAP n'a aucune chance de tomber sur abcdefghijkl123.mondomaine.com si celui ci n'est pas référencé ailleurs que sur les DNS. Si aucun autre site ne le mentionne, et si son reverse est différent (voire sur un autre domaine) alors c'est grillé.
Ensuite L'immense majorité des entrées DNS sont publiques. C'est clair que si je scanne toutes les adresses du monde et que je regarde pour chaque adresse son reverse, je vais tomber un paquet de noms de domaines (honnêtement je suis même surpris que ce ne soit "que" 33%) - mais ça n'apporte pas vraiment grand chose au débat. La on parle d'un frontal avec une entrée DNS "connue" qui discute avec pleins de serveurs back-end via des entrées DNS qui ne sont normalement pas connues du public et qui ont des reverses qui divergent des noms utilisés par les serveurs frontaux.
Ensuite il ne s'agit pas de sécurité par l'obscurité, la sécurité par l'obscurité consiste à ne pas dévoiler la méthode utilisée - de peur que par l'analyse de la méthode on puisse casser la méthode elle-même et donc rendre nulle la sécurité. La non divulgation, qui consiste non pas à masquer la méthode, mais à ne pas dévoiler l'ensemble des éléments utilisés par l'implémentation spécifique de la méthode est parfaitement normale. Au hasard je dirais, par exemple, que si tu veux utiliser un chiffrement asymétrique RSA, tu ne vas pas divulguer ta clef. Ce n'est pas de la sécurité par l'obscurité, c'est du bon sens.
Ben dans le cas présent c'est la même chose - la méthode est exposée clairement (le reverse est différent des noms utilisés par les serveurs frontaux, les serveurs frontaux sont les seuls (ou presque) à utiliser certains nom de domaines.)
[^] # Re: Juste pour compléter la liste
Posté par Kaane . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 0.
Étant donné qu’il est très simple et très rapide de scanner toute la plage IP (cf ZMap et son utilisation la plus efficace, Shodan), avoir un DNS obscurci ne sert à rien : on trouvera facilement quel serveur (= IP) héberge un VPN, au mieux on aura scanné toute ta plage de port, au pire tout l’Internet :P
Ben vas-y scanne tout internet, fait un reverse lookup de toutes les IP et fait la corrélation. Je ne pense pas qu'il existe de machine capable de faire ce que tu proposes. Surtout qu'en plus il n'y a qu'un seul reverse par IP alors qu'il peut y avoir plusieurs noms de domaine.
Si tu fais un reverse sur tout internet tu vas tomber sur pas mal de CDN par exemple, mais bonne chance pour savoir lesquels sont utilisé par tel ou tel domaine (et donc lesquels tu dois cibler si tu veux faire un DDoS)
[^] # Re: Juste pour compléter la liste
Posté par Kaane . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 3.
J'ai jamais compris cet argument. Y en a qui nomment leurs serveurs avec leurs numéros de CB ? La sécurité du backoffice repose sur le postulat que personne ne tapera lebackoffice.maboite.com ?
Il y a plusieurs cas ou tu n'as vraiment pas envie d'exposer tous les noms DNS possibles et imaginables.
Par exemple si tu as un cluster de serveur derrière un load balancer. Pour tout un tas de raisons tu peux vouloir que les clients passent par ton load balancer (server.mondomaine.tld) , mais avoir besoin d'exposer tes machines directement pour la maintenance (srv1.mondomaine.tld, srv2.mondomaine.tld etc.)
Autre exemple, en cas de migration de serveur ou de montée de version - tu peux vouloir que les clients passent par un autre serveur (par exemple un serveur de maintenance) sans pour autant que le dit serveur soit normalement visible.
Pour finir quand tu donnes la liste des serveurs accessibles depuis l'extérieur via DNS, tu files au passage les IP desdits serveurs - ça peut permettre à des personnes mal intentionnées de voir chez qui tu es hébergé, ou sont tes peerings, quelles sont les parties les moins redondées de ton réseaux (SPOF entre autres) et ça simplifie grandement les attaques.
# Juste pour compléter la liste
Posté par Kaane . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 2.
Tous les TLD n'ont pas un top level signé liste TLD ce qui oblige à passer par des DLV DNSSEC Lookaside Validationqui va créer des trusts anchor à droite à gauche - au cas ou.
Du fait du truc précédent, il redevient possible de faire du DNS poisonning (c'est un poil plus compliqué certes)
Il faut parfois deux mois pour renouveler/changer une clef et la remonter vers les DLV et les racines TLD. Et il n'existe pas de façon simple de révoquer une clef. Très cool si un admin sys un peu escroc sur les bords par en claquant la porte.
Si votre clef est corrompue sur le disque et/ou en mémoire - ben plouf. J'espère que vous avez un backup de la clef et une bonne connaissance des adresses IP des serveurs autoritaires, sinon vous prenez le risque de passer un poil pour un guignol.
De base DNSSEC permet assez facilement de récupérer l'ensemble de votre zone, il y a des "bricolages" qui permettent de protéger vos fichiers zones (Universal DNSSEC, Online signing, NSEC3) mais bon ils ont tous des inconvénients et sont des degrés de protection variable (Universal DNSSEC n'est pas formalisé, Online signing oblige à laisser trainer les clefs privées sur tous les resolveurs et NSEC3 est déjà cassé)
[^] # Re: Enfin un journal qui dénonce grave...
Posté par Kaane . En réponse au journal De la nausée. Évalué à 5.
Tu as un exemple concret à donner ?
La théorie des nombres (hash, chiffrement, certaines formes d'indexation, compression sans perte etc.)
La théorie du signal (quasiment toute l'informatique s'appuie dessus - mais bon on peut citer l'ensemble des transmissions, les mécanismes de contrôles d'erreur, les évitements de collisions, certaines compressions (avec ou sans perte), a peu près tous les filtres possibles et imaginables)
Les processus stochastiques (génération d'entropie, calcul de risque, répartition de risque, nombreuses applications statistiques )
Ça c'est juste pour les parties qui ont des impacts directs depuis le fin fonds des mathématiques théoriques vers le bout du bout de l'informatique.
Après si on prend des domaines comme la théorie des graphes (en fait toute la topologie ou presque), la théorie de l'information ou encore l'algèbre linéaire - on a pas fini.
Dans mon travail de tout les jours je suis très loin de toute considération mathématique.
C'est vrai que la plupart des informaticiens sont utilisateurs des briques mathématiques pré-traduites par leurs ainés. Mais bon quand on met un index sur une base de données, ou même simplement que l'on ouvre une image PNG pour l'afficher à l'écran - il faut bien se rendre compre qu'il y a derrière un gros bagage mathématiques qui débarque (même si il est discret).
Ne serait-ce qu'un programme qui fait appel à des ondelettes ou à une transformée de Fourrier - ça ramasse des maths velues…
[^] # Re: Enfin un journal qui dénonce grave...
Posté par Kaane . En réponse au journal De la nausée. Évalué à 2.
La dette c’est la différence entre les dépenses et les recettes. Si l’état met en place un programme qui coûte 100.000€ financé par une levée de 100.000€ de taxes, ça te fait un financement par la dette du programme de… 0.
Si la collecte de la taxe est immédiate, si elle est immédiatement mise à disposition des services usagers et qu'il n'y avait pas besoin de verser d’acompte, voire de payer d'avance tout ou partie des biens oui. Dans les faits il y a quasiment une année fiscale de décalage entre la mise à disposition des biens et/ou des services et le versement de la taxe dans les caisses de l'état.
Et rappelons que dans la situation de ce journal, c’est pas « l’état qui dépense » vs « les particuliers qui dépensent », mais « l’état qui dépense » (en salaires de fonctionnaires) vs « l’état qui dépense » (en achats auprès de Microsoft).
Tout à fait, j'intervenais juste sur la partie "masquage" de dette tel qu'évoqué par thamieu. Du genre de ce que l'on a avec les mutuelles obligatoires cumulées en France. Dans ce type de relations, l'état n'intervient plus du tout - ce sont les entreprises qui effectuent le travail de collecte et de reversement.
[^] # Re: Enfin un journal qui dénonce grave...
Posté par Kaane . En réponse au journal De la nausée. Évalué à 3.
Oui mais sur l'opération visée, dans un cas on a un ratio ( augmentation de dette publique ) / ( augmentation de PIB ) de 100% - tant que la dette publique est inférieure au PIB ça va venir augmenter le ratio dette publique sur PIB.
Dans le second cas seul le PIB va augmenter, la dette publique ne bronchera pas. La dette privée peut augmenter, mais la BCE se moque de la dette privée (ou alors elle a peur de chopper le vertige).
Par exemple si on a un produit à 100€ acheté tous les ans par l'état pour 1000 citoyens via une taxe. Mettons que cet état ait un PIB de 1 000 000€ (petit état) et une dette de 850 000€.
La banque autorise 80% de PIB en dette, le petit état a donc un problème de 50 000€.
Si l'état conserve un mécanisme de taxe, il va collecter 100 000€ qui vont venir en plus sur le PIB et il va dépenser 100 000€ qui vont venir en plus sur la dette.
On aura donc un PIB de 1 100 000€ et une dette de 950 000€. la banque autorise toujours 80% de dette soit 880 000€ maximum.
Notre petit état a maintenant un problème de 80 000€
Par contre si on passe par le mécanisme de dépense privée obligatoire, le PIB va toujours augmenter de 100 000€, mais la dette publique ne va pas broncher.
On aura un PIB de 1 100 000€ et une dette de 850 000€. Le seuil maximal d'endettement est comme à l'exemple précédent toujours à 880 000€.
Notre petit état a donc non seulement résolu son problème de 50 000€ du départ, mais en plus il se paye le luxe de récupérer 30 000€ de capacité d'endettement supplémentaire.
J'aurais du détailler plus, et j'ai pris pas mal de raccourcis dans mon énoncé précédent. Mais l'idée générale est là, la PIB augmente sans toucher à la dette publique ce qui permet de dégager une nouvelle capacité d'endettement (ou au moins de sauver les meubles).
[^] # Re: Enfin un journal qui dénonce grave...
Posté par Kaane . En réponse au journal De la nausée. Évalué à 6.
Dans le public en tant qu’usager ce qui sort de ma poche c’est le coût de fonctionnement de l’administration, qu’on appelle « dépense publique ». C’est donc normal de plus s’intéresser à la dépense du service public qu’aux dépenses des entreprises privée.
Supposons que l'état mette à disposition de ses citoyens des voitures, via financement par une taxe. Ce serait une dépense publique, donc un déficit qui viendrait aggraver la dette du pays.
A l'inverse si la dépense est effectuée par le citoyen lui même sur le territoire français il s'agit alors d'une opération commerciale qui accroit le PIB du pays et qui permet au contraire à l'état d'augmenter sa dette (puisque seul le ratio dette/PIB est pris en compte).
Donc au final même si toi ça te coute la même chose et que tu as vraiment besoin d'une voiture dans un cas le pays s'endette et dans l'autre cas le PIB du pays augmente - ce qui proportionnellement fait baisser sa dette.
Ben c'est pareil pour les mutuelles de santé, l'entretien des routes, l'école et les autres services "publics".
De fait l'état décale de plus en plus de dépenses du public vers le privé - C'est purement artificiel, en vrai ça ne change pas grand chose pour le contribuable (entre une taxe et une dépense obligatoire, la différence au niveau du portefeuille est nulle), mais ça baisse la dépense publique tout en faisant augmenter le PIB sans avoir à remettre en cause quoi que ce soit (Bon il y a bien quelques syndicats qui râlent des fois - mais ça se gère bien)
[^] # Re: « learning analytics » & cie
Posté par Kaane . En réponse au journal De la nausée. Évalué à 10.
Non car les chartes sont un contrat pouvant même avoir valeur juridique.
Généralement si tu trahis une charte tout ce qui va se passer c'est que tu n'auras plus le droit d'afficher le macaron vert et mauve de l'ecolo-entrepreneur responsable sur le mur de ta salle de réunion.
C'est limité comme valeur juridique.
[^] # Re: Merci beaucoup de lire entre les lignes
Posté par Kaane . En réponse au journal De la nausée. Évalué à 2.
Merci beaucoup, c'est ce qu'il se passe quand on écrit sous le coup de la colère.
Sans vouloir abuser il y a un
qui gagnerait franchement à être remplacé par
Merci d'avance.
[^] # Re: Euh moins connus que qui ?
Posté par Kaane . En réponse au journal Hommage aux Hackers moins-connus. Évalué à 3.
Apparemment c'est vraiment lui qui s'est prêté aux tests topcoder pour lesquels il a obtenu un score de 1044 (niveau débutant)
http://www.topcoder.com/members/mzuckerberg/details/?track=DATA_SCIENCE&subTrack=SRM
En tout cas ca a fait du bruit sur internet à l'époque et ça n'a pas été démenti.
Il y a eu pas mal de discussion sur Quora à ce sujet. Zuckerberg a d'ailleurs admis que d'Angelo lui avait appris pas mal de truc en programmation.
En ce qui concerne Bill Gates, les retours que j'ai viennent de personnes qui ont bossé pour Microsoft - PBPG entre autres, mais pas que. Bien qu'il ne code plus depuis un moment, il est resté capable d'assimiler des page set des pages de specs et de notions techniques en un temps record, y compris sur des sujets pointus comme le système de fichier ou la gestion protocoles réseaux.
Mais là c'est plus dur de trouver des sources fiables - il y avait une page avec un texte parlant d'une nouvelle fonctionnalité Office, et d'une correction à faire sur laquelle Bill Gates aurait ingurgité l'équivalent de 450 pages de doc technique en quelques heures et aurait posé des questions très pointues et pertinentes avant de donner son GO. Mais je ne la trouve plus.
[^] # Re: Hacker ?
Posté par Kaane . En réponse au journal Hommage aux Hackers moins-connus. Évalué à 3.
Parce que ce n'est pas la même chose ?
Appelle Hacker les personnes qui utilisent des outils facilement disponibles pour créer quelque chose d'innovant ou résoudre un problème technique - de préférence de façon soit rigolote soit spectaculaire.
Un hacker n'est pas forcément lié au domaine informatique, même si c'est là ou il y en a le plus je pense. Le monde de l’électronique et de la téléphonie regorgent de hackers.
Le Hack tient parfois de la jonglerie (je lance quatre truc en l'air dans le noir et je parie que j'arrive à les rattraper avant qu'ils ne touchent le sol), parfois du bricolage++ (façon Angus MacGyver), parfois de l'obstination statistique (ça a une chance sur 1 million de marcher ? Bon ben je créé un truc qui fait 10 000 essais par secondes - et j'attends).
[^] # Re: Euh moins connus que qui ?
Posté par Kaane . En réponse au journal Hommage aux Hackers moins-connus. Évalué à 10.
Malgré la définition très floue (et très disputée) du mot hacker, je ne considère ni l'un ni l'autre comme des hackers.
Jobs pas du tout, et Zuckerberg à peine. A la limite Moskovitz ça peut se discuter pour Facebook. Pour Apple le hacker "célèbre" c'est Wozniak.
Même Bill Gates (qui est très loin au niveau technique devant Jobs et Zuckerberg) peine à rentrer dans la catégorie "hacker".
Je m'attendais plus à du Seymour Cray, du Tanenbaum, ou du Linus Torvalds (même si son status de hacker est un peu en hiatus en ce moment, de son propre aveu)
# Euh moins connus que qui ?
Posté par Kaane . En réponse au journal Hommage aux Hackers moins-connus. Évalué à 6.
J'avoue volontiers ne pas connaitre Ilya Zhitomirskiy, mais les autres il sont quand même très largement dans les 100 hackers les plus connus.
On a juste dans l'ordre l'inventeur de l'IHM, du HTTP et de la souris, l'auteur du langage C et le petit génie inventeur du RSS et de créative common très médiatisé de part son suicide suite aux pressions de la justice américaine.
Si pour toi se sont des "seconds couteaux", je serais curieux de savoir qui tu mets en tête de liste.
Enfin j'imagine que ça veux surtout dire que même si on change la vie de milliards de gens (Zhitomirskiy pas encore) on ne devient pas forcément célèbre.
[^] # Re: Déjà ils proposent un PDF ..;
Posté par Kaane . En réponse au journal À quoi sert le RGI ?. Évalué à 10.
Tu as visiblement un gros problème à comprendre qu'il y a un facteur humain là dedans.
Et tu as visiblement un gros problème à comprendre qu'il y a DEUX facteurs humains.
Parce que le l'administré il veut bien comprendre pleins de choses, mais le niveau d'incompétence chronique dont font preuve les différentes administrations atteint en ce moment des records. Alors parfois c'est sur ordre (faut pas payer, faut prélever), mais dans l'immense majorité des cas il s'agit simplement d'un désintéressement total des choses du légal et du social quand ça avantage ou arrange l'administré et lui seul.
La création de documents numériques éditables et imprimable par toute personne qui le souhaite est un problème qui a bientôt vingt ans et qui a été résolu dans toutes les entreprises du monde. Beaucoup de sociétés qui n'ont aucune obligation à le faire ont de nombreux formulaires que l'on peut remplir en ligne, hors ligne ou manuellement.
Créer un PDF valide, un formulaire en ligne ou feuillet imprimable chez monsieur tout le monde ça n'est plus un problème. Même des sociétés très modestes arrivent à créer ou à faire créer des formulaires sécurisés compatibles avec les navigateurs des divers téléphones portables.
Par contre l'administration, qui a obligation de résultat, obligation de non discrimination et toutes les obligations afférentes liées au RGI se permet de t'envoyer balader quand par hasard tu fais remarquer que 7 manquements sur 6 obligations c'est quand même un joli score.
Donner des directives pour que les documents produits soient conformes à minima avec des lignes directrices, c'est long, c'est complexe humainement et tout ce que tu veux - mais c'est leur boulot. C'est une administration, bon sang, produire et valider des documents conformes c'est 95% de leur boulot.
Et l'administré en face il a autre chose à faire que de bricoler des documents dégénérés pour essayer de leur donner un sens, autre chose à faire que de recoller les informations pour comprendre ce que l'on attend de lui et autre chose à faire que de multiplier les aller retours à tel ou tel service public pour pousser un dossier qui n'avance pas parce que trop éloigné des dossiers "simples" à traiter.
Donc oui produire des documents conforme c'est complexe, mais
a) Aujourd'hui tout le monde y arrive sauf nos administrations
b) C'est le métier qu'ils ont choisit de faire en entrant dans cette section de la fonction publique - il serait bon qu'il fasse un peu semblant de s'y intéresser de temps à autre.
[^] # Re: et systemd ?
Posté par Kaane . En réponse au journal Les cgroups, un outil trop méconnu. Évalué à 10.
Oui et non.
Si il s'agit d'un processus lancé depuis un terminal ou un pseudo terminal, ça ne change pas grand chose. Il y a des projets de nouvelle interface pour les cgroups qui forcera une interface centralisée. Dans les systèmes utilisant le framework systemd c'est celui-ci qui s'occupera de gérer les cgroups.L'api et les commandes seront différentes, mais dans l'ensemble les fonctionnalités devrait être sensiblement les mêmes.
Par contre si il s'agit d'un processus détaché (daemon ou autre) géré par l'init, ça devient plus compliqué. Et c'est déjà le cas aujourd'hui, même sans la nouvelle interface.
Si le processus a été lancé par systemd il a nécessairement été placé dans une slice, c'est à dire une tranche de ressources configurée dans systemd. Par défaut il y a trois grande catégories de slice présente dans systemd
- la slice system, qui lance tous les services "classiques".
- la slice user, qui lance tous les services "utilisateurs" - c'est à dire ayant besoin d'avoir accès à logind)
- la slice machine qui gère les machines virtuelles et les containers (dans une certaine mesure, tout n'est pas supporté et tout ce qui est supporté n'est pas recommandé)
Il faut bien comprendre trois choses :
- Un processus ne peut appartenir qu'à un cgroup et un seul
- Quand un processus change de hiérarchie il devient littéralement invisible aux yeux des processus qui ne sont pas dans une hiérarchie ancêtre.
- Certains processus (par exemple logind) et certains devices (les cartes réseaux notamment) ne peuvent pas être déplacés, ré-alloués ou même relancés dans un autre cgroup sans heurts. (Et par heurts je veux dire passage de systemd en mode panique totale, avec tentative de relance en boucle de certains services)
A noter que le troisième point n'est en aucun cas une faute de systemd, simplement le résultat d'un choix qui a été fait dans un soucis de simplification. La nouvelle interface résoudra ce problème via la centralisation des appels.
De fait certaines opérations sur les cgroups qui sont possibles sans systemd deviennent très complexe avec systemd.
Par exemple supposons que je veuille mettre à disposition d'un client une machine virtuelle avec une carte réseau dédiée, et en plus une interface web de monitoring sur laquelle il peut se loguer en utilisant ses identifiants utilisateurs local (ou domaine).
Maintenant supposons que je veuille mettre des restrictions à tout ça en utilisant les cgroups. La transversalité du bignou va m'obliger à créer plusieurs tranches avec systemd et à composer avec les différents éléments.
Sans systemd je peux parfaitement créer une hiérarchie globale pour le client et mettre les restrictions dessus.
En plus certaines opérations, comme allouer un coeur CPU ou une carte réseau à un cgroup défini, geler un processus ou encore taguer les paquets en fonction de leur cgroup ne sont pas encore supportées par systemd.
Pour faire court :
- Pour l'instant sur tous les processus lancés depuis un tty, ça marche et ça devrait continuer de marcher - mais peut-être avec une API différente, et peut-être avec certains manques sous le framework systemd si les fonctionnalités manquantes aux slides en sont pas implémentées.
- En ce qui concerne les processus rattachés au PID 1,à aujourd'hui il y a des limitations - elles n'impactent probablement pas grand monde (mais j'en suis et ca me casse les pieds gravement)
Pour le futur ca dépendra du controlleur de cgroups au final, sous le framework systemd il y aura très probablement des manques dus aux choix architecturaux. Mais on ne sait jamais, il faut attendre les nouvelles interface et leur intégration pour être sur.
[^] # Re: Impartialité
Posté par Kaane . En réponse au journal 2017 : On change les têtes et on fait le grand ménage avant que le vent tourne. Évalué à 10.
PS : au fait, ce plan B qui serait accepté par plus de monde, il en est où?
Là : https://fr.wikipedia.org/wiki/Trait%C3%A9_de_Lisbonne
Adopté par tous les pays, y compris par l'Irlande en mode référendum.
Pas mal de pays ont fait l'impasse sur un second référendum, de peur que les idiots désinformés, abreuvés de flots populistes, ne votent mal une seconde fois. Ça se comprend note bien, la technique en vigueur du "On reproposera la même loi jusqu'à ce que vous la votiez" est très complexe à mettre en place à 27 pays.