Deux défis majeurs pour le Libre

a marqué ce sujet comme résolu.
Auteur du sujet

À la marge d’un commentaire d’une tribune ailleurs, je me suis demandé : quoi citer aujourd’hui comme des problèmes chauds, bouillants, difficiles, inquiétants qui sont à surmonter pour les communautés qui attachent de l’importance au logiciel libre, au savoir libre ?

Deux problèmes qui me viennent immédiatement, peut-être pour ouvrir une discussion :

  • On n’a pas de solution logicielle libre pour avoir un ordinateur personnel utilisable et sécurisé contre les acteurs étatiques (à conseiller à un journaliste dans un pays totalitaire, par exemple). Même contre la cyber-criminalité, la sécurité de l’écosystème des environnements de bureau au-dessus de Linux perd de l’avance et prend du retard sur les solutions verrouillées verticalement (Windows, OSX, les versions Google d’Android). La meilleure équipe de sécurité pour les logiciels libres en ce moment est celle de Google, et c’est un peu triste.

  • On n’a pas réussi à faire des progrès durables sur des propositions "libres" sérieuses dans les domaines artistiques et ludiques. Même chez les gens qui sont sensibilisés au logiciel libre, l’extrême majorité continue à écouter de la musique propriétaire, jouer à des jeux propriétaires, lire des livres diffusés en des termes très privateurs et généralement consommer et subventionner surtout de l’art qui n’est pas libre.

Quelques idées de gestes qui avancent dans la bonne direction:

  • Pour le premier point, apprendre à utiliser des techniques de programmation plus sûres et s’en servir dans ses projets libres. Essayer des langages qui rendent moins facile les failles, des outils de vérification de programmes, des architectures logicielles mieux compartementalisées et mieux conçues pour la sécurité.

  • Pour le second point, essayer au moins de se renseigner sur l’offre qui existe aujourd’hui et leur apporter un peu de publicité. Jouer à Battle for Wesnoth ou Xonotic (par exemple), écouter Regis Gronoff (par exemple), ou acheter et lire les auteurs de la maison d’édition C&F éditions qui propose des livres intéressants (souvent sur des thèmes pertinents pour les libristes), sans DRMs et qui essaie de transposer des idées de licences ouvertes à l’édition en poussant la licence Édition Équitable.

À vos idées/avis.

+2 -0

Bonjour ,

je trouve que contrairement à ce que tu dis je pense que Linux est peut être une des meilleur solution pour se protéger des attaques pirates et Windows et peut être le pire OS a utiliser pour se protéger (wanacry etc…) , Android et aussi réputé pour sa non-sécutrité. Mais en tant que OS libre et sécuritaire on peut citer OpenBSD qui est bien au dessus de tout les autres OS actuel propriétaire ou non. Et les mise a jour de sécurité de Linux sont beaucoup plus soutenue que Windows et la sécurité est loin d’être a la traîne.

Au niveau de la solution : les langages utilisé dans les logiciel libre sont a peu prés les même que ceux utilisé dans les logiciels propriétaires.

Pour ton deuxième point par contre je suis entièrement d’accord meme si je joue à Battle for Wesnoth (excellent jeu au passage pour les amateur de stratégie). Mais les autres jeux vidéos libres sont pour la plupart abandonné et plus soutenu ce qui est dommage. Ensuite pour ce qui est du libre dans des domaines autre que l’informatique je pense que c’est plus difficile de diffuser quelque chose de libre dans un domaine autre que l’informatique.

N’hésitez pas a aller voir le code source de mon projet Trapped Hero qui est en cour de migration vers une autre plateforme.

+0 -0

Ensuite pour ce qui est du libre dans des domaines autre que l’informatique je pense que c’est plus difficile de diffuser quelque chose de libre dans un domaine autre que l’informatique.

Linux

Tout dépend encore des domaines en question. Il est courant de trouver des contenus sous creative commons par exemple, que ce soit dans les tutos/articles/billets ici ou dans les images DeviantArt.

Concernant la sécurité, je pense qu’un des gros problèmes est surtout que pour l’instant, on a quasiment aucun outil simple à proposer, alors que c’est juste essentiel. Ok, gérer ses clés GPG en ligne de commande c’est classe, mais si on veut avoir une chance de convaincre les néophytes de chiffrer leurs messages, il faut un truc intuitif. Enigmail fait un pas dans cette direction, mais personnellement j’ai du mal avec l’ergonomie de Thunderbird, donc bon…

L’appli Silence est quant à elle très cool. Elle ressemble comme deux gouttes d’eau à une appli SMS classique, mais elle fourni des outils dont l’accès est simple, ce qui rend la migration très peu couteuse en "temps de cerveau".

En ajoutant à cela une forte dose d’éducation populaire sur « pourquoi la vie privée c’est important », on aura alors (je pense) une chance de pouvoir démocratiser la sécurité.

Concernant les arts, il y a un article de SpaceFox à ce sujet qui peut alimenter la réflexion : https://zestedesavoir.com/articles/1522/reflexions-sur-lart-libre-et-son-avenir/ ;)

"Les accidents dans un système doivent se produire, mais il n’est pas obligatoire qu’ils produisent pour vous et moi." Laurence Gonzales - Deep Survival

+2 -0
  • On n’a pas de solution logicielle libre pour avoir un ordinateur personnel utilisable et sécurisé contre les acteurs étatiques (à conseiller à un journaliste dans un pays totalitaire, par exemple).

Quelque chose comme Tails ? Qui d’ailleurs rend tout ce schmilblick (cryptage, Tor, etc.) peut-être un peu plus accessible aux novices (cf remarque de rezemika ci-dessus).

Édité par Arlequin

+1 -0

