djrom a écrit 303 commentaires

De ce que j'ai suivi, apriori, RMS a répondu dans une discussion privée par mail à quelqu'un qui lui posait une question précise. Et là, tu pars en latte en disant que "tout le monde s'en fou", qu'il faudrait qu'il "arrête de faire du buzz autour de lui" parce que quelqu'un a posté cette réponse sur LinuxFR pour en causer ? En quoi c'est de la faute de RMS que ce post ait été fait sur LinuxFR et que les gens en parlent ici ? Il devrait surveiller ce qu'il dit dans ses correspondances mail pour être sûr que "les gens" trouvent toujours pertinent ce qu'il dit ? WTF ? Il était pas en conférence, il représentait personne, je vois pas comment on pourrait lui reprocher quoi que ce soit de ce qu'il fait de sa vie dans ce contexte, c'est sa vie, il y a les débats qu'il veut avec qui il veut, je dirais. Des trucs qu'il dit sur des listes publiques, c'est autre chose, mais là je suis vraiment pas. C'est comme si on engueulait Linus parce qu'il a fait un troll Intel vs AMD dans un mail privé à Alan Cox qui s'est trouvé sur Internet.

Et puis bon, dans la catégorie "buzz", je trouve que RMS reste assez modeste, pas comme d'autres qui lancent des flamewars idiotes avec un point godwin dès le 0-ème post sur des listes publiques, il me semble.

Cela dit, tant qu'a avoir une version buggé du jeu, pourquoi le jeu ne va pas de lui même dire au serveur "je suis une version piratée" ?

Je dirais que c'est parce qu'avant la mise en place de leur DRM, le jeu parlait pas obligatoirement à un serveur (si la personne jouait pas sur internet, par exemple), et que donc, plutôt que de mettre en place une nouvelle infrastructure (un serveur qui écoute les dénonciations venant de jeux piratés) pour débusquer les vilains pirates, ils ont préféré utiliser une infrastructure existante (le support technique), quite à tricher un peu.

Ils disent ici comment ils ont fait pour évaluer la quantité de piratages: http://www.linuxgamepublishing.com/press_releases/200806241.(...) .

We obtained this estimate by seeding the download sites
with a number of broken copies of our games, and monitored the number of
requests for technical support that referenced the known bug we had
inserted.

Traduction:

Nous avons obtenu cette estimations en mettant en ligne sur des sites de téléchargement des copies volontairement défectueuses de nos jeux, et en regardant ensuite le nombre de requêtes de support technique qui référençaient le bug que nous avions inséré.

J'ai jamais fait le test sur une Xandros, mais avec mon EEE 701 sous Hardy, j'ai le même genre de résultats que ce graphe, càd de 2h30 à 3h30. Y'a moyen de faire un peu mieux sous les autres distribs que sous Xandros, parce que les possibilités de tweakage sont plus grande; on peut donc booster ses stats PowerTOP comme le premier jacky venu :)

Là tout de suite, sur un EEE avec la Xandros par défaut, j'ai ... 17 secondes de boot (BIOS compris), avec à la fin X de lancer et tout et tout. Bon évidemment, le même ordi sur une ubuntu met plutôt 40 secondes, mais la distrib' custom d'Asus pour l'EEE est la preuve qu'on peut avoir un linux qui boote en, en gros, quinze secondes.

La force de xmonad, c'est aussi son extensibilité. Y'a des extensions qui permettent de faire des tonnes de choses vraiment simplement, et plus le temps passe plus cette collection d'extensions grandit. Avec un mélange de ces extensions, on atteint un niveau de flexibilité assez incroyable, genre avoir un mode de tiling différent par bureau, voire même des choses comme gimp qui s'affiche dans un bureau à lui avec son mode de tiling à lui, mais avec ses barres d'outils dans un tiling particulier qui leur convient mieux. De pleins de manières, xmonad c'est un peu l'emacs des gestionnaires de fenêtres: ultra-configurable (avec des extensions, des hooks, ...), organisé autour d'un ensemble très réduit de concept puissants et un langage commun à tout ça pour lier le tout. Ce qui change par rapport à emacs quand même, c'est que la conf est plus simple, en tout cas je trouve; j'ai dû mettre une ou deux heures grand max à avoir un xmonad aux petits oignons, sous gnome (mais je connaissais déjà haskell cela dit, ça doit aider), et le fichier de conf est relativement petit (+/- 100 lignes bien aérées et commentées).

Un autre atout que je trouve à xmonad, c'est la doc: elle est assez abondante, générée automatiquement à partir du code et elle couvre à peu près tout, jusqu'aux types de données qui sont au coeur de xmonad, pour bien comprendre ce qui se passe si on veut.

