Discussion :

[kain_tn]

Il me semble que le point le plus important c'est quand même de faire prendre conscience que l'open source peut être à double tranchant.
Des personnes mal intentionnée peuvent (et ne s'en privent sûrement pas) introduire des vulnérabilités.

Oui, tout comme le Closed-Source (rien que ces derniers mois, on a Ubiquiti, Microsoft Azure à travers Solar Winds Orion, puis Microsoft Exchange. les firewalls Zyxel et leur compte admin caché et codé en dur, et pas plus tard qu'aujourd'hui un article sur Clickstudios PasswordState).

L'Open-Source est tout aussi vulnérable, comme tu le soulignes, et tu as raison (d'ailleurs, il me semble que c'était un des postulats de l'article de recherche en question).

Du coup il est important de tirer parti d'un avantage de l'Open Source: auditer le code.

Après, il ne faut pas se le cacher, les audits ça coûte cher et les gens vraiment compétents ne courent pas les rues.

[Uther]

Il me semble que le point le plus important c'est quand même de faire prendre conscience que l'open source peut être à double tranchant.
Des personnes mal intentionnée peuvent (et ne s'en privent sûrement pas) introduire des vulnérabilités.
Que les mainteneurs ne les voient pas ne fait pas forcement d'eux de mauvais travailleurs.

Le problème n'est pas l'open source en soi : des backdoors ont aussi été introduites dans des logiciels propriétaires. La clé c'est le système de revue, l'expérience visait avant tout a montrer les faiblesse du système de revue qui n'est pas en mesure de relever efficacement certaine vulnérabilités comme les "use after free".

[walfrat]

Le problème n'est pas l'open source en soi : des backdoors ont aussi été introduites dans des logiciels propriétaires. La clé c'est le système de revue, l'expérience visait avant tout a montrer les faiblesse du système de revue qui n'est pas en mesure de relever efficacement certaine vulnérabilités comme les "use after free".

Le problème, c'est que ça me paraît très difficile à une personne révisant le code de :

1. Vérifier que ça marche et que ça n'introduit pas d'autres bug
2. Passe en revue la liste complète des trous de sécurités possibles pour vérifier qu'on en a pas introduit un.

Le mieux serait sans doute d'augmenter la détection automatique.

Malheureusement cela signifierait sans doute qu'il faudra aider les outils, par exemple en indiquant quelle variable ne peut pas être accéder sans se situer dans un code qui fait un lock etc.

[kain_tn]

Malheureusement cela signifierait sans doute qu'il faudra aider les outils, par exemple en indiquant quelle variable ne peut pas être accéder sans se situer dans un code qui fait un lock etc.

Oui, c'est justement un des arguments de l'arrivée de Rust dans le noyau.

[BugFactory]

Qu'en est-il des autres projets open source victimes de cette expérience? Les vulnérabilités introduites sont-elles en production? Ces chercheurs se sont-ils excusés pour cela ou bien est-ce qu'ils ne se sont excusés qu'auprès de la communauté Linux parce que oups! il y a des représailles?

[Uther]

A ma connaissance Linux était le seul projet étudié, mais si il y en avait d'autre, il n'y a pas de raison qu'ils aient été traités de la même façon, il ne devrait pas y avoir de faille introduite. Le but de l'expérience et de tester les processus de review, les patch ont été signalés par l'équipe elle même avant qu'ils arrivent dans le code final.

[BugFactory]

Merci pour la réponse rapide. Ce qui me dérange c'est qu'on ne sait pas si les responsables des projets vulnérables ont été prévenus.

(Pourquoi un -1, mes questions me paraissent pertinentes?)

[kain_tn]

Merci pour la réponse rapide. Ce qui me dérange c'est qu'on ne sait pas si les responsables des projets vulnérables ont été prévenus.

(Pourquoi un -1, mes questions me paraissent pertinentes?)

Je ne sais pas qui a mis le "-1", mais je pense que c'est en relation avec le fait que l'on a déjà répondu à ta question dans les messages précédents, et que les chercheurs en parlent aussi dans leur article: comme dit avant, les chercheurs n'ont fait qu'analyser des bugs sur les autres projets; ils ne leur ont soumis aucun correctif/patch/vulnérabilité.

[Bill Fassinou]

La Fondation Linux veut des détails sur toutes les contributions au noyau Linux faites par l'université du Minnesota
avant qu'elle ne soit autorisée à contribuer à nouveau au noyau

Quelques jours sont passés depuis le scandale des « commits hypocrites » qui a éclaboussé la communauté Linux. Après que Greg Kroah-Hartman, le mainteneur du noyau Linux pour la branche stable, a refusé les excuses des chercheurs impliqués dans ce geste malencontreux, l'on apprend que la Fondation Linux a adressé un certain nombre de demandes à l'université du Minnesota (UMN) auxquelles elle doit répondre avant que son personnel ne soit autorisé à contribuer à nouveau au noyau. La fondation exige que l'UMN lui fournisse "toutes les informations nécessaires pour identifier toutes les propositions de code vulnérable connu de toute son expérience".

Tous les commits provenant de l'UMN pourraient être réexaminés

Dernièrement, la communauté du noyau Linux a quelque peu été agitée en raison des efforts déployés par des chercheurs de l'UMN pour torpiller intentionnellement la sécurité de Linux en soumettant des correctifs défectueux. Depuis l'incident, les chercheurs, Qiushi Wu et Aditya Pakki, et leur conseiller diplômé, Kangjie Lu, professeur adjoint au département des sciences et de l'ingénierie informatiques de l'UMN, ont présenté leurs excuses pour leurs bévues concernant le noyau Linux. Mais cela n'a pas suffi. Greg Kroah-Hartman, le mainteneur principal du noyau Linux, demande plus.

Les développeurs du noyau Linux et le comité consultatif technique de la Fondation Linux, via la Fondation Linux, ont demandé à l'UMN de prendre des mesures spécifiques avant que leurs collaborateurs ne soient autorisés à contribuer à nouveau à Linux. Greg Kroah-Hartman a en effet proposé de revoir et de purger toutes les contributions au noyau faites à partir des adresses électroniques officielles de l'Université du Minnesota. Il est donc demandé à l'UMN de fournir à la fondation "toutes les informations nécessaires pour identifier toutes les propositions de code connu comme vulnérable provenant de toute expérience de l'UMN".

« Veuillez fournir au public, de manière accélérée, toutes les informations nécessaires pour identifier toutes les propositions de code connu pour être vulnérable de toute expérience de l'Université du Minnesota. Les informations doivent inclure le nom de chaque logiciel ciblé, les informations de commit, le nom supposé de l'auteur, l'adresse e-mail, la date et l'heure, le sujet et/ou le code, afin que tous les développeurs de logiciels puissent rapidement identifier ces propositions et éventuellement prendre des mesures correctives pour ces expériences », exige la lettre signée par Mike Dolan, vice-président senior et directeur général des projets de la Fondation Linux.

En fait, il a toujours été possible d'introduire du mauvais code dans de bons projets open source. Les logiciels open source ne seraient pas intrinsèquement sûrs. C'est plutôt le processus d'open source qui est sûr, et bien que ce processus entre en jeu pendant le développement, les analystes estiment qu'il est sans doute plus efficace après la découverte de vulnérabilités. Cela ne signifie pas que l'open source, en général, ou le noyau Linux, en particulier, est en quelque sorte imperméable aux failles de sécurité. En fait, comme l'a écrit Laura Abbott, contributeur du noyau Linux, les failles sont une procédure opérationnelle standard.

« Le problème avec l'approche adoptée par les auteurs [chercheurs de l'UMN] est qu'elle ne montre rien de particulièrement nouveau. La communauté du noyau est bien consciente de cette lacune depuis un certain temps. Personne n'a besoin d'introduire intentionnellement des bogues dans le noyau, nous sommes parfaitement capables de le faire dans le cadre de notre travail normal. Personnellement, j'ai introduit des bogues comme ceux que les chercheurs ont introduits, non pas parce que je veux détruire le noyau de l'intérieur, mais parce que je ne suis pas infaillible », a-t-elle déclaré.