On n’a pas de solution logicielle libre pour avoir un ordinateur personnel utilisable et sécurisé contre les acteurs étatiques (à conseiller à un journaliste dans un pays totalitaire, par exemple). Même contre la cyber-criminalité, la sécurité de l’écosystème des environnements de bureau au-dessus de Linux perd de l’avance et prend du retard sur les solutions verrouillées verticalement (Windows, OSX, les versions Google d’Android). La meilleure équipe de sécurité pour les logiciels libres en ce moment est celle de Google, et c’est un peu triste.

Je ne sais pas exactement ce que tu recherche dans ce domaine mais des amis activistent utilisent tails qui semble bien fonctionner.

EDIT : grillée pour tails

Pour le second point, Il ne faut pas oublier que le logiciel et l’art ne fonctionnent pas tout à fait pareil. S’il est possible de vendre du support, du développement ou encore des services d’hébergement pour un logiciel, c’est malheureusement très difficile pour un jeu vidéo, un livre ou une musique (encore que pour la musique il y a les concert).

Pour que le libre fonctionne dans ces domaines, il faut des gens prêt à acheter quelque chose qu’ils pourraient avoir gratuitement. Ce qui correspond selon moi un changement de mentalité. En cherchant un peu, il y a quand même quelques initiatives qui tentent le coup. À nous d’essayer de les rendre viable :

Tout dépend encore des domaines en question. Il est courant de trouver des contenus sous creative commons par exemple, que ce soit dans les tutos/articles/billets ici ou dans les images DeviantArt.

Je pense aussi qu’on trouve de plus en plus de contenus sous licences creatives commons plus ou moins libre. C’est vrais aussi que ç’est encore principalement dans un milieu militant mais je pense aussi que beaucoup de gens n’ont aucune idée de comment fonctionne la propriété intellectuelle.

Édité par oiseauroch

+3 -0

1) comme mes VDD Tails ; 2) les gens se foutent de la licence, ils veulent du contenu de qualité. C’est pas parce que c’est libre qu’un logiciel ou une oeuvre est objectivement meilleur pour le plus grand nombre ;

Je suis sur téléphone, je ferais certainement un truc plus argumenté plus tard.

écolo-utopiste altermondialiste radicalisé sur Internet | La tero estas nur unu lando | Géographe de service | Cliquez 👍 pour dire merci

+1 -0

Hello, post très intéressant. =)

  • On n’a pas de solution logicielle libre pour avoir un ordinateur personnel utilisable et sécurisé contre les acteurs étatiques (à conseiller à un journaliste dans un pays totalitaire, par exemple). Même contre la cyber-criminalité, la sécurité de l’écosystème des environnements de bureau au-dessus de Linux perd de l’avance et prend du retard sur les solutions verrouillées verticalement (Windows, OSX, les versions Google d’Android). La meilleure équipe de sécurité pour les logiciels libres en ce moment est celle de Google, et c’est un peu triste.
gasche

Linux dispose depuis quelques années de beaucoup d’outils pour la sécurité. On peut citer Seccomp, Cgroups, les linux namespaces, SELinux, AppArmor, etc, chacun avec sa propre spécificité. Les outils comme les indexeurs de fichier ou les navigateurs web (chromium étant devant tout le monde là dessus) ont commencé à utiliser ça directement pour du self containement, et d’autres applications comme Flatpack ou Snapcraft permettent d’installer des applications qui sont déjà en partie conteneurisées, même s’il y a des défauts dans cette méthode.

Par rapport à Google, un gros défaut qu’ils ont est qu’on a un Android avec ASLR et processus zygote qui précharge une grosse masse de bibliothèques, donc l’ASLR ne sert pas beaucoup.

Sinon les outils de chiffrement sont là sous linux, que ce soit en ligne de commande ou en interface. Le problème vient principalement de leur difficulté de prise en main. Mais ça a l’avantage de forcer les utilisateurs à savoir un peu ce qu’ils font et les mets face aux limites des systèmes de ce type. Ça me parait difficile de faire de la sécurité «générique» qui fonctionnerait pour tout le monde sans gêner la moitié des gens, et c’est ce qui bloque les principales innovations sous linux (combien n’ont au moins rien qu’un MAC comme SElinux installé ?)

  • On n’a pas réussi à faire des progrès durables sur des propositions "libres" sérieuses dans les domaines artistiques et ludiques. Même chez les gens qui sont sensibilisés au logiciel libre, l’extrême majorité continue à écouter de la musique propriétaire, jouer à des jeux propriétaires, lire des livres diffusés en des termes très privateurs et généralement consommer et subventionner surtout de l’art qui n’est pas libre.
gasche

Comme mes VDD, ça me semble difficile de considérer que l’art libre devrait être la seule forme d’art, parce que ça me semble difficile d’en vivre dans la période actuelle. J’ai moins d’argument cependant.

+0 -0
oiseauroch

C’est David Revoy (mec super sympa au passage, pour avoir passé une semaine avec ^^). Et juste parce que c’est un film libre que j’apprécie beaucoup et sur lequel il était directeur artistique : Sintel - David Revoy


L’art libre, je ne sais pas, comme mes VDDs ça me semble plus compliqué d’en vivre, surtout pour ce qui est numérique. Après, pour ce qui est des œuvres "physiques" libre, le pas doit être beaucoup plus facile à franchir pour les artistes.

+0 -0

C’est David Revoy (mec super sympa au passage, pour avoir passé une semaine avec ^^). Et juste parce que c’est un film libre que j’apprécie beaucoup et sur lequel il était directeur artistique : Sintel - David Revoy

corrigé merci