A noter aussi qu'avec la nouvelle version de xmonad, la 0.5, y'a plus besoin de recompiler pour changer la conf, enfin plus précisement xmonad est une librairie, et le gestionnaire de fenêtre en lui-même est le fichier de conf qu'on construit qui est recompilé de manière transparente quand on lui demande de relancer xmonad pour tester la nouvelle configuration; la recompilation prend moins d'une seconde, et donc on teste la nouvelle configuration quasiment immédiatement, sans même avoir besoin de relancer sa session X. Le seul problème que ça peut poser c'est qu'il faut avoir un compilateur haskell, mais bon pour l'instant, il faut en avoir un de toute façon pour utiliser xmonad vu qu'il est pas packagé, donc ça change rien; et pour le long terme, c'est envisageable que la distrib fournisse la lib xmonad + les extensions en paquet et que le window-manager tourne dans un interpréteur haskell, et y'en a des tous pitits, donc ce serait pas très lourd.

En tout cas, après quasiment deux ans sous dwm, xmonad + gnome, c'est le combo ultime qui ro><e grave, je trouve.

PS: Si vous voulez avoir une idée de la richesse des extensions, jetez un oeil ici: http://www.xmonad.org/xmonad-docs/xmonad-contrib/index.html

Je suis tout penaud, j'avais une embrouille depuis des plombes avec mon gnome-terminal en UTF8 et une machine distante que j'accédais avec ssh en ISO, et ben là, avec luit, tout est reglé.

Merci donc, de m'avoir fait découvrir ce mignon p'tit truc.

Je crois que par "partie standard", le post plus haut voulait dire que c'était dans les sources vanilla du noyau, sans besoin de patcher. LSM fait partie du noyau depuis 2001 ou 2002. Après, effectivement p't'être il est pas activé par défaut.

Voir notamment un récit par LWN (en anglais) de récentes discussions autour de LSM: http://lwn.net/Articles/180194/

Donc, soit on est riche à milliards, soit on ferme sa gueule ? T'es vraiment un philantrope toi !

Petite histoire du "politiquement correct", au cas où ça intéresse des gens: http://lmsi.net/article.php3?id_article=252 .

Si pour toi un système donnant 4999 chances sur 5000 de tout péter est sûr, alors t'y comprend rien.

Pfff, t'as moyen de faire sans l'aggressivité ?

Au fait, cdrecord peut s'utiliser sans setuid. C'est comme ça depuis au moins 2 ans.

Est-ce que j'ai dit le contraire ?

Donc il ne faut surtout pas dire :
- "corrigé (B) car selinux sera inopérant si (B) arrivé, et ignoré (A) car selinux s'en charge".

Est-ce que j'ai dit le contraire ?

Bon ben trop d'aggressivité pour moi, et j'ai pas l'impression qu'on arrive à se comprendre. Alors t'aura qu'à avoir raison, et moi j'aurais qu'à "rien avoir compris", et pis voilà. Tcho !

