Grsecurity est une série de patchs développés dans l'optique d'améliorer la sécurité du noyau Linux. Ces patchs n'ont, pour diverses raisons, pas été intégrés upstream dans le noyau vanilla et il s'agit donc un patch externe que les personnes intéressés doivent appliquer au code source du noyau avant de le recompiler.
Grsecurity maintient deux séries de patchs : la série stable s'applique à un noyau à support long (comme le 3.2 ou le 3.14). La série test s'applique au dernier noyau upstream mais sa stabilité n'est pas garantie.
Un article vient d'être publié sur le site de Grsecurity qui annonce un gros changement dans ce mode de publication.
Apparemment les développeurs derrière Grsecurity (Brad Spengler et PaXTeam) en ont marre que des entreprises spécialisées dans l'embarqué utilisent leur travail et leur nom de marque de façon déloyale. Certaines entreprises appliquent un patch Grsecurity vieux de plusieurs années et jamais corrigé dans leurs produits. Ils utilisent le nom du projet (sous copyright) dans leurs documents marketing afin de profiter de son aura alors qu'en réalité ils font un boulot dégueulasse qui risque de ternir la réputation de Grsecurity.
Il y aurait aussi des cas (non détaillés) de violation de la GPL par ces firmes qui bossent sur l'embarqué.
Tout ça fait que Brad en a ras la casquette et qu'il a pris la décision de restreindre, à partir de mi-septembre, la disponibilité de la série stable du patch Grsecurity. Ce patch ne sera plus mis à la disposition de tous mais sera restreint aux sponsors officiels du projet. Seule la série instable de test sera ouverte à tous.
On peut regretter cette fermeture du projet qui, si elle respecte la lettre de la GPL, en viole l'esprit.
Comme je l'ai écrit en commentaire de l'annonce sur LWN, cela ne va sans doute rien changer pour les firmes prédatrices qui se baseront simplement sur la série de test.
Il vaudrait bien mieux que Grsecurity s'adosse à une fondation comme SPI ou Conservancy afin d'avoir une assistance légale pour défendre son copyright et son code. Mais sans doute est-ce incompatible avec l'esprit d'indépendance absolue qui caractérise les devs de Grsecurity.
C'est dommage.
# Un prétexte uniquement ?
Posté par Renault (site web personnel) . Évalué à 7.
Personnellement, après des années de suivi du dit projet, j'ai la vague impression que tout ceci n'est qu'un prétexte.
Pourquoi ? Je ne suis pas convaincu que l'image de GRSecurity soit si importante que ça pour qu'elle serve d'argument commercial, ou qu'elle soit considérablement ternie par ce types de pratiques. De plus, ce n'est pas ce genre de comportement qui va améliorer l'image et promouvoir leur code. :)
Linux peut souffrir bien plus par exemple d'un noyau mal utilisé (avec des patchs à l'arrache, un très vieux noyau utilisé encore aujourd'hui, etc.). Pourtant Linus Torvalds n'a rien remis en question sur ce point. C'est le risque du libre d'avoir ce type de comportements, mais c'est aussi ce qui lui permet de se répandre partout à moindre coût.
Et tu ne contre pas une violation de GPL par une fermeture du code. Ça n'a pas vraiment de sens.
Vu les loustiques derrière ces projets (qui ne sont pas à leurs premières polémiques), je pense qu'il a trouvé une excuse pour s'enfermer un peu plus et essayer de gagner plus de sous à partir de leur produit. Je n'ai rien contre le fait qu'ils souhaitent plus d'argents via ce travail, mais autant l'annoncer clairement et ne pas mentir.
[^] # Re: Un prétexte uniquement ?
Posté par patrick_g (site web personnel) . Évalué à 5.
J'ai un peu le même sentiment que toi.
Brad et PaXteam ont toujours eu un comportement "assez particulier" (surtout Brad) vis à vis des idéaux du libre. Leur qualité technique n'est pas en cause mais il semble impossible de travailler en bonne intelligence avec eux.
Cette décision de restreindre l'accès au patch stable risque de marginaliser encore plus le projet. Je leur souhaite au moins que cela entraine l'arrivée de nouveaux sponsors.
[^] # Re: Un prétexte uniquement ?
Posté par Misc (site web personnel) . Évalué à 6.
Si la qualité technique n'est pas remise en cause, pourquoi c'est pas upstream ? ( sauf à dire que le kernel n'est pas une meritocracie comme on le dit si souvent, et qu'au final, l'humain joue )
[^] # Re: Un prétexte uniquement ?
Posté par claudex . Évalué à 5.
Si je me souviens bien, une partie des patchs ralentissent trop les performances pour êtres intégrés upstream, une autre partie complexifierait trop le code. Certains devrait aussi être réécrits pour mieux s'intégrer avec le code vanilla mais cela demanderait des efforts des deux côtés que personne n'a envie de fournir. Je crois que certains patchs cassent aussi la compatibilité.
Après, il est possible que tout puisse être intégré mais ça nécessiterait beaucoup de réécriture, des ajouts d'option de compilation et des ajouts dans /proc,/sys. Comme personne n'est motivé.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Un prétexte uniquement ?
Posté par Anonyme . Évalué à 5.
J’avais aussi entendu parlé du fait que les dev de GRSec poussaient un énorme patch, difficile à relire et à intégrer plutôt que des petits patchs.
[^] # Re: Un prétexte uniquement ?
Posté par Misc (site web personnel) . Évalué à 2.
Donc est ce qu'on peut dire qu'un patch difficile à relire est un patch de qualité correct ?
Si on le refuse pour ça, la réponse est "non".
[^] # Re: Un prétexte uniquement ?
Posté par Anonyme . Évalué à 4.
Le code peut-être de bonne qualité mais le patch qui l'ajoute/le modifie, non.
C'est comme une loi. Si elle est écrite de tel manière qu'elle va modifier 50 paragraphes dans 5 codes différent, elle est de mauvaise qualité alors que les modifications, elles, peuvent être de bonne qualité juridique.
[^] # Re: Un prétexte uniquement ?
Posté par patrick_g (site web personnel) . Évalué à 1.
Cf plus bas ma réponse.
[^] # Re: Un prétexte uniquement ?
Posté par Zenitram (site web personnel) . Évalué à 5.
En plus d'autres problèmes décrits par patrick_g plus bas, mettre upstream enlève plusieurs choses :
- Pas de visibilité de ton nom
- Pas de possibilité de changer de modèle de diffusion comme c'est fait aujourd'hui
On aime ou pas, mais parfois c'est difficile de trouver un business model qui tienne sur la durée en contribuant upstream et donc on ne contribue pas upstream pour pouvoir se démarquer (c'est vrai pour tous les projets).
Après, on peut se demander pourquoi personne d'autre pour le faire (à part quelques travaux ponctuel) en adaptant aux contraintes des mainteneurs du noyau.
[^] # Re: Un prétexte uniquement ?
Posté par bubar🦥 (Mastodon) . Évalué à 3. Dernière modification le 27 août 2015 à 14:27.
Parcequ'il n'y a aucune volonté que cela le soit ?
Il n'y a pas exclusion mutuelle entre ces affirmations (me semble t il)
Ce n'est pas "l'humain" côté noyau (qui entrainerait effectivement à dire que ce n'est pas une méritocracie) mais uniquement l'humain côté grsec. Ils font le choix de ne pas faire le travail d'intégration en amont.
Au final, oui, sans entrainer de conséquence pour la méritocratie (même teintée d'apport de connaissances personnelles, où il serait plus facile d'avoir une acceptation de bon patch si on est déjà tamponné red hat ou fujitsu, que lorsqu'on est inconnu). L'humain joue pleinement ici, mais chez Grsec initialement au moins.
Non ?
[^] # Re: Un prétexte uniquement ?
Posté par Misc (site web personnel) . Évalué à 4.
je connais plein de gens qui le voudrais, donc la volonté est la.
Et pourtant si.
Si les décisions sont prises pour des raisons purement techniques, alors une raison non technique prouve que les décisions ne sont pas prises que sur la technique, et donc que les affirmations "on prends en compte que la technique" est visiblement fausse. De la à dire que ce patch est juste un exemple parmi tant d'autres, il y a un pas que je n'hésite pas à franchir.
C'est pas dur de trouver des gens qui vont dire que Brad Spengler a l'air d'avoir une certaine colère dans ses écrits et visiblement n'attire pas grand monde pour bosser avec lui ou faire des efforts.
Même si des gens dans la communauté du libre rationalise ce comportement comme une qualité (sans doute parce que ne pas pointer les soucis des gens permet de justifier notre propre comportement vis à vis des autres), ça reste dans son cas un comportement antisocial. Et sauf à me trouver assez de gens qui vont me dire clairement et sérieusement "moi, j'aimerais bosser avec lui", je pense qu'il y a personne (à tort ou à raison) voulant le faire.
Donc ouais, je persiste à dire que "meritocratie mes fesses".
[^] # Re: Un prétexte uniquement ?
Posté par Zenitram (site web personnel) . Évalué à 1.
Voudrait comment?
Parce que bon, je connais plein de gens qui veulent virer systemd l'horrible truc, mais quand il s'agit de se bouger, il n'y a plus personne…
Dire qu'on veut, ce n'est pas vouloir.
Du coup, je me demande toujours si il y a une réelle volonté d'avoir ce code, je me demande toujours pourquoi pas foule ne bosse dessus si il y a "plein de gens qui le voudrais".
[^] # Re: Un prétexte uniquement ?
Posté par Guillaume Rossignol . Évalué à 5.
C'est très discutable. Il n'est pas évident que le mérite ne se mesure que sur le résultat final :
Demain je propose un patch qui multiple la performance d'une appli par deux en sabrant la moitié des lignes de codes. Ça fait longtemps que j'y bosse, donc j'avais fait plein de petites modifs, mais je propose le patch d'un bloc. A coté de ça, comme j'ai mon caractére, je refuse d'expliquer mes modifs et laisse tout ça en laissant les autres se dépatouiller de la relecture, de la vérification que ca ne casse pas un truc un peu à la marge et si un jour un bug apparait et qu'on se rend compte qu'il est arrivé avec mon commit, ca va etre drole pour dépatouiller le bouzin.
Dans un univers parralelle, j'ai proposé 50 petits patch qui ne multiple que la performance de 30% (les chiffres sont un peu au pif). Tout est documenté et expliqué, je répond au question sur les points technique peu clair. Globalement, parce que dans cet univers je suis un type sympa, j'ai tout fait pour favoriser le travail en équipe, du coup, l'amélioration est moi bonne à l'instant t, mais au moins, on peut utiliser mon boulot.
Dans lequel de ces deux univers je suis le plus «méritant». Si on mesure le mérite à l'utilité pour un projet donné, clairement, la deuxieme situation est meilleure, mais elle fait bien intervenir l'humain.
[^] # Re: Un prétexte uniquement ?
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 27 août 2015 à 10:01.
Ca n'a surtout pas de sens de parler de fermeture du code : le code est toujours sous GPL, toujours aussi ouvert.
libre != gratuit.
C'est un concours d'erreurs sur ce qu'est le libre, la?
PS : je ne prononce pas sur bien/mal de la restriction de diffusion, c'est un sujet complètement différent par rapport à la fermeture du code.
[^] # Re: Un prétexte uniquement ?
Posté par barmic . Évalué à 3.
Oui (qui dit le contraire ?)
Non
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un prétexte uniquement ?
Posté par Renault (site web personnel) . Évalué à 4.
Pardon, c'est ma faute, je voulais dire par une restriction de diffusion. Ce qui revient à un cloisonnement dans les faits du code pour ceux qui ne payent pas.
Là encore, il n'y a rien d'immoral et d'illégal, je dis juste que le prétexte donné est selon moi inventé pour justifier ce changement de stratégie.
[^] # Re: Un prétexte uniquement ?
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 27 août 2015 à 10:12.
Mieux :).
Note que je n'ai pas réagi sur ce point, je te laisse donc imaginer ce que j'en pense ;-).
Ma réaction était surtout sur tout se qu'on peut dire sur ce que serait le libre ou l'ouverture qui lui est associée, et vu la phrase moralisatrice dans le journal sur le sujet, ça me titille et je pensais donc, à tort donc, que le mot était volontairement utilisé.
Le pauvre libre souffre parfois qu'on veuille autant le limiter, le libre est bien plus tolérant que ça.
# Quel esprit?
Posté par Zenitram (site web personnel) . Évalué à 2.
De quel esprit parles-tu?
Le libre n'a rien à voir avec la diffusion à tous.
http://www.gnu.org/philosophy/free-sw.fr.html
"« Logiciel libre » [free software] désigne des logiciels qui respectent la liberté des utilisateurs."
Le mot important est "utilisateur".
utilisateur != toute la planète.
C'est très explicite, impossible de se tromper si on s’intéresse à la définition de "libre" par la FSF.
Je dirai plutôt que tu violes l'esprit de la GPL (et du libre au passage) en disant que cette modification (je ne parlerai pas de "fermeture") viole l'esprit de la GPL, si esprit il y a.
Ha le libre, chacun parle de "l'esprit" en le mettant à sa sauce, sans regarder la source…
Ceci-dit, ça change du discours plus classique genre que le non commercial serait le vrai esprit du libre (par exemple)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1. Dernière modification le 27 août 2015 à 16:12.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quel esprit?
Posté par Spyhawk . Évalué à 5.
N'importe quoi… Tu peux autant dire que "l'esprit du libre" c'est exprimé par les 10 points definis par l'OSI, ou par le mouvement BSD, ou par ton arrière grand mère.
Parce que moi, je défini "l'esprit du libre" par le mouvement Open Source (partage technique), parce que le "Logiciel Libre" tel que défini par la FSF a plutôt une vocation idéologique que pragmatique. C'est tout autant foireux que n'importe quelle définition de "l'esprit du libre" simplement parce que "l'esprit du libre" n'est pas défini.
[^] # Re: Quel esprit?
Posté par BAud (site web personnel) . Évalué à 5. Dernière modification le 27 août 2015 à 21:56.
si, un peu, tout de même : open source au sens de l'OSI correspond à la définition de la FSF (et leurs licences sont compatibles)
Les BSDistes assument faire du libre, tant que leur source est publié (libre une fois publié), ceux ne souhaitant pas collaborer en bénéficient, mais c'est le jeu (ils le comprendront plus tard et pourront se rattraper pour revenir dans la course, sans se faire taper sur les doigts : efficacité immédiate du fait de la facilité de réutilisation avec peu de contrainte, possibilité de se joindre au mouvement après réflexion ou pas, ce qui est très pragmatique).
Les GPListes préfèrent mettre une barrière à l'entrée : autant que ceux souhaitant en bénéficier aient déjà envie d'en assumer le fonctionnement (fournir les sources, ce qui va de soi dans le libre) au prix d'incompatibilités temporaires (la GPLv3 améliore les choses, ne limitant que les nuisibles… la CeCILL ayant montré qu'il est facile de décliner la GPL selon les droits locaux).
Pour prendre un parallèle, c'est un peu comme dans l'admin :
Le permissif et le prudent correspondent à la BSD et la GPL (libre entrée, montrer patte blanche). C'est une zone similaire, mais avec une approche différente. La licence finalement retenue ne correspond qu'à la lettre, pas à la réflexion ayant mené à ce choix, ni à ce que cela permet (chacun déclinant un fonctionnement lié aux participants). Personnellement, je serais plutôt MIT qui permet de relicencier et simplifie tout, pour autant je reconnais l'intérêt de licences identifiées (j'ai passé un peu trop de temps à les lire, à en discuter avec des juristes et à en comprendre les tenants et aboutissants, ainsi qu'à en comprendre les déclinaisons dans chaque communauté où je me suis impliqué :D).
Il est possible d'aller plus loin, ceux ayant concocté la licence Art Libre dans un domaine hors des logiciels étant sortis des sentiers battus et apporté de nouveaux domaines. Pour approfondir, j'ai quelques notes sur http://faq.tuxfamily.org/CommunicationLibre/Fr et je suis preneur d'ajouts et précisions :-)
[^] # Re: Quel esprit?
Posté par Spyhawk . Évalué à 2.
C'est débatable. Si le Libre (selon la FSF) et l'Open Source (selon l'OSI) donnent plus ou moins les mêmes résultats et ont grosso modo les même licences, la manière de faire et de voir les choses sont différentes. Et dans ma définition personnelle et foireuse de "l'esprit du Libre", cette vision différente compte, parce qu'un mouvement avec sa vision défini l'esprit de ce mouvement.
D'ailleurs, pour moi "l'esprit du Libre" tel que lu sur DLFP c'est plutôt "l'esprit du Libre et de l'Open Source" (et parfois même plutôt "l'esprit de l'Open Source" pour ceux qui arrivent à faire la différence) parce que le Libre tel que définit par la FSF est plus idéologique que pragmatique.
Pour donner un exemple et rester sur mes définitions tout autant foireuses que n'importe quelles autres, "l'esprit du Libre" est en guerre contre le propriétaire, tandis que "l'esprit de l'Open Source" ne cherche qu'à s'améliorer lui même.
[^] # Re: Quel esprit?
Posté par Zenitram (site web personnel) . Évalué à 2.
Oui. Mais aucun des deux ne s’intéresse à la planète entière, car le seul qui compte est l'utilisateur.
Ben justement, je trouve qu'il sur DLFP il y a pas mal de monde avec de l'idéologie. Par contre, pas vraiment de l'idéologie sur l'Open Source ou le libre, mais plus "j'invente une idéologie et l'appelle libre". En exemple, on peut voir du libre qui s’intéresse à la planète entière (genre dans le journal et les commentaires ici ;-) ), du libre qui serait un but à atteindre et non un outil (la on est dans la pure idéologie), du libre "pur" qui serait NC, du libre qui s'intéresserait à celui qui fournit (le classique "l'upstream doit recevoir le patch"), du libre qui ne se formaliserai pas du ND, du libre qui considère les licences BSD comme non libres, et j'en passe. (tous les exemples sont issues de mes lectures DLFP, si si).
[^] # Re: Quel esprit?
Posté par BAud (site web personnel) . Évalué à 1.
oui
non, les nouveaux arrivants peut-être, que tu harangues sans vergogne, quitte à les faire partir… Je ne te jette pas la pierre, tu es souvent factuel au début, sur les CC-by et CC-by-sa tu as un discours clair, sur la GPL moins, une compréhension (ou une empathie) pour l'errance du -NC en dessous de zéro (ainsi que le -ND mais cela va sans dire).
non. Tu confonds finalité et moyens : oui, le libre est potentiellement une finalité, accessoirement une manière de travailler et d'apprendre, il y a des outils comme les licences mais sans compréhension de la démarche y arrivant, tu passes à côté de l'implication de chacun (ton manque d'empathie ? la lettre plutôt que l'esprit ? le doigt plutôt que le message ?)
je te laisse à tes délires. Tu omets souvent le niveau de compréhension de ton interlocuteur (de débutant à long contributeur), son intelligence et son apport au mouvement, même s'il faut parfois le rediriger efficacement vers ce qui va lui servir pour se mettre le pied à l'étrier ou trouver une vraie réponse à son problème ponctuel.
Tu as fais un truc exemplaire avec les DRM, ton comportement et ton implication à dériver me sidèrent systématiquement. C'est le propre du libre je me dis : la diversité :-) Je pense néanmoins que tu ne sais pas tourner 7 fois ton clavier avant de cliquer sur
prévisualiserpuis surposter le commentaire:p[^] # Re: Quel esprit?
Posté par BAud (site web personnel) . Évalué à 3.
oui, j'en suis convaincu, même MIT permet des les obtenir « si tout se passe bien », c'est une question d'état d'esprit et de compréhension du contexte et de volonté de s'insérer dans l'écosystème.
non, la FSF a un sous-ensemble : l'OSI engloble plus large là où la FSF propose de la compatibilité (une notion juridique, un peu chiante àmha mais intéressante par les réactions que cela suscite).
en surface, in fine, pour ceux souhaitant s'impliquer, il n'y a aucune différence : c'est avec ceux ne souhaitant pas participer que le traitement est différent, permissif (on assume faire du libre de bout en bout, parfois pas), prudent (nous préférons que vous fassiez du libre dès le début et jusqu'au bout).
le volet idéologique est important : parce qu'il dérange, parce qu'il oblige à se positionner, parce qu'il oblige à assumer via ses licences, cela met un frein (inefficace dans de nombreux cas, je puis en convenir, pas forcément dans la durée).
euh, non, le libre ne cherche qu'à développer le libre, la disparition du propriétaire ne sera qu'un effet de bord. Le propriétaire a accès à son code source, il peut travailler de la même manière que dans le libre (et il a les mêmes soucis que le libre avec ses partenaires bossant en proprio : la rétro-ingénierie n'est pas la panacée du libre, dans le proprio tu en fais aussi vis-à-vis de tes « partenaires »). Le choix de BSD ou GPL n'est qu'une question de confiance ou de compréhension, pour moi c'est une simplification des échanges et un travail d'égal à égal (j'ai déjà envoyé des bugs et des patchs sur du proprio… à eux de le traduire dans leur source que je n'avais pas puis me le relivrer… faire 2 fois le boulot, c'est moins efficace, tout le monde peut le comprendre).
là, pour le coup, je ne puis qu'être en désaccord : open source ayant été repris à toutes les sauces, dont celle du MS shared source empêchant la redistribution, c'est complètement contre-productif (heureusement, MS évolue même s'il ne contribue pas largement au libre, il y a quelques agents infiltrés, leur codeplex est une réussite par exemple, mono-plateforme, mais une très belle avancée).
open source au sens de l'OSI est très efficace àmha sur tout ce qui est protocole (réseau, WS…), pour FreeBSD repompé éhontément par Apple, je reste mitigé. Autant faire du MIT pour travailler bénévolement, sans reconnaissance ni rétribution : sur un malentendu, cela sera cité et attribué (vu chez Samsung dans leur section Licence et Copyright).
[^] # Re: Quel esprit?
Posté par Spyhawk . Évalué à 2.
J'aurais sans doute du utiliser les mots "approuvent grosso modo les même licences", puisque certaines licences sont approuvées par l'OSI mais pas la FSF, et vice versa. Je ne faisais pas référence aux licences créées par la FSF elle même.
Bien évidemment que l'on puisse être en désaccord avec mes définitions foireuses. Si le "Logiciel Libre" est défini par les 4 libertés fondamentales de RMS, "l'esprit du Libre", lui, n'est pas défini ' et toute définition sera foireuse.
Si le monde du Libre et de l'Open Source n'est pas foutu de s'entendre sur un terme commun (d'où l'utilisation de "Libre et Open Source", justement..) on est pas prêt de définir son esprit.
[^] # Re: Quel esprit?
Posté par BAud (site web personnel) . Évalué à 3.
euh, les deux sont libres et tous ceux qui y participent sont d'accord àmha :-) (OSI + FSF)
ce que j'indiquais, c'est que ceux qui n'y participent pas y voient des différences.
Si le libre était plus efficace, il s'attaquerait au proprio :-) vu qu'il y a les mêmes possibilités des deux côtés (le libre bosse en libre, galère avec le proprio ; le proprio bosse sur le source, galère avec le proprio des autres), c'est le même monde que tu essaies de réconcilier, alors que chacun n'a pas de souci avec cela : ça fait partie du paysage. Si tout le paysage était libre, il n'y aurait plus de souci (mais cela n'est pas le cas).
tu as été perverti par Zenitram< qui veut te faire croire que seule la licence compte :-) Tu oublies les intervenants. Par exemple, Alfresco a toujours été une alternative libre à Documentum, pas de freemium, une meilleure conception, une meilleure utilisation à l'installation (Documentum sans consultant, bin t'en fait rien, même pas une gestion documentaire, ce qui serait censé être sa fonction première).
Tant côté BSD (le code publié reste libre) que GPL (le binaire publié doit rendre son code source disponible à qui le demande), il y a une volonté des participants de travailler en collaboration, permettant à tout le monde de s'impliquer. À chacun de voir la différence àmha :-)
En conclusion : « logiciel libre » et « logiciel open source au sens de l'OSI » sont synonymes, tu demandes quoi de plus ?
[^] # Re: Quel esprit?
Posté par Spyhawk . Évalué à 1.
Tu parles de résultats, je parle de vision et ça, je l'inclus dans le terme "esprit".
[^] # Re: Quel esprit?
Posté par Zenitram (site web personnel) . Évalué à 1.
Oui, tous ces intervenants qui font bien attention à ne pas mettre sur papier leur "esprit du libre".
Pourquoi ils ne le font pas? Car pour 1 million de libristes, il y a 1 million d' "esprit du libre".
Tu peux le voir dans ce journal même (et ses commentaires), où le libre s’intéresse à l'utilisateur mais des intervenant s’intéressent à la "communauté". Si le libre s’intéressait à la communauté, pourquoi ne pas l'avoir écrit dans les 4 libertés? bizarre bizarre…
Ce n'est pas de la perversion, juste du factuel : ne pas écrire est toujours la solution quand on ne veut pas afficher ses désaccords. Tu veux croire qu'il y "plus que les 4 libertés dans le libre", je ne peux te convaincre, mais ça n'en fait pas que tous ceux qui se disent libristes partagent ton "esprit du libre" (surtout vu tous les libristes que j'ai pu croiser qui ont le commercial en horreur, ça fait juste sourire de les croiser quand on a les 4 libertés en tête…)
Le NASA Open Source Agreement est Open Source au sens de l'OSI mais n'est pas libre au sens FSF et Debian.
Ces deux mots sont synonymes que dans certains cas :
- Qu'on ne parle pas d'une licence précise qui fait exception
- Qu'on ne parle pas d'idéaux (et ici, dans cette discussion, on est quand même pas mal dedans!)
[^] # Re: Quel esprit?
Posté par barmic . Évalué à 4.
S'ils l'écrive sur internet ça compte ?
Source : Définition du logiciel libre selon Debian
Tu vois l'incompatibilité entre :
et
Dans les faits aujourd'hui si la version de test de Grsecurity reste libre, sa version stable n'est plus libre selon la définition de Debian.
Donc Grsecurity passe d'une logique libre telle que comprise par le plus grand nombre à elle n'y correspond plus que pour 2 des 3 définitions clairement établie que je connais.
Ce n'est pas là une forme de fermeture ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Quel esprit?
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 28 août 2015 à 15:34.
Mais quel FUD…
Montre-moi l'endroit où ils disent qu'ils ne diffusent plus en GPL.
Si c'est GPL, c'est toujours libre, que ça te plaise ou pas.
Il n'y a aucune incompatibilité, que ça te plaise ou pas. Debian n'aura peut-être pas accès, mais ça ne change rien au sujet du libre de la version stable. Parce que le libre se fout que Debian ai accès au code si il n'est pas utilisateur (ici, donc sponsor).
Faux.
tu n'as toujours pas compris que le libre s’intéresse à celui qui reçoit, et non pas à la planète entière.
"comprise par le plus grand nombre"? tu en es sûr? Et ce n'est pas parce que le plus grand monde fantasme sur un truc que c'est vrai. Si le plus grand nombre pense que le ND est libre, tu diras que le libre est donc compatible avec ND? Hum…
Saloperie de libre, hein, qui permet bien plus de choses que ce que veulent des gens qui voudraient le limiter, et en sont à trahir les définitions, à les tordre, pour que ça leur convienne. Pile ce que je décrivais sur ceux qui se font une idée bien fausse et pas compatible avec les voisins du libre.
Maintenant, du NC et ND est libre, car des gens l'ont écrit sur Internet.
[^] # Re: Quel esprit?
Posté par barmic . Évalué à 2.
Je te pointe le journal qui dis que les sources sont disponibles si tu paie et le contrat social debian qui indique que la gratuité de l'accès aux sources est la première règle d'un logiciel libre selon Debian.
Quel libre ? FSF, OSI, Zenitram,… Je t'ai dis au sens de Debian. La DFSG ne parle pas de l'utilisateur. Elle se moque de la GPL ou de ce que tu veux elle se contente d'elle même et peut décider que Firefox pose problème même s'il utilise une licence libre.
Tu fais parti des gens qui pensent que ce qui est écris dans un livre est probablement plus vrai que ce qui est écris sur un écran ?
Là en l'occurrence je n'ai pas dis que Grsecurity n'est pas libre, mais que ça version stable ne semble pas l'être pour Debian. Mais t'inquiète pas je peux aussi écrire que Grsecurity est libre au sens de Zenitram. Tu peut remettre en cause la valeur de la DFSG ou m'expliquer que je la lis mal, bref essaie au moins de trouver un argument.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Quel esprit?
Posté par Lucas . Évalué à 8. Dernière modification le 28 août 2015 à 17:09.
En fait non, le contrat social parle bien de licence d'un composant dans Debian qui ne doit pas réclamer de royalties ou de limitations de redistribution. Rien ne dit dans le contrat social que le composant a atterri gratuitement dans Debian (par exemple si Debian devient sponsor). Juste que la licence (ici GPL comme dit Zenitram et c'est tout ce dont le contrat social parle, de la licence pas de comment Debian se procure le composant) n'empêche pas Debian de le redistribuer, gratuitement, de modifier, etc…
Donc tu interprètes le contrat social de la mauvaise manière ici je pense.
[^] # Re: Quel esprit?
Posté par Zenitram (site web personnel) . Évalué à 1.
Ouf, ça me rassure, il y a au moins une personne qui suit ce qu'est une licence libre (et ce qu'est le contrat social de Debian, qui s’intéresse à ce qu'il reçoit et pas à autre chose non plus).
C'est quand même fou tout ce qu’on peut inventer sur une licence / un contrat / un "esprit" qui ne plait pas dans la description écrite.
Après, il ne faut pas s'étonner que des gens fassent des choses contraire à une religion tout en se disant représentant de cette religion, le libre est une religion, avec ce genre de fidèles ne respectant pas vraiment la source de leur religion, parfois!
[^] # Re: Quel esprit?
Posté par j-c_32 . Évalué à 2.
Oui, comme par exemple étendre les 4 libertés logicielles à des produits non logiciels, alors que le texte auquel tu fais référence ne mentionne NULLE PART le fait que cela est légitime (cela ne veut pas dire que ça ne l'est pas, mais cela ne veut pas dire que ça l'est).
La seule extension qui est faite est:
Étrange formulation, pourquoi parler de finalité pratique si les mêmes arguments s'appliquent à des créations sans finalité pratique ?
bizarre bizarre…
(finalement, il y a aussi un lien d'exemple d'extension des licences libres à d'autres objets, mais il n'est dit NULLE PART que ces cas sont pertinents)
Lorsque quelqu'un dit qu'il est libriste et qu'il trouve que la musique sous licence NC n'est pas incompatible avec le libre, il a autant raison que toi qui dit le contraire, car RIEN de ce que dit cette personne n'est contredit dans le texte que tu cites, tandis que les seules contradictions, ce sont des trucs que "des gens ont écrits sur internet" (à savoir, principalement, toi).
Ces deux personnes tordent les définitions pour que cela leur convienne. C'est ce que tu fais en interprétant les 4 libertés selon ton agenda idéologique.
Je n'ai pas de problème avec ça. Je n'ai aucun problème avec ceux qui considère que la musique sous NC n'est pas compatible avec leur esprit du libre. Mais quand tu critiques certains alors que tu fais exactement pareil (et que tu ne le remarques même pas), c'est juste navrant.
[^] # Re: Quel esprit?
Posté par oinkoink_daotter . Évalué à 5.
Pourquoi éhontément ? Par ailleurs, pour ce qui est repompé des BSD chez Apple qui n'est pas redistribué dans Darwin ?
Pour le coup, je les trouve plutôt clean sur ce truc.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quel esprit?
Posté par Zenitram (site web personnel) . Évalué à -3.
On parle bien de ceux qui ont, entre autre, ont créé les sections invariantes de la GFDL, c'est bien ça?
le rapport?
Il parle de la licence, pas du code.
Ou pas.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quel esprit?
Posté par BAud (site web personnel) . Évalué à 4.
oui, le -ND est non libre. RMS (et la FSF) s'y accroche visiblement pour représenter son opinion. Le projet Debian l'a battu en brèche et tant mieux, c'est inopérationnel et inutilisable quand utilisé (tu te traînes un boulet dans les traductions, notamment… RMS aurait été chinois et le libre en cyrillique, tout le monde en Europe et aux états-unis comprendrait que gérer l'UTF-8 uniquement pour cette section aurait été chiant dans les années 90… on ne va pas refaire l'histoire). L'histoire concernant l'Art Libre ou les brevets en biologie vont au-delà des prérogatives de la FSF et sont tout aussi intéressantes.
un peu, si.
Cela a permis de créer des distributions (à titre d'exemple : Debian GNU/Linux ou Debian/kFreeBSD ou Debian GNU/Hurd, notamment, bien créatif pour le coup et bien impliqué pour faire au mieux, Ubuntu n'étant qu'une opportunité différente pour d'autres personnes, Red Hat étant un autre modèle, assez proche de Slackware plus libre, ArchLinux partant dans tous les sens sans cohérence et Mageia bénéficiant tant de Fedora que de Debian ou Gentoo), de rebondir sur ce qu'est un format ouvert grâce à Adobe et son flash finalement abandonné sous Linux et remplacé au profit de HTML5 que promeut avec succès Mozilla (suivi par d'autres… dont un utilisateur comme youpron^Wyoutube^Wgoogle).
Mozilla, IBM, Red Hat se renouvellent, Oracle périclite malgré ses rachats en masse, le libre fait désormais partie du paysage pour publier : autant promouvoir cela, non ? L'extension à l'open data, à l'open access (pour les publications scientifiques avec crowdsourcing du peer-review), à la liberté d'expression sur Internet (battue en brèche mais pas encore remise en cause), ce n'est qu'un effet de bord qui bénéficie en dehors du cercle de l'informatique, autant promouvoir cela, non ?
[^] # Re: Quel esprit?
Posté par Spyhawk . Évalué à 0.
RMS a formellement défini le "Logiciel Libre", pas l'"esprit du Logiciel Libre". Et le "Libre" selon la FSF est loin d'être une définition universelle de la liberté dans le logiciel, c'est juste un sous ensemble.
Personnellement je n'en ai rien à faire du Logiciel Libre selon la FSF. Le "Logiciel Libre" est avant tout un mouvement social, mais ce que m'intéresse c'est l'open source en tant que méthode de développement. Je n'aurais aucun scrupule à utiliser du logiciel propriétaire s'il était aussi efficace que le logiciel libre et open source.
Je sais qu'il y en a quelque uns comme moi sur LinuxFR, mais on est clairement pas une majorité (et on survit tant bien que mal…)
[^] # Re: Quel esprit?
Posté par BAud (site web personnel) . Évalué à 3. Dernière modification le 28 août 2015 à 00:09.
si tu bosses sur du proprio, tu fais partie de mon monde :
Malencontreusement, j'ai rencontré le libre dès l'école (avec les X Athena Widgets, notamment, un truc qui compilait pour Solaris, HPUX, Linux accessoirement, Xenix parfois et autres ix de l'époque) et j'ai continué à utiliser ce genre de logiciel ensuite, à l'aune de leur prise en compte de *mon environnement. Le libre y répond parfaitement, continue d'y répondre, y apporte d'autres choses (respect des standards notamment), pourquoi ne pas le choisir plutôt que le truc fermé à côté qui ne sait même pas suivre des RFC connues depuis bien longtemps ? (même s'ils s'améliorent).
Bon en vrai, je suis acquis au libre dès que j'ai eu mon Apple IIe en 1984 et ai pu hacker son bios via PEEK et POKE :D
[^] # Standards?
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 28 août 2015 à 08:57.
Le libre n'a RIEN à voir avec les standards.
Tu peux faire du libre qui dit merde aux standards, et du non libre qui respecte les standards.
Bon exemple de mélange que les gens peuvent faire sur le libre.
Note : j'espère que tu ne mélange pas "personne d'autre n’implémente, tu peux lire le code donc c'est standard" avec "plusieurs implémentations, une spec, une validation par unorganisme)
Mélanger libre et standard est un bon moyen d'opposer les gens (par réaction de ceux qui sont injustement exclus) plutôt que de les amener à vivre ensemble.
[^] # Re: Quel esprit?
Posté par j-c_32 . Évalué à 2.
La situation actuelle est un résultat compréhensible.
Un type arrive avec un projet, qu'il décrit en long et en large, et il lui donne un nom.
Ensuite, certains identifient dans la pratique de ce projet des éléments qu'ils aiment, et en déduisent que ce projet a les mêmes objectifs que ceux qu'ils ont eux-mêmes.
Le premier type ensuite passe son temps à expliquer que son projet initial n'a rien à voir, et que les autres se sont plantés de bannière (vu qu'il existait à l'époque de l'open-source en parallèle du libre, pourquoi avoir choisit de s'associer avec le mot "libre" ?).
Mais c'est juste trop tard, la communauté du libre contient plein de gens d'idéologies différentes, et je n'ai personnellement pas de problème avec ça.
C'est sans doute le résultat du fait que la culture politique prend du temps à s'apprendre, et que sans ça, on n'arrive pas à comprendre que son opinion personnelle n'est pas forcément évidente pour tout le monde (ça explique selon moi pourquoi, par exemple, les "open-sourciens" ou autres se sont ralliés derrière le mot "libre", parce qu'ils n'ont pas cherché à voir si le mouvement auquel ils se ralliaient était bel et bien celui qu'ils avaient en tête, pour eux, que ça ne soit pas le cas était inconcevable).
Il y a encore des indices de cette absence de culture politique aujourd'hui. Par exemple, le fait de faire une distinction entre pragmatisme et idéologie. Se revendiquer du pragmatisme, c'est en soi déjà une idéologie. On voit même très souvent des gens ayant des solutions opposées qui revendiquent tout les deux être pragmatiques, simplement parce qu'ils ont des objectifs différents ou une échelle de valeur différente ("que le logiciel plante de temps en temps, on s'en fout, on le redémarre et c'est bon, ce qui compte, c'est qu'il soit produit rapidement et diffusé grandement", "que le logiciel arrive plus tard, peu importe, du moment qu'il soit parfait et ne plante pas"). Le pragmatisme n'est pas opposé à l'idéologie, c'est juste une méthode qu'on applique au dessus de son idéologie.
[^] # Re: Quel esprit?
Posté par BAud (site web personnel) . Évalué à 0.
euh, tu mélanges idéologie et politique, open-source et libre.
tu ajoutes pragmatisme et culture, en citant échelle et méthode !?
Tu en as trop dit ou pas assez, quel logiciel t'a traumatisé ?! Franchement, même pour un breton comme moi, tu es à l'ouest :-)
[^] # Re: Quel esprit?
Posté par Tonton Th (Mastodon) . Évalué à 3.
Yaka fouiller : https://rms.sexy/ :)
# Inclusion
Posté par barmic . Évalué à 6.
Je ne retrouve pas le journal en question, mais il y a bien longtemps tu nous avais parlé d'un étudiant qui se mettait à découper les patch grsecurity pour les inclure dans linux. Qu'est-ce que c'est devenu ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Inclusion
Posté par patrick_g (site web personnel) . Évalué à 10. Dernière modification le 27 août 2015 à 10:54.
C'était ce journal : https://linuxfr.org/users/patrick_g/journaux/renforcer-la-s%C3%A9curit%C3%A9-du-noyau
Je crois que Vasiliy Kulikov a réussi à faire passer en upstream quelques trucs non invasifs mais qu'ensuite ça c'est arrêté là.
Je sais que Dan Rosenberg a également bossé sur la remontée upstream de certains parties du code de grsecurity.
Mais le problème c'est qu'il est très difficile d'upstreamer le patch complet pour les raisons suivants :
[^] # Re: Inclusion
Posté par claudex . Évalué à 6.
Du coup, comment bossent-ils ensembles ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Inclusion
Posté par Antoine . Évalué à 8.
De façon pas sereine.
[^] # Re: Inclusion
Posté par barmic . Évalué à 7.
L'impression que j'ai c'est plutôt : "la sécurité est le seul paramétre" vs "la performance est le seul paramétre" :-)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Inclusion
Posté par claudex . Évalué à 7.
Non, un paramètre important dans le dev du noyau est de ne pas casser la compatibilité externe.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Inclusion
Posté par debrouxl . Évalué à 5.
Mathias Krause (minipli) rentre aussi quelques patches de temps en temps.
Des centaines de hunks de PaX/grsecurity sont de purs cleanups, certains n'améliorant même pas explicitement la sécurité, et ne font l'objet d'aucune controverse pour les pousser vers mainline. Un des exemples qui revient le plus souvent est la constification des structures ops. Une très grosse série de patches de constification avait été poussée vers mainline par Emese Revfy (ephox), et peu de développeurs avaient intégré les modifs de constification…
On peut également citer quelques dizaines de structures locales qui prennent de la place sur la pile et du temps d'exécution alors qu'elles pourraient être static (et souvent const), ou a contrario, quelques variables static pour lesquelles ce static n'a aucun intérêt puisque la première chose que fait la fonction qui les déclare est d'écraser leur valeur.
Nombre de ces hunks sont présents depuis des années, inchangés. L'incitation à les pousser vers upstream est faible, puisque le fait de faire une soumission prend du temps, et comme je l'ai mentionné plus haut, le taux d'intégration de ces patches a déjà été montré comme bas.
Un point de ton post ne me paraît pas techniquement correct: on peut utiliser les frameworks de policy basés sur LSM en plus de grsecurity: https://grsecurity.net/compare.php
A moins que tu veuilles dire par "incompatible avec LSM" que mainline insiste absolument pour que grsecurity passe par les fourches caudines de LSM, alors que spender explique depuis des années ( https://grsecurity.net/lsm.php ) que c'est parfaitement inadapté parce que LSM est très loin d'être assez puissant ? C'est hélas un fait que "c'est pas un LSM" est une des objections qui ont été formulées contre l'inclusion de grsec dans mainline - peu importe le fait que ça réduise énormément la puissance de la solution.
[^] # Re: Inclusion
Posté par patrick_g (site web personnel) . Évalué à 7.
Oui c'est bien ce que je voulais dire. Grsec n'utilise pas l'infrastructure LSM qui est celle du noyau. Qu'on l'aime ou pas c'est le chemin qui a été choisi par la communauté des codeurs du noyau.
Par ailleurs je colle un lien vers un de tes posts LWN qui me semble intéressant pour les lecteurs de ce journal : https://lwn.net/Articles/598525/
Je ne suis pas d'accord avec tout, en particulier je trouve que tu fais la part trop belle aux devs de grsec sans tenir compte de leur caractère conflictuel et de leur dédain de tout ce qui n'est pas lié à la sécurité.
Comme l'a écrit à de nombreuses reprises Jonathan Corbet, tous les devs noyau qui veulent être recrutés y arrivent très facilement. Ce ne sont pas les employeurs qui manquent. Si Spender et PaXTeam voulaient être payés pour bosser sur le noyau et travailler à intégrer petit à petit leur patch ils pourraient le faire. Mais ils ne veulent pas car cela implique de ne plus être le boss et de ne plus décider seul. Cela implique de faire des compromis, de reconnaitre que la sécurité n'est pas le seul paramètre.
Ils ne sont pas prêts à ça.
[^] # Re: Inclusion
Posté par debrouxl . Évalué à 3. Dernière modification le 27 août 2015 à 15:05.
Comme je l'ai signalé dans ce post-là, PaXTeam et spender préfèrent en effet se concentrer sur la réalisation des features utiles pour la minorité d'utilisateurs qui connaissent et croient réellement en leur travail, plutôt que sur l'intégration à mainline, suite à une revue de code par des gens moins compétents en sécurité qu'eux, qui leur imposent de passer du temps à dégrader ce qu'ils ont fait (en imposant des interfaces inadaptées, en refusant les plugins GCC, et j'en passe).
J'ai du mal à leur donner complètement tort, tout comme j'ai du mal à donner complètement tort à leurs trop nombreux détracteurs :)
Il n'y a toujours pas de réponse à la question que je posais dans ce post, et que je ne suis évidemment pas le seul à poser: "What to do to meaningfully improve end user security of Linux ?" (for most users on a day to day basis, je rajoute maintenant pour être plus explicite)
S'il y avait une initiative un peu coordonnée de déplacement des morceaux de cleanup non controversiaux que j'ai listés dans un autre post ici depuis PaX/grsecurity vers mainline, j'essaierais de participer, à mon petit niveau, comme je l'avais fait pour quelques patches de constification en 2011 (suite à une autre discussion LWN où j'avais joué l'andouille), peu avant que la constification soit réécrite avec le plugin GCC.
[^] # Re: Inclusion
Posté par Prae . Évalué à 2.
Pour suivre grsec depuis très longtemps, le plus gros problème - à mon sens - est le fait que Brad Spengler a un rapport avec les développeurs du kernel assez conflictuel. A chaque release, et même depuis les premières, il ne se privait pas pour envoyer des petits tacles ou de se foutre de la gueule de la sécurité du kernel Linux (même encore maintenant, on voit, de temps à autres, apparaître des tweets assez sarcastiques là-dessus). A mon avis, cela n'aide pas. Malheureusement :-\
# Alternatives
Posté par erdnaxeli (site web personnel) . Évalué à 9.
Je suis membre d'une assoce étudiante qui utilise grsec sur un serveur sur lequel chaque étudiant à un shell. Je doute que l'on puisse devenir sponsor de grsec, et utiliser les versions de test me parait pas une très bonne idée.
Du coup, quels sont les alternatives possibles ? SELinux me vient tout de suite à l'esprit mais je n'y ai jamais touché. Y a-t-ils d'autres alternatives ?
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Alternatives
Posté par G.bleu (site web personnel) . Évalué à -2.
Je ne connais pas les fonctionnalités offertes par grsec, du coup je suis curieux de connaître les raisons (et/ou les lacunes du noyaux vanilla) qui t'ont poussées à l'utiliser dans un contexte à première vue non critique (à moins que les étudiants en questions ne soient en info spé sécu…) ?
[^] # Re: Alternatives
Posté par gdelugre . Évalué à 4.
Il faut vraiment expliquer le besoin de sécuriser un serveur sur lequel on donne un shell à tout un tas de gens ?
[^] # Re: Alternatives
Posté par G.bleu (site web personnel) . Évalué à 4.
Non mais expliquer la différence avec un noyau linux standard (qui n'est pas sensé être une passoire de base) serait intéressant.
[^] # Re: Alternatives
Posté par erdnaxeli (site web personnel) . Évalué à 7.
Je ne sais pas pourquoi ce choix à été fait en premier lieu, quand je suis arrivé c'était déjà comme ça. Mais il s'agit d'une école d'informatique donc oui, certains étudiants sont (très) bons et certains prennent la spécialité sécu.
Je ne suis pas expert, mais je vois plusieurs avantages à utiliser grsec. Déjà, on peut régler très finement avec le rbac les droits pour chaque utilisateur et chaque binaire (mais si je ne suis pas totalement à la ramasse c'est aussi le but de SELinux et autres). Mais surtout, depuis 5 ans que je suis entré dans cette école, jamais une seule faille du kernel ne nous a touché, et ça c'est plutôt agréable. Devoir mettre à jour un noyau sur un serveur aussi utilisé ce n'est déjà pas évident et surtout il y aura toujours quelqu'un plus réactif que nous pour essayer d'utiliser l'exploit dès sa sortie.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Alternatives
Posté par debrouxl . Évalué à 8.
Pour grsec, "patch de test" n'est pas un synonyme de "patch particulièrement instable" :)
Sur plusieurs machines depuis plus d'un an, je n'ai jamais utilisé un des patches stables parce qu'ils ciblent des versions trop vieilles du kernel… et je n'ai eu qu'un problème, qui était circonscrit à peu de modèles de serveur Dell, dont celui que j'ai, et a été rapidement corrigé.
Il n'y a aucune alternative à PaX/grsecurity, qui s'occupent (puissamment) d'anti-exploitation du kernel.
Tout ce dont SELinux / AppArmor et autres frameworks de policy s'occupent, c'est de veiller à ce que les applications ne fassent pas autre chose que ce qui est défini dans la politique de sécurité… mais ils ne durcissent en rien le kernel.
La plupart des PoCs pour les exploits significatifs du kernel Linux (privesc, souvent), tels qu'ils sont publiés, sont arrêtés par plusieurs protections de PaX/grsecurity. En général, quand un tel exploit et son PoC sont mentionnés sur LWN, spender liste les protections impliquées, le plus souvent:
* UDEREF (sur-ensemble strict du SMAP des tout derniers processeurs Intel): empêcher le kernel de lire les structures ops directement en userspace;
* KERNEXEC (sur-ensemble du SMEP des derniers processeurs Intel): empêcher le kernel d'exécuter directement le payload en userspace (soupir…), dont l'adresse a été lue à cause de l'absence d'UDEREF sur mainline;
* RANDSTRUCT: réordonner les champs d'un certain nombre de structures du kernel, pour que les exploits binaires précompilés fassent en général un DoS - et il est difficile de recompiler à la volée une version adaptée au kernel, parce que le layout est difficile à déterminer de l'extérieur;
* une quatrième qui m'échappe à l'instant.
En pratique, la plupart des utilisateurs désactivent SELinux parce que c'est juste trop pénible à l'usage: problèmes de compatibilité dus à une politique de sécurité incomplète ou trop restrictive.
L'autre jour, j'ai dû installer CentOS 6 (soupir de devoir se coller des versions obsolètes de ce genre…) dans une VM avec un hyperviseur propriétaire. Out of the box, la VM ne bootait même pas si je ne désactivais pas SELinux - ce n'est pas une blague !
Bref, je ne peux que te conseiller de continuer avec grsec (et donc, le patch de test, comme moi), parce que c'est ça qui fait une sécurité vraiment améliorée, et non les frameworks de policy qui ne protègent pas des exploits du kernel et ne présentent aucune difficulté réelle pour les agences gouvernementales.
[^] # Re: Alternatives
Posté par patrick_g (site web personnel) . Évalué à 4.
HIDESYM ?
[^] # Re: Alternatives
Posté par Renault (site web personnel) . Évalué à 2.
Ou pas.
SELinux est activé par défaut dans Android maintenant, et je n'ai pas entendu les utilisateurs le virer systématiquement.
SELinux était une plaie il y a 5-10 ans, en effet. Aujourd'hui, personnellement en usage client comme serveur : aucun problème au quotidien. Et les rares cas signalés sont soient bénins, soient le programme te dit la commande à faire pour ignorer cette erreur. Donc bon, ça reste assez utilisable.
Pour moi ces histoires de SELinux inutilisable viennent de préjugés dus au passé.
Tu as résumé le problème : CentOS 6… Le monde a évolué depuis, non ?
À t'écouter on pourrait croire que les LSM sont inutiles. C'est bien faux…
[^] # Re: Alternatives
Posté par debrouxl . Évalué à 8.
Pas toutes ces histoires, non. En-dehors de RHEL et dérivées, pas toutes les distros n'utilisent des politiques de sécurité SELinux un peu complètes et à jour… la plupart des distros n'utilisent simplement pas SELinux par défaut, d'ailleurs, ce qui n'aide pas à avoir des politiques convenables.
Moi, je sais bien que le monde a évolué depuis CentOS 6… mais que veux-tu, installer CentOS 6 est ce qu'on m'a demandé de faire, parce qu'on doit utiliser des packages qui sont testés avec CentOS 6 et non CentOS 7 - alors je dois faire avec CentOS 6, même si je peux indiquer qu'il y aurait mieux à faire ;)
A une époque, spender s'était amusé à faire une série d'exploits que SELinux n'empêchait absolument pas. J'ai déjà vu des exploits qui commencent par désactiver SELinux et tous les LSMs, peut-être que ceux de spender que je mentionne en font partie. Ceci reste d'actualité, puisque les capacités des LSMs n'ont pas évolué (parce qu'elles ne peuvent pas évoluer) vers plus de protection efficace du kernel.
Pour empêcher de rooter la machine et nuire aux utilisateurs et données (les exploits les plus dangereux, quoi), les LSMs sont beaucoup moins utiles que grsecurity.
Bien sûr, contre les exploits plus simples (LFI, par exemple), si tu interdis à l'application vulnérable de lire /etc/passwd, ça rend l'exfiltration de données un peu plus difficile, mais ce n'est pas ça qu'il faut faire en premier pour la protection de l'intégrité de la machine, à mon sens. Les sponsors de grsecurity, qui sont pour la plupart des fournisseurs d'hébergement, ne s'y trompent pas: ils commencent par utiliser une base saine, et ensuite, ils peuvent construire par-dessus.
[^] # Re: Alternatives
Posté par Renault (site web personnel) . Évalué à 1.
Ce qui en soit ne prouve rien. Entre autre parce que certains comme Ubuntu ont privilégié un programme équivalent.
Fedora, Red-Hat, CentOS, Scientific Linux + quelques personnes qui l'installent manuellement, ça fait plusieurs millions de machines avec quand même.
Que tu arrêtes de troller en utilisant comme preuve un code ancien.
Je ne nie pas les soucis du passé, ni même des problèmes aujourd'hui, mais tu accuses SELinux d'être inutilisable au quotidien : c'est faux aujourd'hui.
Et ? Parce que SELinux n'est pas infaillible, il est inutile ? Sérieusement ? Arrête un peu.
Car jusqu'à aujourd'hui SELinux ne s'en préoccupe pas.
SELinux s'oriente surtout pour protéger l'espace utilisateur et non le noyau, c'est complémentaire de GRSEC en ce sens.
Cela ne le rend donc pas inutile pour autant.
D'autant que, à t'écouter, on pourrait croire que GRSEC c'est invulnérable… Il faut faire attention avec ce genre d'idées.
[^] # Re: Alternatives
Posté par debrouxl . Évalué à 1.
Ce n'est pas correct de lire dans mes posts des choses que je n'écris pas, aussi bien sur l'inutilité de SELinux que sur l'invulnérabilité de grsec - des choses que je n'écris pas parce qu'il serait faux de les écrire ;)
De plus, toi et moi sommes d'accord sur certains points: j'ai précisément écrit, dans un autre post de ce thread, "on peut utiliser les frameworks de policy basés sur LSM en plus de grsecurity". Même si apparemment, nous ne mettons pas la même priorité sur les élements.
Bref… on arrête longtemps avant que la modération nous signifie qu'on devrait le faire parce qu'on tourne en rond ?
[^] # Re: Alternatives
Posté par oinkoink_daotter . Évalué à 3.
Ca ne marche pas bien sur Debian. Et n'est visiblement pas une priorité.
A tel point que le paquet selinux-policy-default qui est censé contenir la politique de sécu par défaut n'existe pas sur jessie pour cause de bug release critical pas corrigé à temps.
[^] # Re: Alternatives
Posté par Sufflope (site web personnel) . Évalué à -3.
Eh bah disons que c'est inutilisable sous Debian, ce qui n'est pas équivalent à inutilisable.
De toute façon à part les vieux dinos "je gère ma sécu à la main avec /etc/groups et le sticky bit, si tu veux un accès à tel dossier envoie-moi un courriel et je le ferai dans 1 mois, ça c'est du collaborative software" qui utilise Debian ? Si on veut des technos modernes…
[^] # Re: Alternatives
Posté par erdnaxeli (site web personnel) . Évalué à 2.
Merci pour tes conseils. On était un peu inquiet puisque dans l'annonce de grsec il est dit à propos du patch testing : « unfit in our view for production use ».
La partie durcissement du noyau est effectivement vraiment un plus, et passer seulement à un framework de policy serait pour nous une régression. Pour ce qui est des agences gouvernementales, je pense que c'est un peu hors de propos :p
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# J'ai pas très bien compris
Posté par j-c_32 . Évalué à 1.
Imaginons la situation suivante:
L'entreprise sponsor X utilise la version "stable" du code, en tant qu'utilisateur, selon la liberté 2 dans le document de la FSF, j'ai donc le droit de donner ma version stable à n'importe qui.
Or, ce qui est dit dans le journal, c'est qu'il est interdit de donner cette version stable à mon voisin si celui-ci n'est pas sponsor du projet.
J'ai l'impression que le modèle actuel est plutôt:
on produit un code sous GPL (instable) et un code (stable) dont la licence n'est plus GPL si elle respecte cette condition.
Par exemple, dans le cas de RedHat, CentOS fait exactement ça: alors que RedHat vend ses services de maintenance (mais n'impose aucune restriction sur le code et ceux qui peuvent l'utiliser), CentOS reprend le code pour le distribuer de façon simple à ceux qui veulent l'utiliser.
[^] # Re: J'ai pas très bien compris
Posté par Zenitram (site web personnel) . Évalué à 5.
Le journal ne dit pas ça, à ma connaissance.
il dit que le développeur principal ne va filer qu'aux sponsors.
(donc rien sur un interdit de donner cette version stable à son voisin non sponsor)
Du moins, je n'ai pas compris dans l'annonce ("Therefore, two weeks from now, we will cease the public dissemination of the stable series and will make it available to sponsors only.") et le journal qu'ils allaient diffuser sous une autre licence que GPL.
[^] # Re: J'ai pas très bien compris
Posté par patrick_g (site web personnel) . Évalué à 4.
C'est ça. Grsec restreint le patch stable à leurs sponsors mais ensuite ces sponsors font ce qu'ils veulent du code. Ils ont parfaitement le droit de le publier sur un FTP quelconque.
Mais bon ce serait certes conforme à la licence mais sans doute mal perçu par les devs Grsec. En plus ces derniers offrent plus que du code brut à leurs sponsors. Sur le site il y a marqué :
"Sponsors receive personal support, audits of RBAC policies and kernel configurations, the ability to request features tailored to your organization"
[^] # Re: J'ai pas très bien compris
Posté par Zenitram (site web personnel) . Évalué à 2.
Tout à fait.
Comme ce que fait RedHat.
(la, je te concéderai une violation de l'esprit du libre, car tu es libre de diffuser mais on coupe le support dont tu as besoin, na, en pratique tu ne peux pas trop utiliser tes droits du libre tant que tu veux du support)
[^] # Re: J'ai pas très bien compris
Posté par bubar🦥 (Mastodon) . Évalué à 5. Dernière modification le 27 août 2015 à 14:26.
Red Hat ne se contente pas de respecter la licence, ils en respectent aussi l'esprit (ou, disons, l'organisation de développement) : non ?
Dis comme cela (et plus bas aussi) on a l'impression que Red Hat est comparé à un vulgaire constructeur taïwanais de téléphone. Red Hat ne fait pas que publier un gros tarball sur un sous-site obscur de son domaine : L'immense majorité de ses développements en fait directement dans les projets en amont (kernel, gnome, … et même LibreOffice, les citer tous serait trop long :p)
Pour le reste ce sont des projets internes qui n'intéresse personne au presque probablement et dont le développement est complètement fait par eux. Mais mêmes pour ces projets là le développement est public et ouvert (katello par exemple). Au final il doit y avoir pouillème qui reste vraiment interne chez eux. Les chiffres exacts doivent se trouver avec un peu de temps :)
Pour comparer grsec avec red hat, il faudrait que grsec :
Ceci ne l'empêcherai pas de continuer à livrer un "gros patch intrusif" à ses clients, si les deux parties en sont satisfaites. Le patch perdrait certainement un peu de poids, et grsec devrait faire cet effort d'adaptation, mais à côté ils gagneraient en aura sans perdre en exclusivité (le kernel n'avançant jamais assez vite pour eux \o/ dans l'intégration de leur patch de sécu ou diffère de leur vision)
[^] # Re: J'ai pas très bien compris
Posté par j-c_32 . Évalué à 3. Dernière modification le 27 août 2015 à 14:45.
Ne relançons pas le débat sur ce qu'est "l'esprit du libre".
Il existe plusieurs interprétations idéologiques de ce que sont les buts sociaux du libre.
Pour reprendre l'exemple donné par Zenitram dans un de ces commentaires plus haut, dire "tu penses qu'utiliser une licence NC sur une musique n'est pas contraire à l'esprit du libre, alors t'es un idiot et pas un libriste", c'est stupide. De même, dire "tu penses qu'utiliser une licence NC sur une musique est contraire à l'esprit du libre, alors t'es un idiot et pas un libriste" est stupide.
Au final, tu peux trouver des acteurs du libre qu'il serait stupide de prétendre pas libristes, qui font partie du premier groupe ou du deuxième.
Pour RedHat, si je ne m'abuse, ils ont quand même adopté des stratégies défensives en voyant que d'autres entreprises (je me souviens du nom d'Oracle, mais p-e je me trompe) les concurrençaient sur le service tout en profitant des développements de RedHat. Je pense que par exemple, ils ont arrêté de documenter leur patches ou de donner la liste de ceux qu'ils appliquaient et ceux qu'ils n'appliquaient pas, de manière à conserver l'expertise sur les solutions proposées par ces patchs.
[^] # Re: J'ai pas très bien compris
Posté par claudex . Évalué à 4.
J'ai peut-être de la merde dans les yeux mais je ne lis pas ça.
Ça serait contraire à la GPL vu que c'est un travail dérivé du noyau.
Non, Red Hat publie les sources1, ce que fait CentOS, c'est "juste" de les recompiler.
par exemple, les srpm de la version 6, pour la 7, ils ont carrément migré sur le git CentOS ↩
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: J'ai pas très bien compris
Posté par Renault (site web personnel) . Évalué à 4.
Vu que c'est un patch, je ne suis pas sûr.
Un noyau modifié et compilé avec ce patch oblige en effet son diffuseur à diffuser tous le code source associé, mais pour un patch indépendant sans distribution du source complet ou compilé, je ne sais pas si cela s'applique.
[^] # Re: J'ai pas très bien compris
Posté par jyes . Évalué à 2. Dernière modification le 27 août 2015 à 11:55.
C’est un patch, mais il a vocation à servir, et s’il n’est pas sous GPL (ou licence compatible, donc qui respecte les 4 libertés) un noyau patché compilé ne peut pas être distribué (conflit de licence, impossibilité de respecter la GPL qui impose que ce noyau compilé soit GPL et que donc toutes ses sources soient accessibles selon les libertés de base). Je doute que le sponsors soient intéressés par un patch qui ne leur permet pas de distribuer des noyaux patchés.
[^] # Re: J'ai pas très bien compris
Posté par Zenitram (site web personnel) . Évalué à 0.
Pourquoi?
(je demande un exemple de sponsor qui a besoin de distribuer des noyaux patchés pour faire son business)
[^] # Re: J'ai pas très bien compris
Posté par Patrick Nicolas . Évalué à 5.
Si le sponsor veut vendre du matériel qui utilise ce kernel, il doit fournir les sources.
[^] # Re: J'ai pas très bien compris
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 27 août 2015 à 12:11.
Merci, je connais cette phrase, elle n'apporte pas de réponse à ma demande, pas du tout.
tu n'as pas répondu à la question.
J'ai explicitement demandé un exemple de "si".
Dit autrement : lequel des sponsors a pour business de vendre du matériel qui utilise ce kernel et donc besoin de ce droit?
[^] # Re: J'ai pas très bien compris
Posté par Patrick Nicolas . Évalué à 3.
En effet le premier lien (atomiccorp) vend directement le logiciel, pas du matériel, les patchs sont téléchargeables sur https://atomicorp.com/downloads/
Le deuxième (prometheus) vend le produit du premier et les autres sont des hébergeurs.
[^] # Re: J'ai pas très bien compris
Posté par dj_ (site web personnel) . Évalué à 2.
Ils peuvent recevoir de l'argent de client en étant sous NDA…
Si une personne veut hacker du matos, si elle sais déjà quel protection il y a derrière c'est plus simple je pense
[^] # Re: J'ai pas très bien compris
Posté par Renault (site web personnel) . Évalué à 2.
Tout dépend de la clientèle visée.
S'il vise de gros infrastructures employés en internes, le noyau patché n'est pas diffusé.
De plus, selon moi, admettons qu'un industriel en embarqué prend le patch non GPL, patch le noyau et le distribue dans son équipement.
Selon moi la viralité de la GPL s'applique, le nouveau noyau est donc sous GPL.
Il peut donc diffuser le noyau avec les sources, mais il sera bien ardu pour le quidam moyen d'extraire ce patch de ce code source (en embarqués, ce sont les rois des modifs crades de partout).
[^] # Re: J'ai pas très bien compris
Posté par claudex . Évalué à 2.
Le patch, il ne sort pas de nul part, son écriture s'appuie sur le noyau. Et de la même manière que si on utilise une bibliothèque sous GPL, le code doit être compatible GPL ; si on écrit un patch, il doit être compatible GPL. Du moins, c'est comme ça que je l’interprète.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: J'ai pas très bien compris
Posté par Renault (site web personnel) . Évalué à 4.
Suivant le lien entre la bibliothèque et le reste du binaire, tu peux utiliser la bibliothèque GPL sans devoir rendre le programme sous licence GPL.
La licence s'applique sur le code source lié au binaire distribué, un patch c'est indépendant et envoyé en tant que tel ne tombe pas sur la nécessité de respecter la licence du programme d'origine.
[^] # Re: J'ai pas très bien compris
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 27 août 2015 à 11:55.
Ils diffusent un patch.
Donc rien de Linux, donc rien à faire de la la licence de Linux.
Le problème est si quelqu'un veut diffuser le noyau Linux patché (la, il ne pourrait pas).
Et vu que les sponsors sont des hébergeurs, en fait ça ne m'étonnerai pas que la prochaine étape soit en non GPL (les hébergeurs gardent en interne la version modifiée, et donc la GPL ne s'applique pas), mais ça ne semble pas être le contenu de l'annonce aujourd'hui (les sponsors gardent le patch pour eux suffit à faire pareil en pratique, et c'est sans doute ce qu'ils feront)
[^] # Re: J'ai pas très bien compris
Posté par Damien Thébault . Évalué à 1.
Un patch ne serait-il pas un travail dérivé ? Il a clairement besoin du code de base pour fonctionner.
[^] # Re: J'ai pas très bien compris
Posté par patrick_g (site web personnel) . Évalué à 3.
De toute façon le patch grsec est sous GPL.
[^] # Re: J'ai pas très bien compris
Posté par j-c_32 . Évalué à 1.
Exact, ma faute (le mot "interdire" est mal choisi, et je suis passé de "ne donnera plus son code à un non-sponsor" à "souhaite qu'un non-sponsor ne puisse plus avoir le code").
Cela dit, le journal dit que ce code est utilisé dans de l'embarqué. Est-ce que ça ne veut pas dire qu'en tant qu'utilisateur du produit, je ne peux pas faire une requête pour obtenir les sources ? On doit alors me fournir soit un lien, soit les sources directement.
Du coup, il suffit qu'un utilisateur d'un de ces produits demande et redistribue.
Je n'en étais pas sur (et d'ailleurs, ce n'est pas clair, cf. les autres discussions)
(
Ben ? C'est exactement ce que je dis:
"mais n'impose aucune restriction sur le code et ceux qui peuvent l'utiliser" <-> "Red Hat publie les sources"
"CentOS reprend le code pour le distribuer de façon simple à ceux qui veulent l'utiliser" = "CentOS reprend les sources et les recompile pour ceux qui veulent les utiliser" <-> "ce que fait CentOS, c'est "juste" de les recompiler"
)
[^] # Re: J'ai pas très bien compris
Posté par Renault (site web personnel) . Évalué à 3.
Ils fournissent le code de Linux complet, pas du patch spécifique. Et vu la tonne de patchs utilisé en embarqué en interne, pour extraire le patch grsecurity à partir de cela je te souhaite bien du courage.
[^] # Re: J'ai pas très bien compris
Posté par claudex . Évalué à 4.
Tu as écrit * CentOS reprend le code pour le distribuer de façon simple *, je l'interprétais comme le fait que le code source soit "caché" par Red Hat.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: J'ai pas très bien compris
Posté par Zenitram (site web personnel) . Évalué à 2.
Il suffit, voila, tout est dit.
Ah non, un autre intérêt : tu vas le chercher ailleurs, sans aucune garantie que ton fournisseur n'a pas mis de backdoor.
PS : au passage, il te file le Linux patché avec grsecurité modifié et d'autres modifs, c'est un "package".
emabarqué qui n'est pas sponsor, donc n'aura pas plus accès à la version stable que toi. Donc tu y gagneras quoi en fait?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.