Concernant l’art, je pense que publier sous licence libre est une approche différente de conserver les droits d’exploitations de l’oeuvre. En effet, Pour moi c’est aussi un message qui invite les autres à s’approprier l’oeuvre et à la modifier/partager au maximum. Je pense que ceux qui font de l’art libre voient plutôt leur oeuvre comme appartenant aux commun de l’humanité et non pas étant leur propriété.

Après, pour ce qui est des œuvres "physiques" libre, le pas doit être beaucoup plus facile à franchir pour les artistes.

Sur ce point je ne suis pas tout à fait d’accord. Les licences libres ont encore du mal à franchir le pas du monde "matériel". Ça me semble dû au fait qu’on voit moins l’intérêt de le faire (pourquoi mettre une statue sous licence libre si personne n’est en capacité de la reproduire) voir même qu’on n’a pas idée que ce soit possible.

Édité par oiseauroch

+0 -0

Après, pour ce qui est des œuvres "physiques" libre, le pas doit être beaucoup plus facile à franchir pour les artistes.

Sur ce point je ne suis pas tout à fait d’accord. Les licences libres ont encore du mal à franchir le pas du monde "matériel". Ça me semble dû au fait qu’on voit moins l’intérêt de le faire (pourquoi mettre une statue sous licence libre si personne n’est en capacité de la reproduire) voir même qu’on n’a pas idée que ce soit possible.

oiseauroch

J’aurais du dire "devrait". J’ai conscience que ce n’est pas courant, parce que, pourquoi rendre libre un objet qui globalement est et restera "unique" par sa conception. Mais c’est pour cela que ça devrait être plus facile de franchir le pas. On rend son art accessible, tout en pouvant toujours en vivre sans grande différence (contrairement aux œuvres numériques).

+0 -0

Je souhaiterais juste réagir à l’argument cité à de multiples reprises comme quoi on ne peut pas vivre facilement avec l’art libre. Avec le système actuel non plus.

Un auteur moyen1 touche en gros 2 SMIC par livre. Ça permet aux éditeurs de vivre (et encore, les petits se débattent pour survivre…), oui, mais sûrement pas aux auteurs.


  1. Oui, moyenne. Dans ce genre de cas, la médiane est sûrement inférieure.  

Hier, dans le parc, j’ai vu une petite vieille entourée de dinosaures aviens. Je donne pas cher de sa peau.

+0 -0
  • Pour le premier point, apprendre à utiliser des techniques de programmation plus sûres et s’en servir dans ses projets libres. Essayer des langages qui rendent moins facile les failles, des outils de vérification de programmes, des architectures logicielles mieux compartementalisées et mieux conçues pour la sécurité.
gasche

Un langage qui rend moins facile aux failles, il y à Ada. De mon point de vue, c’est un très bon langage mais qui, probablement pour ses origines (initialement développé pour l’armée) et le prix exorbitant des compilo à l’époque, n’a pas eux autant de succès que le C ou le C++, alors que c’est un langage multi-paradigme, qui supporte les types scalaires (possibilité de définir son propre type d’entier qui va dans une plage de valeur, en une ligne). Il disposes de fonctionnalités intéressantes. Et aujourd’hui il existe un compilateur gratuit pour ce langage.

  • Pour le second point, essayer au moins de se renseigner sur l’offre qui existe aujourd’hui et leur apporter un peu de publicité. Jouer à Battle for Wesnoth ou Xonotic (par exemple), écouter Regis Gronoff (par exemple), ou acheter et lire les auteurs de la maison d’édition C&F éditions qui propose des livres intéressants (souvent sur des thèmes pertinents pour les libristes), sans DRMs et qui essaie de transposer des idées de licences ouvertes à l’édition en poussant la licence Édition Équitable.
gasche

Là par contre je troue qu’il va y avoir des petits problèmes. La société actuelle, profondément ancrée à un système économique mal fichu (et qui, au passage, est basé sur l’endettement) fait que cela rend compliqué d’avoir du libre (et gratuit) partout. À un moment, il faut bien gagner sa vie (bien qu’auteur/compositeur/DJ/que-sais-je ne rapportent pas forcément de quoi vivre pour tous). Même si j’aimerai bien voir cela un jour, je ne pense pas que ce soit possible…

Édité par Heziode

+0 -0

Pour moi la meilleure solution est utopique parce qu’Apple voudra jamais, mais sortir le code source de Mac OS X sous licence libre (donc autoriser son utilisation sur des ordinateurs non Apple) constituerait une bonne solution à ces deux problèmes.

OS X est à la fois l’OS des artistes par excellence, à la fois meilleur que windows en terme de sécurité, à la fois proche de Linux à administrer (comparativement à Windows quoi), et à la fois facile d’accès aux utilisateurs.

C’est ce qui pourrait arriver de mieux à l’informatique pour les petits particuliers et au libre.

(mais c’est une utopie :p )

+0 -0
Auteur du sujet

Linux dispose depuis quelques années de beaucoup d’outils pour la sécurité. On peut citer Seccomp, Cgroups, les linux namespaces, SELinux, AppArmor, etc, chacun avec sa propre spécificité. Les outils comme les indexeurs de fichier ou les navigateurs web (chromium étant devant tout le monde là dessus) ont commencé à utiliser ça directement pour du self containement, et d’autres applications comme Flatpack ou Snapcraft permettent d’installer des applications qui sont déjà en partie conteneurisées, même s’il y a des défauts dans cette méthode.