Pour exploiter cette faille afin de contourner AppArmor, SeLinux et
autres, il faut déjà être root ! (dexit l'auteur du papier). Donc il faut déjà exploiter une autre faille. Et on peut supposer que cette autre faille ne contourne pas Selinux etc. Sinon qu'elle est l'intérêt de la faille découverte par Loïc Duflot ?

Il faut exploiter une autre faille ? Et donc ? Les failles deviennent souvent dangereuses en combinaison, c'est assez rare les failles "arg, n'importe qui peut devenir root à distance". Plus souvent, t'exploite déjà une failledistante qui te donne un accès apache genre, et après t'exploite une faille locale qui te permet de devenir root.

Ah oui, et puis "devenir root" n'exige pas forcément une faille. Tu peux souhaiter que l'utilisateur légitime de root n'aie pas accès à certaines choses, et c'est justement l'interêt de ces systèmes de sécurité.

L'idée c'est que pour obtenir un système Unix un peu plus sécurisé de nos jours, on utilise deux systèmes de sécurité: le mécanisme standard des utilisateurs Unix, et un mécanisme en plus (genre AppArmor, SELinux, securelevels, ...), le mécanisme en plus permettant de limiter les possibilités plus finement, et même pour les personnes en haut de l'échelle Unix normale (genre root ou sudoers). Cette faille fout en l'air ça.

Quand je me loggue root sur ma bécane, je ne pense pas qu'exploiter une faille de X11 me donne encore plus accès à ma bécane. Et toi ?

*Ta* bécane, non. Mais une bécane utilisant SELinux pour limiter les possibilités de root, si. Et dans ces cas là, cette faille est vraiment génante.

Sur un système Linux moderne, ça veux pas forcément dire être root

Je développe ce que je voulais dire, parce que visiblement on s'est pas compris.

Quand je disais ça, je voulais dire que y'a des tonnes de mécanismes sur un Linux moderne qui permettent à un logiciel d'avoir une partie seulement des pouvoirs de root, sous la formes des capacités par exemple. Typiquement, t'utilise ça en combinaison avec pam pour permettre à tel ou tel programme de se lancer en mode realtime, ou d'avoir accès à un matos précis, ...

Du coup, il doit sûrement y avoir une combinaison de capacités qui permet de reproduire cette faille sans être root. C'est pas développé dans le papier, parce qu'il s'intéresse pas à Linux en particulier, mais il suffirait de jeter un oeil plus précisément pour trouver. Et qui sait si genre cdrecord, ou je ne sais quel programme utilisant le hardware en mode bas-niveau n'a pas ces capacités là.

Et puis sinon, y'a une autre méthode assez bête: exploiter une faille dans un programme suid root.

Et là, on en revient à ce que je disait, les trucs genre SELinux sont conçus précisément pour éviter qu'une personne exploitant une faille pour devenir root soit le maître de la machine. Avec cette faille c'est foiré. Et j'ai pris SELinux, mais y'a des tonnes de choses de ce genre, genre jail(), les vservers, UML, ... A priori, cette faille peut les foutre par terre.

Il y a foutage de gueule de dire qu'un trou de sécurité potentiel est grave si et seulement si le système est une vraie passoire.

Libre à toi de considérer "y'a une faille qui permet de passer root en local" est l'équivalent de "le système est une vraie passoire". Moi je considère pas que ce soit le cas justement parce que j'utilise des mécanismes pour limiter les possibilités. Cette faille bousille ça, ça m'embête.

La chose est simple: des failles qui permettent de passer root, y'a en tout le temps. Des failles qui permettent de passer les systèmes de sécurité "alternatifs", y'en a très peu souvent, voire même quasiment jamais. Et cette faille, c'est un trou béant. Donc elle a de l'importance.

Encore faut-il être en position exploiter cette faille ce qui n'est pas une mince affaire. Donc, je répète, il faut le faire en deux phases et pour la première phase, on ne sait RIEN.

Ben oui, parce que le type est chercheur en sécurité, alors il va pas expliquer comment exécuter du code en tant que root sur une machine Unix, ce serait assez inintéressant.

Pour cette histoire avec Théo de Raadt, effectivement il bosse pour OpenBSD, c'est même le leader et développeur principal, alors le qualifier de "fan d'OpenBSD" ... Le fond je sais pas, j'ai pas lu le thread.

A ceci près que dire "il faut être root, donc ça sert à rien" c'est assez imprécis.

Dans le papier en question, il est mentionnée clairement que cette faille peut être utilisée pour contourner les systèmes de sécurité qui imposent des restrictions même à root, comme AppArmor, SELinux, ou les securelevels OpenBSD. Avec cette faille, on en revient au modèle Unix traditionnel que ces systèmes essayaient justement de remplacer. C'est assez gênant. Ah oui, sans oublier qu'il faut pas forcément être root, il suffit d'avoir les bonnes capacités d'accès au matos. Sur un système Linux moderne, ça veux pas forcément dire être root, vu qu'un gros effort à été fait pour permettre de modulariser toutes ces capacités que root a. On peux pas critiquer l'auteur du papier en disant "le gros naze, il a rien compris, il faut être root pour exploiter son truc", vu qu'il le dit lui-même, et que c'est justement un des interêts de ce papier: nous montrer les problèmes qui nous attendent pour foutre des nouveaux schémas de sécurité sur nos vieux Unix.

Pour résumer, on a une faille qui fout par terre tous les systèmes de sécurité "modernes" sur un système Unix, pour en revenir au bon vieux "root = dieu" qu'on essaie (dans le domaine de la sécurité avancée, genre pas les machines de bureaux) de mettre aux oubliettes. Ca concerne peut-être pas tes machines à toi, mais cette faille embête beaucoup de gens qui utilisent des Unix pour faire quelque chose de vraiment sécurisé. Pour ces gens là, c'est un "grave problème de sécurité", sisi.

PS: Ah oui, et les clichés sur les "fans d'OpenBSD", franchement ...

Juste pour préciser que le fait d'avoir des opérateurs différents pour la même opération n'est pas justifié par l'inférence de types en soit. On peut enrichir le système de typage de façon à rendre possible l'utilisation du même opérateur pour plusieurs types.

Dans le cas d'Ocaml, je crois que c'est plutôt un choix. D'autres langages avec inférence de type ont fait un choix différent, comme Haskell par exemple.

Disons du vaporware que tu peux télécharger et essayer, quoi: ftp://ftp.cpan.org/pub/CPAN/authors/id/L/LT/LTOETSCH/parrot-(...)

Avec même pleins des vraies choses qui marchent, sisi !

Heu, pour une fois, je vais faire le boulot de pasBillpasGates. NTFS fragmente très peu, en tout cas pas plus que ext2/3 ou XFS. C'est un système de fichier moderne quoi, voire même plus sur certains côtés que les nôtres. Alors bon, taper sur NTFS pour la fragmentation, c'est un peu naze :)