La Fondation Linux boude la recherche non encadrée sur l'homme

Les "mauvais" correctifs de sécurité soumis par les chercheurs de l'université de l'UMN s'inscrivaient en effet dans le cadre d'une recherche. Bien qu'ils affirment que l'intention de leur projet était d'aider à améliorer le processus d'examen de la sécurité du noyau Linux, c'est la manière dont ils ont mené leur "expérience" qui ne convient pas aux développeurs. Dans une FAQ, les chercheurs ont tout d'abord affirmé qu'ils n'avaient pas demandé l'approbation préalable de l'Institutional Review Board (IRB) de l'université, car le projet n'était pas considéré comme une "recherche sur l'homme".

Dans la lettre, Mike Dolan remet toutefois les pendules à l'heure. « Nous pensons que les expériences sur des personnes sans leur consentement sont contraires à l'éthique, et impliquent probablement de nombreux problèmes juridiques. Les personnes font partie intégrante du processus de révision et de développement des logiciels. Les développeurs du noyau Linux ne sont pas des sujets de test, et ne doivent pas être traités comme tels », écrit Dolan. À la lumière de ces éléments, il demande à l'UMN de retirer le document (le rapport de l'étude) de toute publication officielle.

Dolan a déclaré : « l'article doit être retiré de la publication et de la présentation officielles de tous les travaux de recherche basés sur cette recherche ou sur des recherches similaires où des personnes semblent avoir été soumises à des expériences sans leur consentement préalable. Laisser des informations d'archives publiées sur Internet est acceptable, car elles sont pour la plupart déjà publiques, mais il ne devrait y avoir aucun crédit de recherche pour de tels travaux ». En l'état actuel des choses, l'article a été accepté pour publication par l'IEEE Symposium on Security and Privacy (IEEE S&P) 2021.