Le noyau Linux est trop gros, et conçu d’une façon trop peu orientée vers la sécurité, pour être sûr. Tout solution qui est construite en supposant qu’on peut faire confiance au code du noyau, en particulier si elle repose sur des logiques compliquées en interne, est fondamentalement limitée à cause de ça. Je ne pense pas qu’on puisse sérieusement espérer faire de l’isolation sécurisée avec les cgroups (les développeurs noyaux sont lucides, ils n’osent même pas monter un filesystem sans les droits root), la plupart des designs de conteneurs souffrent de ce problème. Seccomp est un peu mieux parce que c’est du sandboxing très violent et avec une interface assez simple (donc moins de chance de se planter), ça limite les appels systèmes, donc la méthode d’interaction entre le code utilisateur et le noyau, donc ça réduit la surface d’attaque – ça reste non sûr, mais c’est moins pire. Les LSMs genre SELinux et AppArmor sont un peu entre les deux (moins fourre-tout et cassés que les cgroups, mais plus compliqués et donc moins robustes que seccomp), mais à ma connaissance on a encore beaucoup, beaucoup de mal à les déployer en pratique sur des machines utilisateurs (sans admin système expert qui les administre), et par ailleurs elles ne changent pas la façon dont on écrit les applications par-dessus (contrairement à seccomp), donc personnellement je pense que c’est impasse sur le long terme.

Quand on a un système comme Linux (ou la plupart des déploiements connus de Windows; je connais mal le monde Apple) qui n’est pas sécurisé par construction, parce que la surface d’attaque est trop importante et la méthodologie de développement pas assez rigoureuse, la seule solution pour offrir de la sécurité en pratique c’est de faire la course contre les méchants : tous les mois ils trouvent des failles, on essaie de les trouver aussi vite qu’eux ou plus vite et de les corriger rapidement. C’est une approche qui marchotte, on a la moitié de l’industrie qui se demande s’il n’y a pas un problème et l’autre qui se dit que comme tout le monde fait pareil, c’est sans doute que c’est la meilleure approche possible. Et tous les mois il y a une nouvelle faille, de nouvelles mises à jour, et les "amis activistes" mentionnés ci-dessus se content d’espérer très fort que les gens qui veulent leur faire la peau à eux n’ont pas fait partie du groupe qui a eu accès à la faille en avant-première.

Ce qui n’existe pas, c’est un système sécurisé par construction qui soit utilisable par le grand public. QubeOS par exemple va dans la bonne direction, mais reste trop confidentiel, utilise Xen qui n’est pas aussi robuste qu’on le voudrait, et fait tout reposer ensuite sur des noyaux Linux dans des hyperviseurs qui ne sont pas vraiment satisfaisants – mais au moins il y a une compartementalisation sérieuse.


Au sujet de "personne ne veut payer pour de l’art libre" : moi quand je fais du logiciel libre, c’est un acte de don, je ne cherche pas à en faire de l’argent. (En général.) Ça pourrait aussi être un mode de production artistique répandu, en fait ça l’est (Devianart, vidéos Youtube, etc.), mais en pratique on n’est pas passé à des œuvres explorables, modifiables et partageables de façon utile pour la création. Il y a aussi la question de la professionalisation (vivre du libre, même dans le logiciel ce n’est pas toujours évident), mais ce n’est pas la seule question intéressante.

+0 -0

Je ne comprend pas, pourquoi comparer des solutions de sécurité qui se complètent ?

Pour le noyau linux, l’objectif est de limiter la surface d’attaque, sinon on peut dire que toute sécurité ne sert à rien parce que ton CPU est déjà troué.

Édité par unidan

+2 -0

Tout solution qui est construite en supposant qu’on peut faire confiance au code du noyau, en particulier si elle repose sur des logiques compliquées en interne, est fondamentalement limitée à cause de ça.

C’est certain, mais après ce n’est pas une raison pour ne pas se baser dessus, faute de mieux.

Je veux dire, tout OS généraliste n’a pas une sécurité garantie, pourtant les bonnes pratiques (à raison) exploitent au mieux les mécanismes qu’ils proposent car ne pas les utiliser sous prétexte que l’OS n’est pas assez sûr est pire que de se reposer dessus.

Je ne pense pas qu’on puisse sérieusement espérer faire de l’isolation sécurisée avec les cgroups (les développeurs noyaux sont lucides, ils n’osent même pas monter un filesystem sans les droits root), la plupart des designs de conteneurs souffrent de ce problème.

Les conteneurs ne sont pas une sécurité absolue également parce qu’elles n’ont pas été conçues dans l’optique de la sécurité. Les conteneurs offrent surtout une abstraction de la machine, en permettant de l’isoler du reste de l’environnement pour simplifier son administration, son contrôle tout en protégeant contre les erreurs accidentelles (donc résister à un bogue, pas à une personne malveillante).

Et elles remplissent très bien ce rôle. Ce n’est pas totalement satisfaisant car on voudrait de la sécurité en plus mais cela demande du travail en plus.

Les LSMs genre SELinux et AppArmor sont un peu entre les deux (moins fourre-tout et cassés que les cgroups, mais plus compliqués et donc moins robustes que seccomp)

Tu compares des choux et des carottes. Les cgroups ne vise absolument pas le même rôle que les LSM ou Seccomp. De même que Seccomp et LSM sont complémentaires.

Le but de seccomp est que le développeur de l’application réduise au maximum la surface d’attaque aux fonctions dont il a réellement besoin en interne. Mais cela implique que le développeur l’utilise correctement.

LSM permet à l’administrateur de définir une politique de sécurité sur sa machine. Cela permet de pallier à l’absence (ou une mauvaise utilisation de celui-ci) d’usage de seccomp d’une application. Mais aussi à appliquer une politique de sécurité à une application dont tu n’as pas confiance. C’est-à-dire que si je n’ai pas confiance en Firefox (ou une application proprio dont on a pas le code source), je peux lui appliquer des contraintes fortes sans changer quoique ce soit au binaire.