PS: oui, je sais, ils ont gardé l'outil de défragmentation dans Windows, mais ça prouve pas grand chose. Enfin, ça prouve pas plus de choses que de savoir qu'on a des outils de défragmentation dans Debian.

FUSE est intéressant, mais n'est pas vraiment équivalent aux translators (j'aime pas trop traduire les termes techniques précis) du Hurd.

D'une part, il y a beaucoup de problèmes quant à la sémantique que tu obtiens avec FUSE par rapport aux permissions (voir le thread suivant de la LKML: http://thread.gmane.org/gmane.linux.kernel/295707(...) )

Ensuite, les performances ne suivent pas du tout avec FUSE, parce que c'est un hack assez intelligent autour du noyau, mais que ça reste un hack. Le noyau n'étant pas conçu dans ses principes même pour faire ça, le coup en terme de performances est assez prohibitif.

Un autre problème est une question de sécurité/stabilité: rajouter FUSE, c'est rajouter un module qui tourne en espace noyau, module faisant un tas d'interactions complexes avec l'espace utilisateur, et donc étant sujet à bug(s). Si ton FUSE crash, ton noyau est par terre. Si une personne trouve une faille de sécurité dans FUSE, pouf il a un exploit local (et même peut-être distant) pour faire tout ce qu'il veux.

Ca fait un bout de temps qu'on peut voir sur Internet FUSE cité comme un exemple de "le Hurd ça sert à rien, on peut déjà tout faire sous Linux". Mais c'est pas vraiment la même chose. Les translators font parti de la base même du fonctionnement de Hurd, avec tout ce que ça apporte comme avantages en terme de performances, de scalabilité (un mot meilleur ?), de sécurité, ... FUSE offre un équivalent en terme de fonctionnalités pures, mais pas avec la même facilité/élégance. On pourrait dire que comparer FUSE aux translators du Hurd en les présentant comme équivalents, c'est comme utiliser Cygwin pour dire "Linux, ça sert à rien, on peut faire tourner ce qu'on veut comme programme UNIX sous Windows". Dans un cas comme dans l'autre, les fonctionnalités sont les mêmes, mais pas avec le même confort.

Cela dit, 'me faites pas dire ce que j'ai pas dit: j'ai pas affirmé que le Hurd était utilisable, génial, révolutionnaire, ou quoi que ce soit. (c'qu'il faut pas faire pour couper l'herbe sous le pied des trolls :))

La petite différence étant que le gros de l'équipe Ubuntu est formée de développeurs qui sont aussi des développeurs Debian. La situation n'est donc pas vraiment la même que pour RedHat/Mandrake.

Je dirais que tu fais une petite erreur dans ton Google. Ce que tu pointes sont des sites qui ont diffusés cet appel, ce qui ne veux pas dire que ça venait d'eux. Notamment, dans les liens donnés par Google y'a beaucoup de site de publication ouverte (genre Indymedia), où le collectif qui s'occupe peut avoir très peu à voir avec les diffuseurs/rédacteurs de l'appel.

A noter quand même quelques problèmes de sécurité dans dm-crypt dans l'état actuel, problèmes qui devraient être réglés d'ici quelques temps, néanmoins:
http://clemens.endorphin.org/LinuxHDEncSettings(...)

Heu ... je ne sais pas si tu as regardé la liste des appelants à cette manif', mais beaucoup font exactement ce que tu décris, et veulent lancer cette appel de manière complémentaire à ce qu'ils font d'habitude.

Quant à l'idée que ces manifestations ne servent à rien, tu me semble bien définitif, sans trop de faits pour étayer.

Idem pour le hurd ( deja qu'avec rms a la tete du projet y a du mal , alors sans lui ...)
Juste pour préciser que RMS n'est plus depuis longtemps à la tête du projet Hurd.

Même si ça ne plait pas à Stallman

Y'en a pas marre de cette connerie ? Stallman n'a jamais rien dit contre les autres licences libres (à part si on considère que dire "telle ou telle license n'est pas compatible GPL" est une attaque), n'a jamais prétendu que libre = GPL et la FSF liste les licenses libres de manière détaillée et exhaustive (enfin, je crois), ce qui est une preuve qu'ils ne sont pas contre, non ?

Pour des infos plus précises sur ce qui est arrivé, vous pouvez aller voir ici: http://docs.indymedia.org/view/Global/WhoTookAhimsa(...) (en anglais)

Sinon, pour suivre un peu l'affaire, vous pouvez aussi aller sur http://indyblogs.protest.net(...)

Oops, à cause du titre pas vraiment explicite de l'autre post, j'avais pas fait attention.