L'UMN n'a pas encore répondu à la lettre. Selon les développeurs du noyau, trouver tous ces commits est actuellement un vrai problème. Le développeur principal du noyau Linux, Al Viro, qui a repéré le premier faux correctif d'avril, a fait remarquer : « S'ils avaient pris la peine de joindre la liste (ou un lien vers une telle liste) de SHA1 des commits qui étaient sortis de leur expérience, ou, mieux encore, s'ils avaient maintenu et fourni la liste des identifiants de messages de toutes les soumissions, réussies ou non, ce désordre avec des demandes de retour en arrière générales, etc. aurait été beaucoup plus petit (s'il s'était produit) ».

En l'état actuel des choses, les développeurs et committers de Linux passent leur temps à réviser plusieurs centaines de correctifs du noyau Linux de l'UMN. Dolan a expliqué que le but de tout cela est d'éliminer tout dommage potentiel et perçu de ces activités, d'éliminer tout bénéfice perçu de ces activités et d'empêcher qu'elles ne se reproduisent. « Nous espérons voir à l'avenir des contributions open source productives et appropriées de la part de vos étudiants et de votre faculté, comme nous l'avons vu les années précédentes de la part de votre institution », a-t-il déclaré.

La Fondation Linux souhaite que l'école réponde à ces demandes le plus rapidement possible. Les mainteneurs de Linux veulent également savoir ce qu'il en est des correctifs de l'UMN, afin de pouvoir les trouver et passer à autre chose. Ils préfèrent travailler à l'amélioration de Linux plutôt que de rechercher d'éventuelles erreurs délibérées.

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi

Linux : Greg Kroah-Hartman refuse les excuses via lettre ouverte des chercheurs impliqués dans le scandale des « commits hypocrites » ou d'introduction secrète de vulnérabilités au noyau

Des chercheurs ont secrètement tenté d'ajouter des vulnérabilités au noyau Linux et ont fini par être bannis

Linus Torvalds annonce la disponibilité de la version 5.12 du kernel Linux, elle apporte la prise en charge de l'hyperviseur ACRN et améliore l'écriture NFS Eager

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux et aurait qualifié le C++ de « langage de m... », après le message de Google

[chrtophe]

C'est très borderline et limite illégal du moins du point de vue du droit français. Que l'intension soit bonne ou mauvaise ne change pas l'illégitimité de l'acte. Ils se sont fait gauler sur au moins certains correctifs douteux, il est donc logique que tous leurs correctifs soient considérés comme douteux.

[Kannagi]

L'approche est correcte. Mais cela fait perdre du temps au mainteneurs du noyaux donc...Mais comment faire autrement si le but recherché est de vérifier que les mainteneurs travaillent bien ?

Cela montre au moins qu'on ne rajoute pas des bugs facilement dans le noyau.