Ce sont donc des mécanismes complémentaires, qui n’offrent pas la même possibilité et qui ne s’adressent pas aux mêmes personnes (l’un est plus pour le développeur, l’autre pour l’administrateur).

mais à ma connaissance on a encore beaucoup, beaucoup de mal à les déployer en pratique sur des machines utilisateurs (sans admin système expert qui les administre), et par ailleurs elles ne changent pas la façon dont on écrit les applications par-dessus (contrairement à seccomp), donc personnellement je pense que c’est impasse sur le long terme.

SELinux est utilisé par défaut dans tous les système Android vendus dans le commerce aujourd’hui. Les distributions comme Fedora, CentOS ou Red Hat s’en servent également par défaut. AppArmor pour Ubuntu.

Pourtant tous ces systèmes sont utilisables sans que l’utilisateur lambda n’ait à s’en préoccuper. Et cela rend bien des services.

Comme je l’ai dit, je pense qu’il est surtout illusoire de croire qu’il y a une manière ultime de faire de la sécurité. La sécurité doit reposer sur un ensemble de mécanismes de protections, potentiellement redondants mais surtout complémentaires, pour que si un maillon de la chaîne casse le reste ne soit pas pour autant compromis.

Si tu combines les cgroups avec une couche de seccomp, SELinux, un pare-feu, etc. par dessus, tu aboutis à une pile de sécurité ou d’isolation qui devient difficilement exploitable (il faudrait potentiellement plusieurs failles séparées pour en venir à bout).

Le risque 0 n’existant pas, je pense qu’on a pas des masses le choix de ce côté là. La seule solution ultime serait la preuve des programmes qui pourrait obtenir des garanties fortes de ce côté, mais tu le sais bien que cela n’est pas réaliste pour nos applications du quotidien.

parce que la surface d’attaque est trop importante et la méthodologie de développement pas assez rigoureuse, la seule solution pour offrir de la sécurité en pratique c’est de faire la course contre les méchants : tous les mois ils trouvent des failles, on essaie de les trouver aussi vite qu’eux ou plus vite et de les corriger rapidement.

Tu auras ce problème quelle que soit ta stratégie de sécurité. La sécurité parfaite n’existe pas, même les logiciels les mieux conçus peuvent avoir des failles.

Ce qui n’existe pas, c’est un système sécurisé par construction qui soit utilisable par le grand public.

Le problème est là, le grand public. La sécurité par essence restreint les possibilités et ajoute de la complexité d’usage. Si pour avoir une sécurité absolue tu ne peux rien faire, personne n’en voudra. Il faut un compromis.

Je me souviens par exemple d’un Français qui avait écrit un noyau compatible POSIX en grande partie pour le fun qui était par essence très sécurisée car toutes les applications étaient naturellement isolées. Par design, impossible d’y échapper.

La contrainte était que vim ne pouvait pas éditer des fichiers crées par Firefox par exemple. Vim ne pouvait pas appeler non plus un shell quelconque pour certaines choses. Car l’isolation était réellement totale.

Du coup la sécurité était sans doute assez bonne mais pour un usage quotidien c’est impossible de s’en servir. Et je pense vraiment que si tu veux une sécurité par construction absolue, tu aboutiras à ce genre de choses. Ce qui n’est pas satisfaisant non plus.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+2 -0
Auteur du sujet

Pour le noyau linux, l’objectif est de limiter la surface d’attaque, sinon on peut dire que toute sécurité ne sert à rien parce que ton CPU est déjà troué.

C’est un non-sens comme remarque. Pour avoir un système sécurisé il faut un processeur sûr et un noyau sûr. On travaille sur les deux en parallèle. Pour évaluer la sécurité d’un noyau, il faut d’une part se demander si, quand on fait abstraction des problèmes de CPU (par exemple en imaginant qu’on tourne sur un CPU parfait), le noyau permet de compromettre le système, et d’autre part se demander si, avec un CPU à risque (avec une compréhension des risques spécifiques à ce qui est difficile dans un CPU), le noyau facilite plus ou moins l’accès aux failles du CPU, ou est plus ou moins sensible à ces failles.

Comme je l’ai dit, je pense qu’il est surtout illusoire de croire qu’il y a une manière ultime de faire de la sécurité. La sécurité doit reposer sur un ensemble de mécanismes de protections, potentiellement redondants mais surtout complémentaires, pour que si un maillon de la chaîne casse le reste ne soit pas pour autant compromis.

Le fait qu’il soit un bon principe de composer des défenses en profondeur (certes) ne veut pas dire qu’on ne peut pas faire mieux que d’ajouter des rustines à un logiciel non-sûr.

Je dirais qu’il y a une manière ultime de faire de la sécurité, qui est de construire un système comme un empilement de briques de conception qui sont toutes conçues pour être sécurisées, et qui utilisent la meilleure approche possible / connue à ce jour pour être sécurisées.

Dans le monde du libre on est très très loin du compte aujourd’hui. On a des systèmes avec des fonctionnalités utilisables, mais peu de sécurité. Avec la pile à base de Linux la plus sécurisée qu’on sait faire aujourd’hui, tout personne qui a un peu réfléchi à ces questions

  1. sait qu’il existe de nombreuses failles de sécurité dans le code qui attendent d’être découvertes
  2. sait qu’il existe des failles de sécurité dans le code qui sont connues par des gens et pas encore corrigées

À partir de là, on peut faire de la mitigation, et espérer être plus rapide que les gens qui s’intéressent à nous personnellement – tant qu’on est quelqu’un de normal qui ne subit pas d’attaque ciblée. On n’est pas du tout au niveau que je mentionnais en entrée, une « solution logicielle libre pour avoir un ordinateur personnel utilisable et sécurisé contre les acteurs étatiques ».

Il est tout à fait possible (et, je pense, réaliste) de rêver d’un système mieux conçu pour la sécurité (qui intègre de la compartementalisation à tous les niveaux, a une conception et une ingénérie plus soigneuse, intègre des méthodes formelles, etc.) tel qu’une personne compétente ne sait pas, à un moment donné, s’il existe une faille ou non. On ne peut pas l’exclure, donc on empile les défenses en profondeur, mais au moins on part d’un système qui ne nous rend pas certain qu’il est troué.

C’est le cas par exemple de la plupart des algorithmes de cryptographie standard, par exemple les algorithmes de chiffrement. Une personne compétente sur ces questions se demande toujours s’il n’y a pas des espions très forts à la NSA ou autre qui ont gardé secret une attaque d’un genre inconnu de la communauté universitaire. Mais elle ne sait pas si l’algorithme est sûr ou non. J’aimerais un système d’exploitation qui a les mêmes propriétés.

La seule solution ultime serait la preuve des programmes qui pourrait obtenir des garanties fortes de ce côté, mais tu le sais bien que cela n’est pas réaliste pour nos applications du quotidien.

Je ne pense pas que la preuve de programme soit une solution ultime, mais je pense qu’elle pourrait effectivement donner une confiance très forte dans la sécurité d’un système. Elle est tout à fait réaliste si elle est bien utilisée. Un hyperviseur, par exemple, pourrait être vérifié par ordinateur – on pourrait sans doute construire un hyperviseur au-dessus du noyau SeL4 vérifié, mais il serait aussi raisonnable de repartir de zéro car ce sont des systèmes assez simples, d’ailleurs je suis sûr que des gens travaillent là-dessus. Avec un système à la QubesOS par-dessus, on peut déjà avoir un système avec une compartementalisation très forte; ce n’est pas tout, mais c’est un premier pas.

Tu mentionnes le fait qu’une isolation totale n’est pas utilisable; certes. Tout le jeu, même quand on sait obtenir une isolation totale, c’est de trouver des manières d’autoriser certains échanges d’information qui répondent à nos besoins sans compromettre la sécurité plus que nécessaire. C’est le gros du travail de QubesOS, par exemple (ou SubgraphOS, etc.), ou de certains outils de plus haut-niveau comme Shill, le prototype de shell sécurisé, ou le noyau de Chromium. Mais aujourd’hui la plupart des gens ne se posent même pas la question, et développent des applications et des APIs qui supposent que toutes les informations de l’utilisateur sont accessibles à tous (le filesystem, le DOM, etc.). Tant qu’on ne pousse pas des solutions de sécurité qui changent la façon dont on pense au développement d’applications pour minimiser les privilèges et réfléchir spécifiquement aux points de dés-isolation nécessaire, elles resteront peu sécurisées, même par dessus un système d’exploitation sûr. (On pourrait pousser ces approches au-dessus de Linux, sans attendre le nouveau système de la mort; c’est l’approche de Capsicum par exemple, mais ça intéresse tellement peu de gens que ça avance très lentement.)

Les communautés du logiciel libre ont parfois su construire, incrémentalement, des solutions vraiment ambitieuses et impressionnantes par rapport à l’état de départ. On pourrait espérer construire un système sécurisé de cette façon.
Et puis on peut aussi limiter les ambitions qu’on a en terme de fonctionnalités. Si on pouvait construire, par exemple, un système sûr (selon le critère "on ne sait pas s’il y a une faille") qui permette juste de se connecter en ethernet pour recevoir et d’envoyer des messages chiffrés, contenant uniquement du texte et des images, et d’utiliser le copier/coller pour transférer du contenu entre ces messages et un système de fichier local sécurisé, on aurait déjà quelque chose d’utile à des gens dans la vraie vie. On en est loin.

Mais aujourd’hui ça intéresse peu de gens – la majorité préfère se contenter de la course-à-la-dernière-faille-publiée, parce que tout le monde fait ça, et se voiler un peu la face.

+1 -1

C’est un non-sens comme remarque. Pour avoir un système sécurisé il faut un processeur sûr et un noyau sûr. On travaille sur les deux en parallèle. Pour évaluer la sécurité d’un noyau, il faut d’une part se demander si, quand on fait abstraction des problèmes de CPU (par exemple en imaginant qu’on tourne sur un CPU parfait), le noyau permet de compromettre le système, et d’autre part se demander si, avec un CPU à risque (avec une compréhension des risques spécifiques à ce qui est difficile dans un CPU), le noyau facilite plus ou moins l’accès aux failles du CPU, ou est plus ou moins sensible à ces failles.

Tu n’as pas compris ce que j’ai dit. Le parallèle que tu fais entre le CPU et le noyau est très exactement ce que j’ai critiqué : tu as plusieurs surfaces d’attaques et tu essayes de réduire chacune d’entre elles. C’est pour ça que comparer individuellement des solutions de sécurité qui sont complémentaires en citant les zones qu’elles ne couvrent pas n’apporte rien.

Le fait qu’il soit un bon principe de composer des défenses en profondeur (certes) ne veut pas dire qu’on ne peut pas faire mieux que d’ajouter des rustines à un logiciel non-sûr.

Ta définition de rustine est étrange. S’il y a des façons beaucoup plus élégantes de réaliser des solutions de sécurité, il y en a beaucoup moins pour le faire dans un environnement utilisable par tous.

Le gros problème de ces solutions est qu’elles mettent la pression au niveau du développeur de l’application finale et demande beaucoup de connaissances de fond ce qui les rend peu satisfaisante pour avoir un environnement complètement safe, mais il ne s’agit plus de rustine (c’est plus ptrace quoi). C’est cette difficulté qui ressort de messages de Theo de Raadt à l’encontre de Firefox quand il critique la séparation des privilèges appliqués dans le logiciel.