Cela porte un nom c'est l’éthique , faire des expériences sur les "vrai gens" c'est un peu hors limite.
Il aurait pu tout simplement travailler sur des données actuels (du code refusé sur Linux , doit y'en avoir beaucoup).
Il aurait pu même faire une enquête sur les codes mauvais et voir combien de temps ils ont été refusé/modifié etc etc

Bref leur méthode et leur approche est très discutable pour ma part.

[Bruno]

Linux 5.13 apportera les correctifs des bogues créés par l'université du Minnesota,
il aura fallu plus de 80 développeurs pour examiner et corriger les « commits hypocrites »

Le responsable de Linux Greg Kroah-Hartman a envoyé une demande de modification de la version 5.13 du noyau Linux pour faire face au chagrin causé par les chercheurs de l'université du Minnesota. Il y a un mois, l'Université s'est vu interdire de contribuer au noyau Linux lorsqu'il a été révélé que les chercheurs de l'université essayaient de soumettre intentionnellement des bogues dans le noyau via des correctifs en tant que « commits hypocrites » dans le cadre d'un document de recherche douteux. Les développeurs du noyau Linux ont finalement terminé la révision de tous les correctifs de l'université du Minnesota afin de résoudre les fusions problématiques dans le noyau et de nettoyer ou corriger les correctifs qui font problème.

Avec plus de 28 millions de lignes de code, le noyau Linux est l'un des plus grands projets logiciels de l'histoire moderne. Des contributeurs du monde entier et de différents domaines soumettent chaque jour un grand nombre de correctifs aux responsables du noyau Linux, afin qu'ils soient examinés avant d'être officiellement fusionnés avec l'arborescence officielle du noyau Linux. Cependant, pour des besoins d’expérimentation, des chercheurs de l'Université américaine du Minnesota ont choisi de soumettre des correctifs contenant furtivement des vulnérabilités de sécurité au noyau Linux et ils ont été pris la main dans le sac par les responsables du noyau Linux.

Ces derniers rédigeaient un document de recherche sur la possibilité de soumettre des correctifs à des projets open source contenant des vulnérabilités de sécurité cachées afin de mesurer scientifiquement la probabilité que ces correctifs soient acceptés et fusionnés. Ils ont utilisé le noyau Linux comme l'une de leurs principales expériences, en raison de sa réputation bien connue et de son adaptation dans le monde entier. Quelques jours après qu’ils aient été pris par les responsables du noyau Linux et ont été publiquement humiliés, l’université sous le coup d’un bannissement s’est excusée.

« Notre objectif était d'identifier les problèmes liés au processus d'application des correctifs et les moyens de les résoudre et nous sommes désolés que la méthode utilisée dans l'article sur les "commits hypocrites" ait été inappropriée. Comme de nombreux observateurs nous l'ont fait remarquer, nous avons commis une erreur en ne trouvant pas le moyen de consulter la communauté et d'obtenir sa permission avant de réaliser cette étude ; nous l'avons fait parce que nous savions que nous ne pouvions pas demander la permission aux mainteneurs de Linux, sinon ils seraient à l'affût des correctifs soumis dans le cadre de notre étude. Bien que notre objectif était d'améliorer la sécurité de Linux, nous comprenons maintenant qu'il était blessant pour la communauté d'en faire un sujet de recherche et de gaspiller ses efforts en examinant ces correctifs à son insu et sans sa permission », avait indiqué l’Université dans une lettre d’excuse rendue publique.

« Nous voulons simplement que vous sachiez que nous ne ferions jamais de mal de façon intentionnelle à la communauté du noyau Linux et que nous n'introduisons jamais de failles de sécurité. Notre travail a été mené avec les meilleures intentions du monde et consiste à trouver et à corriger les failles de sécurité... Nous sommes une équipe de recherche dont les membres consacrent leur carrière à l'amélioration du noyau Linux. Nous nous efforçons de trouver et de corriger les vulnérabilités de Linux depuis cinq ans... Bien que cette situation ait été douloureuse pour nous aussi et que nous soyons sincèrement désolés pour le travail supplémentaire que la communauté du noyau Linux a entrepris, nous avons tiré de cet incident des leçons importantes sur la recherche avec la communauté open source. Nous pouvons faire mieux et nous le ferons et nous pensons que nous avons beaucoup à apporter à l'avenir et nous travaillerons dur pour regagner votre confiance », avait-elle ajouté.

La réponse du responsable du noyau Linux n’était pas moins explicite que la lettre d’excuse. « Merci pour votre réponse. Comme vous le savez, la Fondation Linux et le conseil consultatif technique de la Fondation Linux ont soumis une lettre vendredi à votre université décrivant les actions spécifiques qui doivent être entreprises pour que votre groupe, et votre université, puissent travailler à regagner la confiance de la communauté du noyau Linux. Jusqu'à ce que ces actions soient entreprises, nous n'avons plus rien à discuter sur ce sujet. Merci », avait-il répondu.

Quelques jours après le refus des excuses des chercheurs impliqués dans le scandale des « commits hypocrites » qui a éclaboussé la communauté Linux, la Fondation Linux aurait adressé un certain nombre de demandes à l'Université du Minnesota auxquelles elle doit répondre avant que son personnel ne soit autorisé à contribuer à nouveau au noyau. La fondation exige que l'Université du Minnesota lui fournisse « toutes les informations nécessaires pour identifier toutes les propositions de code vulnérable connu de toute son expérience ».

« Veuillez fournir au public, de manière accélérée, toutes les informations nécessaires pour identifier toutes les propositions de code connu pour être vulnérable de toute expérience de l'Université du Minnesota. Les informations doivent inclure le nom de chaque logiciel ciblé, les informations de commit, le nom supposé de l'auteur, l'adresse e-mail, la date et l'heure, le sujet et/ou le code, afin que tous les développeurs de logiciels puissent rapidement identifier ces propositions et éventuellement prendre des mesures correctives pour ces expériences », exige la lettre signée par Mike Dolan, vice-président senior et directeur général des projets de la Fondation Linux.

Cette nouvelle collaboration semble avoir porté des fruits positifs. En effet, les développeurs du noyau Linux auraient finalement terminé la révision de tous les correctifs de l'Université du Minnesota afin de résoudre les fusions problématiques dans le noyau et de nettoyer ou corriger leurs correctifs qui faisaient problème. Envoyé jeudi par Greg Kroah-Hartman, il s'agissait de correctifs char/misc pour la version 5.13-rc3 du noyau Linux. Alors que les corrections char/misc à ce stade intermédiaire du cycle du noyau ont tendance à ne pas être trop excitantes, cette demande de retrait contient les changements pour traiter les correctifs des chercheurs de l'Université du Minnesota.

Greg a reconnu que : « la majorité de ces modifications sont les retombées du réexamen par l'Université du Minnesota de toutes les soumissions précédentes. Cela a entraîné un grand nombre de retours en arrière ainsi que des modifications, de sorte qu'il n'y a aucune régression des corrections potentielles apportées par ces personnes ». « Je tiens à remercier les plus de 80 développeurs différents qui ont participé à la révision et à la correction de ce problème », a-t-il mentionné.

Cependant, des questions subsistent quant aux processus en coulisses, comme celles posées par Filipo Valsorda, cryptographe et ingénieur logiciel, concernant la prise de décisions de confiance sur la base des domaines de messagerie. Un mois plus tard, son point de vue reste valable : « C'est peut-être une opinion impopulaire, mais je pense que "ne fusionner les choses qu'après avoir vérifié qu'elles sont valides" devrait peut-être être la politique par défaut du logiciel le plus utilisé au monde », a-t-il indiqué sur son compte tweeter.

Source : Liste de diffusion

Et vous ?

Que pensez-vous de cette avancée sur le sujet ?

Voir aussi :

Des chercheurs ont secrètement tenté d'ajouter des vulnérabilités au noyau Linux, et ont fini par être bannis

Linux : Greg Kroah-Hartman refuse les excuses via lettre ouverte des chercheurs impliqués dans le scandale des « commits hypocrites », ou d'introduction secrète de vulnérabilités au noyau

La Fondation Linux veut des détails sur toutes les contributions au noyau Linux faites par l'université du Minnesota, avant qu'elle ne soit autorisée à contribuer à nouveau au noyau

Linus Torvalds annonce la disponibilité de la version 5.12 du kernel Linux, elle apporte la prise en charge de l'hyperviseur ACRN et améliore l'écriture NFS Eager

[JPLAROCHE]

Bonjour avec un peu de bonne volonté on arrive toujours à résoudre les problèmes....

Comme quoi ils ne sont pas bornés Bravo LINUX (tous ses développeur)

[eomer212]

les 'chercheurs' qui ont faits ca , ont juste méprisés au plus haut point les efforts des développeurs et mainteneurs de linux.

ces gens devraient être poursuivis pénalement, pour avoir nuit d'une part à la confiance envers l'université du Minnesota qu'ils ont trompée en utilisant son accréditation à fournir des correctifs au noyau linux,
et aussi nuit à la communauté linux elle même en faisant perdre un temps incalculable aux développeurs.

une sanction exemplaire devrait être prise à l'encontre de ces escrocs.
et pour le moins, les responsables de cette 'étude' , digne de celles qui consistent à étudier comment mieux tuer les baleines en plein moratoire de la chasse à la baleine , devraient être démis de leur poste et aller pointer au chômage!

la preuve que les diplômes universitaires n’empêchent pas d'être de vrais connards au pouvoir de nuisance décuplé.

[shunesburg69]

Ils auront au moins prouvé une chose, on ne peut pas publier des failles aussi facilement que certains essaient de faire croire pour dénigrer les projets libres. On devrait les remercier (mais pas pour autant les ré-autoriser à publier du code).

[Zéolith]

C'est bien de faire amende honorable, mais enfin, comme en Assurance Qualité, ce serait bien que ces chercheurs apporte la preuve que leur démarche n'était qu'un test innocent.

Imaginons que le test ait réussi, c'est-à-dire que les failles n'aient pas été décelées. Quelle aurait été la suite ? Publication ... ou non ? Je fais un pas de plus: la CIA agit en sous-main en fait ou est informée par un chercheur en mal de pouvoir et, suite à ce succès, fait introduire un code qui ouvre une porte, fuite des infos, etc.

Pour moi, c'est grave et je ne crois pas à l'erreur d'appréciation.

[Marc_marc]

- je suis partisan de la sécurité, ce qui implique de tester même si ce test peux-être vu comme une perte de temps pour celui qui l'a subit

- cependant qui a le droit de décider ce qui doit être testé ? pouvez-vous déclencher une alerte incendie d'initiative personnelle pour voir comment votre employeur se débrouille ? pouvez-vous lancer une alerte Ã* la bombe pour voir comment les services concernés y font face ? pouvez-vous faire affecter un bouton d'assistance pour voir combien de temps le service met pour le détecter ?
bien évidement que non. donc on ne déclenche pas non plus de test de sécurité informatique impactant le temps des autres sans leur accord (sauf de rare cas que je trouve légitime tel que ceux ayant mis Ã* jour la passoire sécuritaire d'installation de production électrique par ex, ils n'ont causé aucun dégât, même pas une perte de temps, les gars dans la sécu étaient de toute façon au travail a "attendre l'ennemi")
est-ce que le test du noyau linux pourrait être considéré comme une "cause légitime donnant le droit de s’octroyer le droit de lancer le test-chronophage" ? peut-être. mais c'est sûrement pas une cause légitime de tester plusieurs projet open-source puisque lÃ* le but n'est pas de vérifier si "mes données critiques sont-ellles en sécurité avec le noyeau linux ?" mais "testons de l'opensource"

- quand Ã* la méthodologie, ce n'est pas clair. ils affirment que 60% de leurs failles ont été acceptées et affirment en même temps que c'était un échange via email sans aucun merge ni même aucun commit. alors sur quoi se basent-ils pour dire que c'est accepté ? ils ont papoté et un mainteneur a dit "cela a l'air bien ?"
cela n'est pas l'acceptation d'une faille, donc leur taux a l'air d'être 0% (ou leur explication vaut 0)
a l'inverse le lien theverge dit que 3 patchs problématique ont été accepté. le gars aurait fait involontairement 3 mauvais PR pré-étude ?

- c'est quoi ce PR post-étude ? Greg l'assimile Ã* ceux de l'étude, son auteur ne veux pas s'expliquer.

ce manque de transparence et les incohérences ne plaident évidement pas en sa faveur.
J'ai plutôt l'impression que tout ceci n'est qu'un travail d'étudiant qui mérite 0/10 en éthique