Si ce que tu veux faire est supprimer totalement la surface d’attaque tu as de meilleures solutions mais tes usages prennent le contre coup également.

Et puis on peut aussi limiter les ambitions qu’on a en terme de fonctionnalités.

Ce serait l’idéal, mais on peut argumenter que le système le plus sûr est déjà celui qui n’existe pas et que vouloir forcément tendre vers lui n’est pas une bonne idée pour nos usages. Si ta solution de sécurité ne couvre pas les besoins d’aujourd’hui, elle ne sera pas utilisée et n’apporte donc aucune sécurité.

+0 -0

C’est un non-sens comme remarque. Pour avoir un système sécurisé il faut un processeur sûr et un noyau sûr.

Bah non, et justement avoir une sécurité qui repose uniquement sur la sécurité de tous ses composants est très fragile. Il faut que le noyau soit capable de sécuriser ton système malgré une faille d’un processeur et inversement dans la mesure du possible.

Le fait qu’il soit un bon principe de composer des défenses en profondeur (certes) ne veut pas dire qu’on ne peut pas faire mieux que d’ajouter des rustines à un logiciel non-sûr.

Où est la limite entre une rustine et un vrai concept de sécurité ? Dans le noyau Linux il y a des rustines mais pas que.

Dans le monde du libre on est très très loin du compte aujourd’hui. On a des systèmes avec des fonctionnalités utilisables, mais peu de sécurité. Avec la pile à base de Linux la plus sécurisée qu’on sait faire aujourd’hui, tout personne qui a un peu réfléchi à ces questions

Ce qui amusant en discutant avec toi c’est qu’il ne semble y avoir que la seule approche théorique qui vaille, comme si le développement logiciel n’était conçu qu’autour d’un seul concept, ici la sécurité.

Figure toi que non. La sécurité n’est pas un absolu à attendre, c’est un critère parmi d’autres. Les fonctionnalités, la performance, etc ont aussi une importance significative (un logiciel sécurisé mais non simple d’utilisation n’aura pas d’utilisateur, un logiciel sûr mais lent n’en aura pas non plus). La compatibilité ascendante aussi prime (et POSIX a été élaboré à une époque différente d’aujourd’hui).

C’est entre autre une des raisons pourquoi Linux et d’autres projets ont refusé des correctifs pour améliorer la sécurité car la dégradation des performances était trop forte pour un gain qui n’en valait pas la chandelle. Voir GRSecurity et les polémiques autours.

On pourrait d’ailleurs rappelé que le micro-noyau serait une architecture plus sécurisée. Pourtant malgré des moyens importants et des équipes de sécurité et de R&D à la hauteur ils n’ont pas de micro-noyaux purs dans leurs produits : performances non acceptables.

On peut également parler de d’autres domaines que je connais bien comme l’aéronautique. Toute la conception d’un avion est conçu sur l’évaluation du bénéfice / risque. Un avion est par exemple conçu pour résister à un choc dans un moteur avec un oiseau de la taille d’un poulet. Si l’avion traverse un groupe d’oiseau ou s’il touche un oiseau plus gros (comme lors du crash d’Hudson) l’avion va se cracher avec des morts à la clé très probablement.

Est-ce que pour s’approcher du risque 0 il faudrait demander des contraintes plus fortes encore ? Peut être, mais le coût de conception et de maintenance des appareils sera plus important, le coût du carburant aussi (car avion plus lourd) tout ça pour gérer des cas qui n’arrivent presque jamais (mais qui peuvent arriver).

D’ailleurs tu noteras qu’une faille de sécurité ne signifie pas que :

  • Elle soit exploitable facilement (certaines failles ne sont même pas exploitables sans entrer dans des conditions extrêmement rares, et nécessiter de gros efforts) ;
  • Qu’elle soit économiquement exploitable (il est souvent plus facile d’attaquer l’humain qui utilise la machine que les failles qui regorgent dans le système) ;
  • Qu’en tirer avantage de la faille soit également possible. Typiquement une faille qui te permet d’accéder à des portions de mémoire mais dont tu ignores tout du contenu et dont tu n’as pas contrôle sur ce que tu lis. Pourtant c’est une faille.

Suffit d’ailleurs de le voir dans la vraie vie, de nombreuses failles existantes, documentées et corriges ne sont pas exploitées sur les systèmes vulnérables car ce n’est pas simple. Et dans la vie quotidienne des cas comme ça tu en as partout des cas similaires. Toute serrure d’une maison ou d’une voiture est vulnérable suivant les moyens qu’on y met. Et malgré tout pas tout le monde se fait cambrioler, pas tout le monde met des tonnes de sous pour avoir une porte blindée ou autres mécanismes. Et dans certains pays comme au Canada nombreux sont ceux qui ne verrouillent même pas leur porte ! Pourquoi l’informatique devrait avoir une sécurité aussi forte au détriment de l’utilisabilité et des performances ? J’espère que par esprit de cohérence tu as bien sécuriser ton logement et ton moyen de transport car les failles sont évidentes et connues aussi.

C’est discutable. Loin d’être une si grande évidence.

Il est tout à fait possible (et, je pense, réaliste) de rêver d’un système mieux conçu pour la sécurité (qui intègre de la compartementalisation à tous les niveaux, a une conception et une ingénérie plus soigneuse, intègre des méthodes formelles, etc.) tel qu’une personne compétente ne sait pas, à un moment donné, s’il existe une faille ou non. On ne peut pas l’exclure, donc on empile les défenses en profondeur, mais au moins on part d’un système qui ne nous rend pas certain qu’il est troué.

À part avec une démonstration mathématique rigoureuse, tu ne peux démontrer l’absence de quelque chose. Au mieux tu démontrent l’existence de quelque chose. C’est la base du raisonnement scientifique.

Partant de là, à part si la conception annoncée a été démontrée comme sûr, tu ne peux d’un côté affirmer, sans preuves qu’il y a des bogues ou des failles et de l’autre côté non avec les mêmes éléments de preuve.

Les communautés du logiciel libre ont parfois su construire, incrémentalement, des solutions vraiment ambitieuses et impressionnantes par rapport à l’état de départ. On pourrait espérer construire un système sécurisé de cette façon.

Je rappelle, et tu le sais, que le LL est conçu par ceux qui font, pas ceux qui discutent. Si tu veux un tel système sécurisé, et je n’ai rien contre cela d’ailleurs (je pense juste que ce qui tu veux obtenir révèle de l’utopie), à toi de fonder ta communauté et de lancer un projet là dedans.

Si on pouvait construire, par exemple, un système sûr (selon le critère "on ne sait pas s’il y a une faille") qui permette juste de se connecter en ethernet pour recevoir et d’envoyer des messages chiffrés, contenant uniquement du texte et des images, et d’utiliser le copier/coller pour transférer du contenu entre ces messages et un système de fichier local sécurisé, on aurait déjà quelque chose d’utile à des gens dans la vraie vie.

Je te le dis tout de suite, très peu de gens accepteraient si peu de fonctionnalités de leur machine et préfèreront un peu moins de sécurité en faveur de la sécurité. C’est un peu comme vouloir l’absence d’attentats tout en ayant toutes nos libertés individuelles en même temps, tu demandes des choses qui sont par essence partiellement contradictoires et comme souvent un compromis doit être trouvé. Le compromis étant entre fonctionnalité - sécurité - performances - coût. Trop avantager l’un ou l’autre des critères n’est pas bon, sécurité inclue.

Mais aujourd’hui ça intéresse peu de gens – la majorité préfère se contenter de la course-à-la-dernière-faille-publiée, parce que tout le monde fait ça, et se voiler un peu la face.

Ou alors c’est que :

  • Les développeurs en question se foutent de la sécurité (et c’est leur droit) ;
  • Qu’ils sont pragmatiques et qui acceptent moins de sécurité quelque part si cela permet de gagner du temps (et donc de l’argent potentiellement), des perfs ou des fonctionnalités essentielles ;
  • Que le milieu de la sécurité sait qu’une faille découverte n’est pas synonyme d’une exploitation, et encore moins à grande échelle et à distance.

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+0 -0
Auteur du sujet

Il faut que le noyau soit capable de sécuriser ton système malgré une faille d’un processeur et inversement dans la mesure du possible.

… et c’est justement ce que je rappelle dans la suite du même paragraphe que tu viens de citer. Mais un noyau ne peut nous protéger que de certaines rares failles d’un processeur, en général les utilisateurs peuvent l’exploiter aussi – d’ailleurs il me semble que toutes les dernières failles CPU connues sont exploitables côté utilisateur, par RowHammer ou Meltdown/Spectre.

Ce qui amusant en discutant avec toi c’est qu’il ne semble y avoir que la seule approche théorique qui vaille, comme si le développement logiciel n’était conçu qu’autour d’un seul concept, ici la sécurité.

Je me permets de rappeler le sujet de cette discussion:

Quoi citer aujourd’hui comme des problèmes chauds, bouillants, difficiles, inquiétants qui sont à surmonter pour les communautés qui attachent de l’importance au logiciel libre, au savoir libre ?
[..]
On n’a pas de solution logicielle libre pour avoir un ordinateur personnel utilisable et sécurisé contre les acteurs étatiques (à conseiller à un journaliste dans un pays totalitaire, par exemple).

Le reste de ton message est une série de commentaires raisonnables mais qui ne me semblent pas en rapport avec ma suggestion de problème non résolu – la disponibilité d’une base logicielle libre et vraiment sûre pour les gens qui ont besoin de résister à une attaque ciblée.

Partant de là, à part si la conception annoncée a été démontrée comme sûr, tu ne peux d’un côté affirmer, sans preuves qu’il y a des bogues ou des failles et de l’autre côté non avec les mêmes éléments de preuve.

Je faisais une différence entre les systèmes dont, même en ayant empilé toutes les protections et tous les correctifs connus à un instant T donné, un expert du domaine sait¹ (par intuition, expérience, etc.) qu’il existe des failles qui restent à découvrir voire qui sont connues d’un petit nombre d’acteurs en avance (typiquement la situation du monde Linux), et les systèmes pour lesquels un expert du domaine ne sait pas s’il reste des failles à découvrir (la situation de certains algorithmes cryptographiques, pas tous). La démonstration mathématique est une façon parmi d’autres d’obtenir des certitudes fortes (mais elle ne suffit pas toujours).

¹: par sait ici je veux dire "est très fortement convaincu de", "est certain de", "mettrait sa main au feu que", etc.

Ce n’est pas une différence de nature mathématique, mais une différence liée à l’ingénérie des systèmes – certaines méthodes de conception donnent confiance en la possibilité qu’il ne reste plus de faille dans une certaine partie bien définie d’un système, d’autres ne donnent pas cette confiance, ou donnent au contraire une confiance en l’existence de failles bientôt publiées. C’est sur ce principe que reposent les niveaux d’assurance de sécurité (EAL), et les niveaux EAL5/EAL6 cherchent justement à apporter ce genre de confiance sans demander une preuve formelle de bout en bout.

Édité par gasche

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte