Comme des centaines d’autres distributions… À quand la factorisation des efforts ?
c'est déjà fait, ça s'appelle le code des softs upstream. En fait, 90% de ce que tu retrouves dans une distribution est du code qui est partagé par tout le monde. Ensuite, bien sur, les gens se focalisent sur les 10% restants, n'ayant aucune idée de la chaine globale.
En fait, même pour l'infrastructure, c'est massivement mutualisé, tout le monde utilise les mêmes serveurs webs, etc, etc.
Ben justement, c'est la question. Bien sur que c'est rapide, c'est un commentaire sur linuxfr, pas guerre et paix ( même si j'ai déjà écrit des romans en commentaire ). On peut en discuter pendant des heures, comme déjà savoir si il y a une montée ou pas.
Mais par exemple, on peut comparer avec d'autres pays de taille comparable. Est ce qu'il y a autant de choses autour de la sécurité en espagne, en allemagne ? L'allemagne a toujours eu le CCC, mais c'est pas le même public visé que Hackito Ergo Sum ou d'autres comme le SSTTIC.
Est ce que la présence du minitel ( et donc la monétisation des services qui va avec ), le fait d'avoir des accès au net pas cher ( ou plutot moins cher qu'ailleurs ) est aussi une cause de la démocratisation de l'internet, donc de la montée de la sécurité informatique en France ? Peut être.
Il est généralement reconnu que ça a fait un bond après les attentats du 11 septembre, parce que l'état américain a financé plein de projets et donc a lancé la machine économique ( et j'aurais tendance à le croire aussi ). Ensuite, une fois les deniers publiques épuisés, la technologie s'est retrouvé dans le civil, vu que la croissance du point de vue des militaire et de l'état était soit bouché, soit illégal ( ie, dictature, etc, ce qui n'a pas empêché ).
Mais ensuite, la politique sécuritaire du gouvernement sarkozy, peut être lié aussi aux retombées en occident du 11/09 n'ont pas aidé à instauré cette montée ? La loi HADOPI, le concept d'"internet civilisé", etc, tout ça, c'est aussi des choses qui ont instauré l'idée que l'internet est une source de danger et de non droit.
Et mon point, c'est pas qu'il n'y avait pas de sécurité avant, mais qu'il y a en a beaucoup plus maintenant. C'est pas une croissance faible ou un niveau constant, c'est une croissance des plus fortes. ( encore une fois, on passe de 1 conf franchouillarde par an à 4 ce trimestre ). Et ces conférences sont organisés par des personnes locales. Les gens du milieux se plaignent que le STICC est noyauté par l'ANSII et les grosses boites, mais c'est aussi parce que ces groupes ont grossis. Thales, EADS, etc, y a quoi comme équivalent à l'étranger, et est ce qu'il y a une corrélation entre la présence de grand groupe du même genre et d'un milieu de la sécurité vivace ?
Peut être qu'il y a une monté de la visibilité des crimes qui irait avec une monté de l'information disponible. Peut être qu'il y a une montée parce que les barrières à l'entrée sont plus basses, que les risques sont moindres, c'est sans doute aussi une explication. peut être qu'il y a juste une montée de la visibilité de la sécurité informatique, je sais pas.
Il y a sans doute plus d'une raison, et je ne dit pas que ma proposition est la seule cause, loin de la. La question est de savoir si c'est une cause ou pas. Ou une conséquence. Ou un hasard. Après tout, l'extrémisme politique arrive ailleurs, et pour d'autres raisons. Mais par exemple, ailleurs en europe, je ne croit pas qu'on retrouve les mêmes choses qu'en France ( ie, climat poussant à ne pas croire l'internet, tout en ayant favorisé la montée de l'internet dans les années avant via la mise en place d'infrastructure, et via des initiatives privés ( free par exemple )). Par exemple, je pense que la France est très avance sur le libre ( dans le sens ou on a beaucoup de contributeurs francais ) parce que la DST a coupé une montée des "hackers" dans les années 80, ce qui fait qu'une génération de gens se sont retrouvés à faire du libre au lieu de faire des mouvements comme le CCC comme en Allemagne. Et peut être que cette montée des libristes a permis l'arrivé de FDN, de Free, et une certaine compréhension du fonctionnement du réseau, qui a permis d'avoir plus de libristes, plus d'internet, et à la fin, plus de gens dans le milieu de la sécurité.
Un segfault peut aussi induire un DoS, et un DoS est un souci de sécurité. La sécurité vise à assurer la disponibilité et l'intégrité du SI entre autres choses. Si ton SI ( on va dire celui d'une agence de recrutement ) ne marche pas car un petit malin a mis un cv qui fait planté ton système, tu perds la disponibilité, don cdu pognon. Et ça, c'est pas bon(tm). Ensuite, bien sur, une elevation de privilége en root, ça fait tout de suite plus peur. "oh attention, quelqu'un va devenir root et à partir de la, envoyer du spam, ou piquer votre base de données de cv".
Curieusement, ce genre d'argument pour windows xp ne marche pas pour faire migrer les gens vers un autre OS bureautique, ce qui montre que les gens ont un modèle mentale spécifique des attaques.
ça résume bien ce qui va pas dans le monde de la sécurité. Y a plein de pognon à se faire car le processus de décision contourne la rationalité. Le secret autour des affaires fait que les légendes urbaines et les exagérations sont légions ( suffit de voir les histoires de cyberwars ). Le cinéma fait tout pour faire rêver et faire croire que la sécurité et les ordinateurs, c'est magique et/ou compliqué et/ou tout troué. On vends aux gens de la peur basé sur justement de l'imaginaire, donc ça parle directement à un niveau moins rationnel de l'esprit.
Comme le dit Linus dans une interview cité plus haut, et comme j'ai pu le constater souvent en bossant dans le domaine et en lisant les MLs de projets, certains gens dans la sécurité sont très manichéen avec une vision tunnelisé.
Et comme il y a d'énormes ressources en jeu ( lire pognon ), il y a plein de monde et du coup, le monde de la sécurité est plus dans l'opposition et la compétition que dans la coopération, coopération qui est au coeur du logiciel libre et qui explique le clash des cultures. Et pas opposition juste quand il y a de l'argent, ce qui à la rigueur serait normal. Non opposition du style "je passe des jours à montrer qu'un bug est une faille et en plus,je passe le double du temps à contourner les systèmes de sécurité des autres pour faire une petite pique pour montrer qu'ils servent à rien".
Opposition car les "leaders" du monde de la sécurité sont souvent dans un des 2 extrêmes entre "paranoiaque et très discret", ie, on ne lit pas d'interview d'eux, voir connait pas leur vrai nom ( SolarDesigner, par exemple, même si maintenant, on connait son vrai nom ), et "grande gueule et porté sur l'obsession de la sécurité, voir l'exagération". Donc à partir de la, les grandes gueules gagnent la bataille médiatique, donc on a tendance à suivre leurs exemples. Suivre pour la vision tunnelisé, suivre dans l’exagération, voir promouvoir des gens comme expert alors qu'ils ont plus d'une fois parlé de casser AES.
Ensuite, je connais plein de gens qui ont une approche plus balancé de la sécurité, je ne nie pas leur existence. Mais eux, on ne les entends pas, ils ont pas une horde de gens prêt à reprendre leurs idées non extrémistes sur le web, donc on prends pas en compte leur point de vue.
Et enfin, la question qui se pose, c'est de savoir si c'est le milieu qui transforme les gens, ou si c'est les gens qui transforme le milieu. Et si au final, c'est une bonne chose de voir qu'en France, on a 4 conférences de sécurité international durant ce trimestre. Ou plus audacieux, est ce que la monté du front national en France et la monté de la sécurité informatique ne sont pas liés ( liés dans le sens ou "se méfier des autres" devient une idée de société prédominante )
Je ne suis plus un professionnel du domaine, mais j'ai pris une douche, donc je m'estime un minimum propre. Parfois, si tu as une faille, tu agrdes parce que tu as pas le temps de t'en occuper. Moi, j'ai trouvé des trucs mineurs en faisant de la lecture de code, j'ai fait un rapport de bug par mail, j'attends le correctif. Depuis janvier.
Ensuite, c'est dans l'absolu, si j'avais un truc de ce genre, oui, je tenterais de faire corriger ça assez vite. Et pour ça, c'est simple, au moins pour le logiciel libre. Y a assez de gens sur la liste oss-security pour t'aider à coordonner une release du patch avec un embargo pour que ça soit fait le plus proprement sans faire trop de dégâts.
Dans le cas de spencer, chaque fois que je lit ce qu'il écrit, il est souvent agressif et/ou hautain et rarement coopératif. Et c'est en voyant ce genre de mec ( car c'est pas le seul dans le milieu ) que j'ai compris que le monde de la sécurité est mauvais pour l'équilibre psychologique des gens ( et donc que j'ai pas cherché à re bosser dans le domaine à nouveau, si c'est pour trainer avec des mecs dans son genre ( et c'est pas le seul, je précise ), je préfère devenir admin windows au tadjikistan )
Et c'est aussi en le lisant que j'ai pigé que le patch grsecurity serait sans doute jamais mergé upstream, donc jamais à l'abri d'un coup de tête du dev principal, donc à éviter pour ma part.
C'est une question de ressources. Soit tu prends un noyau ou les gens auditent tout pour la sécurité, mais ça avance pas aussi vite que tu voudrais, voir ça vire des options que tu voudrais ( exemple, la virtualisation que l'équipe openbsd considère comme mauvaise pour la sécurité, donc ne veut pas intégré ça ). Soit tu prends un truc qui avance et ou le prix du progrès, c'est d'avoir parfois des failles.
Sinon, si tu veux une vraie équipe sécurité, y a des boites qui font leur propre OS qui paye des gens pour ça. Exemple, Apple, Microsoft, SunW Oracle mais bien sur, tu doit payer. Y a des boites qui payent aussi des équipes sécu pour le logiciel libre, genre Red Hat, Suse, Canonical, mais pareil, les revues de sécurité, ça tombe pas du ciel.
Dernière possibilité, commence à faire des revues de code en même temps que tout le reste de la lkml, lead by example, etc, etc.
Poster sur Linuxfr sans rien faire, ça va juste rien faire.
On a pas du avoir les mêmes Fedora alors :)
J'ai toujours laissé SELinux installé et activé. Je dit pas que j'ai jamais eu de popups, j'ai reporté pas mal de bugs sur la policy justement, mais je dirais pas "sans arrêt des popups". Et en général, c'était pas sur les softs installés par défaut.
Les erreurs courantes que j'ai vu avec des gens et SELinux, c'est quand tu touches à la configuration des daemons en réseau ( vu qu'il y a globalement que eux qui sont confinés ). Par exemple, tu fait tourner sshd sur un autre port sans configurer selinux pour ça. Que tu décide de mettre ton ftp dans /home/monsiteweb et que pareil, tu précises pas à SELinux que c'est des objets que apache a le droit de lire et vsftpd a le droit d'écrire, etc. ou des trucs que tu installes à la mano.
Dans la configuration par défaut, en règle général, ça passe. Et plus il y a de gens qui utilisent selinux, notamment sur les versions de dev ( genre F19 en ce moment ), plus vite la policy est corrigé. Les packageurs Fedora sont assez réactifs à ce niveau.
Et pour la question de l'utilisation plus grand public, ça dépend des risques d'attaques sur ta machine.
Tu pourrais te dire par exemple qu'un simple assistant va pas avoir de souci, mais si c'est l'assistant de la directrice générale du groupe, ça reste une cible de choix. Ensuite, out of the box, l'utilisateur bureautique n'est pas protégé par SELinux dans la policy déployé par Fedora, car ses processus tournent sans confinement même si des choses comme le fait de bloquer ptrace ( http://lwn.net/Articles/491440/ ) aident à sécuriser. Pour ce genre d'utilisateur, je pense que le confinement tel que Canonical le prévoit va servir une fois que ça sera au point.
Donc je pense plus que tu as le support entreprise pour le kernel maison ( ie la partie intéressante ), et que le reste est disponible grâce à une moulinette semi-automatique et moins intensivement testé et sur laquelle y a pas de garantie (notamment pour les drivers tierces). IE, que le support Fedora/Ubuntu est juste la pour servir de demo sur des machines de test afin d'attirer les clients, tout comme leur version d'essai de 30 jours pour RHEL. Bien sur, Oracle ne parle pas du fait que la version d'essai doit sans doute annuler le support RHEL.
En fait, au vu des postes de blogs ( https://blogs.oracle.com/ksplice/entry/ksplice_update_for_cve_2013 ), il semble que ksplice oblige à attendre le distributeur de base quand même, et au final, vu qu'il y a assez souvent de mesures qui vont réduire l'impact ( mitigation feature, je suis pas sur de traduire ça comme il faut ), ç'est AMHA mieux de passer par les dites features si ton but est d'être protégé vite fait. Du coup, une fois que tu es protégé sans avoir rebooté, tu as plus besoin de ksplice.
Donc oui, comme tu dit, c'est un marché de niche même si 70 clients, c'est déjà pas mal (ie, moi, je connais des boites avec moins de clients en 5 ans) et je pense que plein de gens voudraient ça (mais je connais personne qui utilise ça, alors que le support pour Ubuntu LTS est fourni).
La valorisation de la chose, suffit de voir que c'est juste fourni de base avec le support oracle. Donc ils ont fait le calcul sur le fait que vendre ça comme service, ça rapporte moins que comme "cadeau gratuit" à leur clients existants.
Bien sur, tu prends en compte le fait que certaines failles sont justes dans les noyaux récents et que ta distro pas-rolling-release n'est pas touché ?
exemple, CVE-2013-1858 CVE-2013-1979 et CVE-2013-1959 dans le noyau 3.8 uniquement, pour ne citer que les plus récentes qui me viennent à l'esprit. Ou justement la faille dont parle le journal, qui touche pas RHEL5 ou plus vieux. Ou par exemple, CVE-2009-1527 qui touche que le 2.6.29.
Et j'ai pris juste une paire d'exploit au pif dans la liste des CVEs, j'ai peut être eu de la chance, mais je suis pas sur.
Non, le souci n'est pas la licence (en tout cas, ça n'était pas la licence au début), le souci, c'est soit y a des limitations (genre pas le droit de toucher à la taille du code binaire sinon tu décales tout les pointeurs, pas le droit de toucher aux structures, etc, etc), soit tu es obligé de faire des grosses réécritures de la mémoire, et ton kernel est dans un sale état. En fait, quand tu vois que les devs kernels voulait retirer la possibilité de retirer les modules car c'était trop compliqué (à l'époque du 2.6, je crois), c'est bien qu'il y a quelque choses.
Donc pour mettre à jour ton kernel, tu dois "juste" changer du code, mais pour change rle code, faut le faire de tel façon que le kernel soit le même du point de vue du layout. Même si pour les failles les plus importantes, ça semble être bon d'aprés wikipedia, il semble que pour une petite partie des failles ( 12% ), il faut faire intervenir un développeur pour bidouiller la mémoire du kernel. Et bien sur, les chiffres ne parlent que de 64 failles sur 3 ans, quid des autres updates que tu voudrait aussi appliquer sans rebooter ?
Et ça, ça part du principe que tu part avec un kernel connu dont tu as le code, pas un kernel bidouillé ou avec des modules customs ou ce genre de choses. Et bien sur, chaque modif implique un patch spécifique, et chaque patch spécifique implique des tests poussés (car bon, c'est une chose de tester un soft dans un état connu contre une faille, c'est autre chose de tester un soft dans un état inconnu contre une faille et tout les emmerdes possibles, surtout face à des soucis de processeurs multiples, etc. Et tu veux pas non plus que ton update bloque le kernel trop longtemps pendant que tu fait la mise à jour, vu que le kernel est freezé le temps de magouiller tout)
Et je sais pas si tu peux enchainer les updates ksplices advitam eternam.
Donc non, en pratique, la plupart des distributions n'ont pas les ressources (en plus maintenant de plus avoir le code à jour). En pratique, Oracle n'a visiblement même pas les ressources suffisante pour faire ça sur les 2 kernels de sa distribution malgré le fait que leur distribution ne soit qu'un rebuild de l'original (ou alors, ils mentent quand ils disent qu'ils sont compatibles de façon binaire, mais Oracle peut pas jouer sur les 2 tableaux à ce niveau la). IE oracle ne propose ksplice que pour son kernel maison, celui qu'ils rebasent sur le 3.0 (vu qu'ils ont pas envie de faire des rebases peut êtrepour des questions de moyens) avec btrfs en production et supporté, voir http://www.h-online.com/open/news/item/Btrfs-ready-for-production-in-new-Oracle-Linux-kernel-1471706.html .
Ensuite, peut être que je suis mauvaise langue, c'est vrai, ksplice inc avait réussi à avoir 70 clients en 2 ans d'existence, c'est pas mal.
tu oublies aussi que parfois, les contrats circulent avec des formats fermés, lu par des outils proprios dont l'éditeur n'a pas forcément mis l'accent sur la sécurité ( ou du moins, pour ce format en particulier ). Voir même que pendant longtemps, les dits contrats étaient stockés sur des machines sans disque dur chiffrés.
Et pourtant, l'économie n'est pas en crise à cause du manque de sécurité informatique, plutôt le contraire, les marchands de peur arrivent très bien à s'en sortir.
Ensuite, faut avoir systemtap sur sa distribution ( et vu que pour le moment, ça sert pas mal pour écrire ce genre de magouille, je pense que toute les distros devraient l'adopter vite fait )
Les gens qui ont commité le fix en Avril dans le trunk du noyau savaient qu'ils corrigeaient une faille de sécurité ou pas?
C'est assez délicat de savoir si tu as un truc exploitable ou pas dans la plupart des cas. Même sur des failles simples ( genre usage de /tmp avec un nom un peu prévisible ), tu passes du temps à essayer de voir si tu as un scenario pour monter une attaque pour pas apparaitre comme celui qui dit de la merde et qui s'affole sans savoir de quoi il parle.
Et les attaques les plus simples ( genre buffer overflow ) sont de nos jours assez bien comprises et anticipés ( au moins dans le code du kernel ), donc il reste que les cas les plus compliqués qui sont dur à évaluer.
Ensuite, c'était plus pour vejmarie ( vu qu'il est président de SDS, je pense qu'il peut contacter le service commercial de Grobill pour dire "ça serait bien de corriger tel faute" sur notre produit )
Ah oui, c'est un exemple plus parlant que celui de l'armée :)
En fait, si tu veux avoir des relations, il faut pas juste rajouter un 3eme élément qui est considéré comme étant "hors de la politique de sécurité" et qu'on suppose être capable de décider et de suivre la politique, donc de vérifier l'intégrité ( ou dans le cas de Bell-Lapaluda, de forcer la déclassification des données ) ?
IE, dans le cas que tu donnes, un humain comme l'admin de la machine.
En fait, je réalise ( je réalise beaucoup ce matin ) qu'on utilise les dites politiques de sécurité parce qu'on fait pas confiance aux programmes pour avoir un minimum de jugement pour dire "ça, c'est louche", mais l'armée fait pareil vis à vis de ses membres, en demandant à ne pas réfléchir aux ordres mais en devant compenser ça par des politiques stricts. Au final, l'armée gère presque des machines biologiques.
Si je dois citer tout les solutions de sécurité qui vont changer le système de permission de façon conséquente, faut que je rajoute smack (utilisé par meegoo), tomoyo et sa longue histoire, les différents modules du projet trustedbsd, bitfrost (olpc), aegis (nokia n9), le modèle d'android et sans doute une paire que je connais pas (ou qui n'ont pas de petit nom).
On a beau dire "le modèle Unix est parfait et loué soit ses codeurs", refaire la liste montre bien qu'il y a quand même du monde qui cherche à l'adapter car il est totalement inadéquat (au contraire de Sheila). Et c'est sans prendre en compte le souci que xkcd résume bien: https://www.xkcd.com/1200/ , à savoir qu'il y a aussi tout le souci d'authentification sur le réseau, et la tension entre "facilité d'utilisation" et "blocage en cas de compromission".
Oui, mais le souci, c'est que c'est pas activé par défaut. Le particulier en question veut être secure, mais si ça empêche des tas de choses genre "envoyer ma clé privée sur gmail pour faire un backup", ou "ne plus pouvoir utiliser firessh", il va raler :)
Je vois bien le nombre de gens (à commencer par des OEMs, donc des gens à priori techniques) qui commence par "faut désactiver selinux", c'est pas tip top.
Ensuite, les profiles de firefox/chromium ont aussi le souci de pas être aussi étanche qu'ils devraient, vu qu'il y a divers attaques sur les variables d’environnement, il y a dbus (qui n'est pas encore apparmor aware, et qui est selinux aware mais c'est pas trop utilisé), le keyring, etc. Les soucis pour le confinement d'application sont bien détaillé dans le document d'ubuntu que j'ai donné.
Alors, AppArmor et SELinux, ce sont 2 modules de sécurité du noyau (LSM, linux security module). L'idée est d'avoir des extensions du kernel pour accepter ou pas certaines opérations sur la base de critères externes ( voir ça comme un firewall pour les fonctions du kernel ).
Les LSM permettent plus que ces 2 la, mais je vais pas me disperser. Les 2 servent à appliquer des règles de qui a le droit de faire quoi plus souple que le simple modèle unix.
Ensuite, la ou ça diffère, c'est comment tu le fait. SELinux est un système de label couplé avec des règles. Tu mets un label sur les utilisateurs, sur les fichiers, sur les processus, etc, et tu écrit des règles pour régir l'interaction.
Par exemple, quelqu'un avec le label admin_u ( _u comme user ) a le droit de faire exec sur un fichier avec le label network_t ( _t comme type ), ce qui va donner un processus avec network-exec_t ( y a une regle qui dit comment les labels évoluent ). Et ce processus a le doit de faire tel ou tel chose, comme ouvrir un socket, et ainsi de suite.
Apparmor, c'est la même idée, sans les labels. IE, tu donnes direct les chemins de fichiers. Tu va dire "tel programme /usr/bin/toto a le droit de lire tel fichier, tel fichier, et faire tel opération". Par exemple, tu va dire que evince n'a pas le droit de lire ton .ssh, même si tu as le droit toi en tant qu'utilisateur de manipuler les fichiers. Si jamais un pdf contient un malware, il va pas piquer ta clé ssh.
Personnellement, je trouve SELinux plus souple, mais je suis partiel.
L'idée à la base, c'est de pouvoir confiner les processus et/ou les utilisateurs, ou de gérer des politiques obligatoires ( MAC, mandatory access control, par opposition à un DAC, discretionnary access control, qui sont les droits unix gérés par les utilisateurs eux mêmes, et donc potentiellement non conforme à ce que l'organisation veut ).
L'idée est que si tu as une faille dans un processus confiné, en temps normal ( ie non confiné ), il peut faire ce qu'il veut. Par exemple, si je prends la main sur apache via une faille, j'ai l'accès d'un utilisateur non privilégié et de la, je peux rebondir, faire des connexions vers l'extérieur, lancer des programmes avec d'autres failles, lire des fichiers non protégés, etc. Avec SELinux/AppArmor, tu peux interdire de faire ça.
Ça implique d'avoir une politique de sécurité, mais justement, Ubuntu propose des politiques ( appelés profil ) pour certains démons, Fedora/RHEL/Centos propose une politique SELinux des plus complètes
A partir de SELinux, tu peux aussi mettre en place différents modèles de sécurité des données, souvent mis pour des organisations militaires :
modèle Bell Lapadula, ou grosso modo, chacun a une classification ( donc un label assigné ), chaque document a une classification ( donc un label aussi ), par exemple, public, privée, confidentiel, top secret, par ordre de criticité. Les gens avec l'habilitation privée peuvent écrire un document privée, confidentiel, et top secret, et ne peuvent lire que public et privé. Ce qui fait que l'information top secret ne va jamais devenir moins que top secret ( sauf personne non soumise à la politique de sécurité ).
modèle Biba, qui est l'inverse, ou tu as par exemple 3 classifications, soldat, colonel, général. Les gens de rangs le plus haut peuvent écrire des documents à destination des gens en dessous, mais pas les lire. Et tout le monde peut lire les documents venant d'en haut. Et ça permet donc de formaliser la chaine de commandement d'une armée, ou par exemple, tu es sur que les ordres viennent bien d'une personne au dessus de toi. Le soldat ne peux pas donner d'ordre à un colonel, mais le général peut.
Formaliser la politique de sécurité permet de s'assurer que personne ne va faire des conneries comme virer les droits top secret par erreur.
( ensuite, il faut je précise d'autres mesures pour éviter d'autres attaques )
Enfin bon, je pourrais parler de SELinux pendant des heures, un peu moins de AppArmor ( je connais moins ) mais j’espère que mon explication t'a aidé.
Alors ça, c'est un sujet ou j'aimerais avoir un peu plus de détail, et je ne sais pas si des gens peuvent me répondre.
1) est ce que apparmor est mis par défaut ?
je vois assez souvent des gens qui ralent sur la présence de selinux ( et qui AMHA, rale à tort ), et je vois pareil pour apparmor, dans une moindr emesure, sur ubuntu. Quid de Suse ?
2) apparmor et selinux, sans policy, tu va pas très loin.
est ce qu'il y a plus de profiles que sur Ubuntu, ou des développements particuliers à ce niveau ?
Non mais j'ai vraiment réfléchi à savoir si c'était une vraie personne ou pas. Et si c'est pas quelqu'un qui existe vraiment, alors la personne derrière tout ça a vraiment fait des efforts en créant des comptes facebook, google, en posant à gauche à droite, etc.
C'est un chouia plus flippant
( sinon, je réponds car je vois que j'ai des réponses sur le tableau de bord, hein )
support Oracle : c'est un problème, mais si tu le prend à la source, il disparaît… pourquoi Oracle quand tu peux utiliser Postgresql
parce que ton soft à coté ( exemple, remedy de bmc, ou secureid de RSA, même si je suis pas sur pour celui la ) demande à avoir une db Oracle ou des tas d'autres trucs d'Oracle. Faut pas se leurrer, le standard SQL n'a que la base de standard.
Et il y a des features avancés chez Oracle qu'on a/avait pas encore sur postgresql. Même si postgresql a fait des gros progrès sur ce point depuis quelques années, la réplication n'était par exemple pas fourni de base, et il fallait passer par des projets qui n'avait l'air pas forcément pérenne ( et je me base sur le fait qu'il y avait l'air d'avoir plus une compétition commercial autour qu'une franche collaboration pour pousser ça upstream :/ ).
Et quand je lit les différents threads sur le sujet ( genre https://linuxfr.org/news/migrer-de-oracle-a-postgresql-ora2pg ), il y a l'air d'avoir encore des features vachement avancés que Oracle propose qui fait que les grandes boites vont avoir besoin de ça ( ou plutôt, préfère prendre un produit que d'avoir des ingés pointus sur le sujet vu qu'ils se font débauchés de tout les cotés ).
Ensuite, je vois aussi que plein de gens semblent avoir des expériences pas terrible avec Oracle…
Comme quelqu'un le fait remarquer, oracle, c'est plus qu'un moteur SQL, donc il faut plus chercher de ce coté la que de croire que forcément, les DSI sont idiots et incapables de choisir.
[^] # Re: Ça manque de forks, ou pas…
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Mageia 3. Évalué à 6.
c'est déjà fait, ça s'appelle le code des softs upstream. En fait, 90% de ce que tu retrouves dans une distribution est du code qui est partagé par tout le monde. Ensuite, bien sur, les gens se focalisent sur les 10% restants, n'ayant aucune idée de la chaine globale.
En fait, même pour l'infrastructure, c'est massivement mutualisé, tout le monde utilise les mêmes serveurs webs, etc, etc.
[^] # Re: HAHA
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 5.
Ben justement, c'est la question. Bien sur que c'est rapide, c'est un commentaire sur linuxfr, pas guerre et paix ( même si j'ai déjà écrit des romans en commentaire ). On peut en discuter pendant des heures, comme déjà savoir si il y a une montée ou pas.
Mais par exemple, on peut comparer avec d'autres pays de taille comparable. Est ce qu'il y a autant de choses autour de la sécurité en espagne, en allemagne ? L'allemagne a toujours eu le CCC, mais c'est pas le même public visé que Hackito Ergo Sum ou d'autres comme le SSTTIC.
Est ce que la présence du minitel ( et donc la monétisation des services qui va avec ), le fait d'avoir des accès au net pas cher ( ou plutot moins cher qu'ailleurs ) est aussi une cause de la démocratisation de l'internet, donc de la montée de la sécurité informatique en France ? Peut être.
Il est généralement reconnu que ça a fait un bond après les attentats du 11 septembre, parce que l'état américain a financé plein de projets et donc a lancé la machine économique ( et j'aurais tendance à le croire aussi ). Ensuite, une fois les deniers publiques épuisés, la technologie s'est retrouvé dans le civil, vu que la croissance du point de vue des militaire et de l'état était soit bouché, soit illégal ( ie, dictature, etc, ce qui n'a pas empêché ).
Mais ensuite, la politique sécuritaire du gouvernement sarkozy, peut être lié aussi aux retombées en occident du 11/09 n'ont pas aidé à instauré cette montée ? La loi HADOPI, le concept d'"internet civilisé", etc, tout ça, c'est aussi des choses qui ont instauré l'idée que l'internet est une source de danger et de non droit.
Et mon point, c'est pas qu'il n'y avait pas de sécurité avant, mais qu'il y a en a beaucoup plus maintenant. C'est pas une croissance faible ou un niveau constant, c'est une croissance des plus fortes. ( encore une fois, on passe de 1 conf franchouillarde par an à 4 ce trimestre ). Et ces conférences sont organisés par des personnes locales. Les gens du milieux se plaignent que le STICC est noyauté par l'ANSII et les grosses boites, mais c'est aussi parce que ces groupes ont grossis. Thales, EADS, etc, y a quoi comme équivalent à l'étranger, et est ce qu'il y a une corrélation entre la présence de grand groupe du même genre et d'un milieu de la sécurité vivace ?
Peut être qu'il y a une monté de la visibilité des crimes qui irait avec une monté de l'information disponible. Peut être qu'il y a une montée parce que les barrières à l'entrée sont plus basses, que les risques sont moindres, c'est sans doute aussi une explication. peut être qu'il y a juste une montée de la visibilité de la sécurité informatique, je sais pas.
Il y a sans doute plus d'une raison, et je ne dit pas que ma proposition est la seule cause, loin de la. La question est de savoir si c'est une cause ou pas. Ou une conséquence. Ou un hasard. Après tout, l'extrémisme politique arrive ailleurs, et pour d'autres raisons. Mais par exemple, ailleurs en europe, je ne croit pas qu'on retrouve les mêmes choses qu'en France ( ie, climat poussant à ne pas croire l'internet, tout en ayant favorisé la montée de l'internet dans les années avant via la mise en place d'infrastructure, et via des initiatives privés ( free par exemple )). Par exemple, je pense que la France est très avance sur le libre ( dans le sens ou on a beaucoup de contributeurs francais ) parce que la DST a coupé une montée des "hackers" dans les années 80, ce qui fait qu'une génération de gens se sont retrouvés à faire du libre au lieu de faire des mouvements comme le CCC comme en Allemagne. Et peut être que cette montée des libristes a permis l'arrivé de FDN, de Free, et une certaine compréhension du fonctionnement du réseau, qui a permis d'avoir plus de libristes, plus d'internet, et à la fin, plus de gens dans le milieu de la sécurité.
[^] # Re: Silent patching
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 5.
Un segfault peut aussi induire un DoS, et un DoS est un souci de sécurité. La sécurité vise à assurer la disponibilité et l'intégrité du SI entre autres choses. Si ton SI ( on va dire celui d'une agence de recrutement ) ne marche pas car un petit malin a mis un cv qui fait planté ton système, tu perds la disponibilité, don cdu pognon. Et ça, c'est pas bon(tm). Ensuite, bien sur, une elevation de privilége en root, ça fait tout de suite plus peur. "oh attention, quelqu'un va devenir root et à partir de la, envoyer du spam, ou piquer votre base de données de cv".
Curieusement, ce genre d'argument pour windows xp ne marche pas pour faire migrer les gens vers un autre OS bureautique, ce qui montre que les gens ont un modèle mentale spécifique des attaques.
[^] # Re: HAHA
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 10.
ça résume bien ce qui va pas dans le monde de la sécurité. Y a plein de pognon à se faire car le processus de décision contourne la rationalité. Le secret autour des affaires fait que les légendes urbaines et les exagérations sont légions ( suffit de voir les histoires de cyberwars ). Le cinéma fait tout pour faire rêver et faire croire que la sécurité et les ordinateurs, c'est magique et/ou compliqué et/ou tout troué. On vends aux gens de la peur basé sur justement de l'imaginaire, donc ça parle directement à un niveau moins rationnel de l'esprit.
Comme le dit Linus dans une interview cité plus haut, et comme j'ai pu le constater souvent en bossant dans le domaine et en lisant les MLs de projets, certains gens dans la sécurité sont très manichéen avec une vision tunnelisé.
Et comme il y a d'énormes ressources en jeu ( lire pognon ), il y a plein de monde et du coup, le monde de la sécurité est plus dans l'opposition et la compétition que dans la coopération, coopération qui est au coeur du logiciel libre et qui explique le clash des cultures. Et pas opposition juste quand il y a de l'argent, ce qui à la rigueur serait normal. Non opposition du style "je passe des jours à montrer qu'un bug est une faille et en plus,je passe le double du temps à contourner les systèmes de sécurité des autres pour faire une petite pique pour montrer qu'ils servent à rien".
Opposition car les "leaders" du monde de la sécurité sont souvent dans un des 2 extrêmes entre "paranoiaque et très discret", ie, on ne lit pas d'interview d'eux, voir connait pas leur vrai nom ( SolarDesigner, par exemple, même si maintenant, on connait son vrai nom ), et "grande gueule et porté sur l'obsession de la sécurité, voir l'exagération". Donc à partir de la, les grandes gueules gagnent la bataille médiatique, donc on a tendance à suivre leurs exemples. Suivre pour la vision tunnelisé, suivre dans l’exagération, voir promouvoir des gens comme expert alors qu'ils ont plus d'une fois parlé de casser AES.
Ensuite, je connais plein de gens qui ont une approche plus balancé de la sécurité, je ne nie pas leur existence. Mais eux, on ne les entends pas, ils ont pas une horde de gens prêt à reprendre leurs idées non extrémistes sur le web, donc on prends pas en compte leur point de vue.
Et enfin, la question qui se pose, c'est de savoir si c'est le milieu qui transforme les gens, ou si c'est les gens qui transforme le milieu. Et si au final, c'est une bonne chose de voir qu'en France, on a 4 conférences de sécurité international durant ce trimestre. Ou plus audacieux, est ce que la monté du front national en France et la monté de la sécurité informatique ne sont pas liés ( liés dans le sens ou "se méfier des autres" devient une idée de société prédominante )
[^] # Re: HAHA
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 3.
Je ne suis plus un professionnel du domaine, mais j'ai pris une douche, donc je m'estime un minimum propre. Parfois, si tu as une faille, tu agrdes parce que tu as pas le temps de t'en occuper. Moi, j'ai trouvé des trucs mineurs en faisant de la lecture de code, j'ai fait un rapport de bug par mail, j'attends le correctif. Depuis janvier.
Ensuite, c'est dans l'absolu, si j'avais un truc de ce genre, oui, je tenterais de faire corriger ça assez vite. Et pour ça, c'est simple, au moins pour le logiciel libre. Y a assez de gens sur la liste oss-security pour t'aider à coordonner une release du patch avec un embargo pour que ça soit fait le plus proprement sans faire trop de dégâts.
Dans le cas de spencer, chaque fois que je lit ce qu'il écrit, il est souvent agressif et/ou hautain et rarement coopératif. Et c'est en voyant ce genre de mec ( car c'est pas le seul dans le milieu ) que j'ai compris que le monde de la sécurité est mauvais pour l'équilibre psychologique des gens ( et donc que j'ai pas cherché à re bosser dans le domaine à nouveau, si c'est pour trainer avec des mecs dans son genre ( et c'est pas le seul, je précise ), je préfère devenir admin windows au tadjikistan )
Et c'est aussi en le lisant que j'ai pigé que le patch grsecurity serait sans doute jamais mergé upstream, donc jamais à l'abri d'un coup de tête du dev principal, donc à éviter pour ma part.
[^] # Re: HAHA
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 10.
C'est une question de ressources. Soit tu prends un noyau ou les gens auditent tout pour la sécurité, mais ça avance pas aussi vite que tu voudrais, voir ça vire des options que tu voudrais ( exemple, la virtualisation que l'équipe openbsd considère comme mauvaise pour la sécurité, donc ne veut pas intégré ça ). Soit tu prends un truc qui avance et ou le prix du progrès, c'est d'avoir parfois des failles.
Sinon, si tu veux une vraie équipe sécurité, y a des boites qui font leur propre OS qui paye des gens pour ça. Exemple, Apple, Microsoft, SunW Oracle mais bien sur, tu doit payer. Y a des boites qui payent aussi des équipes sécu pour le logiciel libre, genre Red Hat, Suse, Canonical, mais pareil, les revues de sécurité, ça tombe pas du ciel.
Dernière possibilité, commence à faire des revues de code en même temps que tout le reste de la lkml, lead by example, etc, etc.
Poster sur Linuxfr sans rien faire, ça va juste rien faire.
[^] # Re: C'est légal le commerce d'exploit? J'en doute
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 3.
Disons qu'on peut descendre très vite, y a que 150 messages à lire, tu peux te faire une idée.
[^] # Re: AppArmor et Selinux
Posté par Misc (site web personnel) . En réponse au journal OpenSUSE 13.1 Milestone1. Évalué à 2.
On a pas du avoir les mêmes Fedora alors :)
J'ai toujours laissé SELinux installé et activé. Je dit pas que j'ai jamais eu de popups, j'ai reporté pas mal de bugs sur la policy justement, mais je dirais pas "sans arrêt des popups". Et en général, c'était pas sur les softs installés par défaut.
Les erreurs courantes que j'ai vu avec des gens et SELinux, c'est quand tu touches à la configuration des daemons en réseau ( vu qu'il y a globalement que eux qui sont confinés ). Par exemple, tu fait tourner sshd sur un autre port sans configurer selinux pour ça. Que tu décide de mettre ton ftp dans /home/monsiteweb et que pareil, tu précises pas à SELinux que c'est des objets que apache a le droit de lire et vsftpd a le droit d'écrire, etc. ou des trucs que tu installes à la mano.
Dans la configuration par défaut, en règle général, ça passe. Et plus il y a de gens qui utilisent selinux, notamment sur les versions de dev ( genre F19 en ce moment ), plus vite la policy est corrigé. Les packageurs Fedora sont assez réactifs à ce niveau.
Et pour la question de l'utilisation plus grand public, ça dépend des risques d'attaques sur ta machine.
Tu pourrais te dire par exemple qu'un simple assistant va pas avoir de souci, mais si c'est l'assistant de la directrice générale du groupe, ça reste une cible de choix. Ensuite, out of the box, l'utilisateur bureautique n'est pas protégé par SELinux dans la policy déployé par Fedora, car ses processus tournent sans confinement même si des choses comme le fait de bloquer ptrace ( http://lwn.net/Articles/491440/ ) aident à sécuriser. Pour ce genre d'utilisateur, je pense que le confinement tel que Canonical le prévoit va servir une fois que ça sera au point.
Et sinon, SELinux est aussi la technologie qui permet d'avoir xguest ( https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Confining_Users-xguest_Kiosk_Mode.html ), et visiblement, lightdm se base sur apparmor pour son utilisateur guest. Donc il y a des avantages, même si c'est minime par rapport à tout ce qu'on pourrait faire.
[^] # Re: et quid de Ksplice ?
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 5.
Ben la doc qu'on trouve sur le web ( https://oss.oracle.com/ksplice/docs/ksplice-quickstart.pdf ) dit qu'il faut le kernel maison d'oracle :
Ensuite, la documentation est dite "outdated" ( http://kkempf.wordpress.com/2013/01/24/ksplice-another-reason-to-love-oracle-linux/ ).
Donc je pense plus que tu as le support entreprise pour le kernel maison ( ie la partie intéressante ), et que le reste est disponible grâce à une moulinette semi-automatique et moins intensivement testé et sur laquelle y a pas de garantie (notamment pour les drivers tierces). IE, que le support Fedora/Ubuntu est juste la pour servir de demo sur des machines de test afin d'attirer les clients, tout comme leur version d'essai de 30 jours pour RHEL. Bien sur, Oracle ne parle pas du fait que la version d'essai doit sans doute annuler le support RHEL.
En fait, au vu des postes de blogs ( https://blogs.oracle.com/ksplice/entry/ksplice_update_for_cve_2013 ), il semble que ksplice oblige à attendre le distributeur de base quand même, et au final, vu qu'il y a assez souvent de mesures qui vont réduire l'impact ( mitigation feature, je suis pas sur de traduire ça comme il faut ), ç'est AMHA mieux de passer par les dites features si ton but est d'être protégé vite fait. Du coup, une fois que tu es protégé sans avoir rebooté, tu as plus besoin de ksplice.
Donc oui, comme tu dit, c'est un marché de niche même si 70 clients, c'est déjà pas mal (ie, moi, je connais des boites avec moins de clients en 5 ans) et je pense que plein de gens voudraient ça (mais je connais personne qui utilise ça, alors que le support pour Ubuntu LTS est fourni).
La valorisation de la chose, suffit de voir que c'est juste fourni de base avec le support oracle. Donc ils ont fait le calcul sur le fait que vendre ça comme service, ça rapporte moins que comme "cadeau gratuit" à leur clients existants.
[^] # Re: HAHA
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 7.
Bien sur, tu prends en compte le fait que certaines failles sont justes dans les noyaux récents et que ta distro pas-rolling-release n'est pas touché ?
exemple, CVE-2013-1858 CVE-2013-1979 et CVE-2013-1959 dans le noyau 3.8 uniquement, pour ne citer que les plus récentes qui me viennent à l'esprit. Ou justement la faille dont parle le journal, qui touche pas RHEL5 ou plus vieux. Ou par exemple, CVE-2009-1527 qui touche que le 2.6.29.
Et j'ai pris juste une paire d'exploit au pif dans la liste des CVEs, j'ai peut être eu de la chance, mais je suis pas sur.
[^] # Re: et quid de Ksplice ?
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 4.
s/sans redémarrer/sans passer par le BIOS/
Ce qui est déjà pas mal, je le reconnais, mais tu ne coupes pas au reboot de l'userspace, à la perte de l'état, etc, etc.
[^] # Re: et quid de Ksplice ?
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 4.
Non, le souci n'est pas la licence (en tout cas, ça n'était pas la licence au début), le souci, c'est soit y a des limitations (genre pas le droit de toucher à la taille du code binaire sinon tu décales tout les pointeurs, pas le droit de toucher aux structures, etc, etc), soit tu es obligé de faire des grosses réécritures de la mémoire, et ton kernel est dans un sale état. En fait, quand tu vois que les devs kernels voulait retirer la possibilité de retirer les modules car c'était trop compliqué (à l'époque du 2.6, je crois), c'est bien qu'il y a quelque choses.
Donc pour mettre à jour ton kernel, tu dois "juste" changer du code, mais pour change rle code, faut le faire de tel façon que le kernel soit le même du point de vue du layout. Même si pour les failles les plus importantes, ça semble être bon d'aprés wikipedia, il semble que pour une petite partie des failles ( 12% ), il faut faire intervenir un développeur pour bidouiller la mémoire du kernel. Et bien sur, les chiffres ne parlent que de 64 failles sur 3 ans, quid des autres updates que tu voudrait aussi appliquer sans rebooter ?
Et ça, ça part du principe que tu part avec un kernel connu dont tu as le code, pas un kernel bidouillé ou avec des modules customs ou ce genre de choses. Et bien sur, chaque modif implique un patch spécifique, et chaque patch spécifique implique des tests poussés (car bon, c'est une chose de tester un soft dans un état connu contre une faille, c'est autre chose de tester un soft dans un état inconnu contre une faille et tout les emmerdes possibles, surtout face à des soucis de processeurs multiples, etc. Et tu veux pas non plus que ton update bloque le kernel trop longtemps pendant que tu fait la mise à jour, vu que le kernel est freezé le temps de magouiller tout)
Et je sais pas si tu peux enchainer les updates ksplices advitam eternam.
Donc non, en pratique, la plupart des distributions n'ont pas les ressources (en plus maintenant de plus avoir le code à jour). En pratique, Oracle n'a visiblement même pas les ressources suffisante pour faire ça sur les 2 kernels de sa distribution malgré le fait que leur distribution ne soit qu'un rebuild de l'original (ou alors, ils mentent quand ils disent qu'ils sont compatibles de façon binaire, mais Oracle peut pas jouer sur les 2 tableaux à ce niveau la). IE oracle ne propose ksplice que pour son kernel maison, celui qu'ils rebasent sur le 3.0 (vu qu'ils ont pas envie de faire des rebases peut êtrepour des questions de moyens) avec btrfs en production et supporté, voir http://www.h-online.com/open/news/item/Btrfs-ready-for-production-in-new-Oracle-Linux-kernel-1471706.html .
Ensuite, peut être que je suis mauvaise langue, c'est vrai, ksplice inc avait réussi à avoir 70 clients en 2 ans d'existence, c'est pas mal.
[^] # Re: notre vie privée n'est pas respectée ?
Posté par Misc (site web personnel) . En réponse à la dépêche Cozy, un cloud personnel que l'on peut héberger, bidouiller et supprimer. Évalué à 7.
parfois est un mot un peu faible :)
tu oublies aussi que parfois, les contrats circulent avec des formats fermés, lu par des outils proprios dont l'éditeur n'a pas forcément mis l'accent sur la sécurité ( ou du moins, pour ce format en particulier ). Voir même que pendant longtemps, les dits contrats étaient stockés sur des machines sans disque dur chiffrés.
Et pourtant, l'économie n'est pas en crise à cause du manque de sécurité informatique, plutôt le contraire, les marchands de peur arrivent très bien à s'en sortir.
[^] # Re: Quel est le risque ?
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 3. Dernière modification le 18 mai 2013 à 20:24.
Locale
On a déployé au boulot un fix basé sur systemtap, qui est d'ailleurs dans les liens :
https://bugzilla.redhat.com/show_bug.cgi?id=962792#c13
Ensuite, faut avoir systemtap sur sa distribution ( et vu que pour le moment, ça sert pas mal pour écrire ce genre de magouille, je pense que toute les distros devraient l'adopter vite fait )
[^] # Re: Silent patching
Posté par Misc (site web personnel) . En réponse à la dépêche Root exploit sur les noyaux linux 2.6.38 à 3.8.8. Évalué à 5.
C'est assez délicat de savoir si tu as un truc exploitable ou pas dans la plupart des cas. Même sur des failles simples ( genre usage de /tmp avec un nom un peu prévisible ), tu passes du temps à essayer de voir si tu as un scenario pour monter une attaque pour pas apparaitre comme celui qui dit de la merde et qui s'affole sans savoir de quoi il parle.
Et les attaques les plus simples ( genre buffer overflow ) sont de nos jours assez bien comprises et anticipés ( au moins dans le code du kernel ), donc il reste que les cas les plus compliqués qui sont dur à évaluer.
[^] # Re: Grosbill
Posté par Misc (site web personnel) . En réponse au journal Ouverture du git qy.share. Évalué à 3.
Dans les mentions légales :
http://www.grosbill.com/html/mentions_legales.shtml#gt-mentions_legales-footer
Ensuite, c'était plus pour vejmarie ( vu qu'il est président de SDS, je pense qu'il peut contacter le service commercial de Grobill pour dire "ça serait bien de corriger tel faute" sur notre produit )
[^] # Re: Grosbill
Posté par Misc (site web personnel) . En réponse au journal Ouverture du git qy.share. Évalué à 3.
Un mail au webmaster, ça peut marcher.
[^] # Re: AppArmor et Selinux
Posté par Misc (site web personnel) . En réponse au journal OpenSUSE 13.1 Milestone1. Évalué à 2.
Ah oui, c'est un exemple plus parlant que celui de l'armée :)
En fait, si tu veux avoir des relations, il faut pas juste rajouter un 3eme élément qui est considéré comme étant "hors de la politique de sécurité" et qu'on suppose être capable de décider et de suivre la politique, donc de vérifier l'intégrité ( ou dans le cas de Bell-Lapaluda, de forcer la déclassification des données ) ?
IE, dans le cas que tu donnes, un humain comme l'admin de la machine.
En fait, je réalise ( je réalise beaucoup ce matin ) qu'on utilise les dites politiques de sécurité parce qu'on fait pas confiance aux programmes pour avoir un minimum de jugement pour dire "ça, c'est louche", mais l'armée fait pareil vis à vis de ses membres, en demandant à ne pas réfléchir aux ordres mais en devant compenser ça par des politiques stricts. Au final, l'armée gère presque des machines biologiques.
[^] # Re: AppArmor et Selinux
Posté par Misc (site web personnel) . En réponse au journal OpenSUSE 13.1 Milestone1. Évalué à 3.
Capsicum est pas un LSM, sauf erreur de ma part.
Si je dois citer tout les solutions de sécurité qui vont changer le système de permission de façon conséquente, faut que je rajoute smack (utilisé par meegoo), tomoyo et sa longue histoire, les différents modules du projet trustedbsd, bitfrost (olpc), aegis (nokia n9), le modèle d'android et sans doute une paire que je connais pas (ou qui n'ont pas de petit nom).
On a beau dire "le modèle Unix est parfait et loué soit ses codeurs", refaire la liste montre bien qu'il y a quand même du monde qui cherche à l'adapter car il est totalement inadéquat (au contraire de Sheila). Et c'est sans prendre en compte le souci que xkcd résume bien: https://www.xkcd.com/1200/ , à savoir qu'il y a aussi tout le souci d'authentification sur le réseau, et la tension entre "facilité d'utilisation" et "blocage en cas de compromission".
[^] # Re: AppArmor et Selinux
Posté par Misc (site web personnel) . En réponse au journal OpenSUSE 13.1 Milestone1. Évalué à 2.
Oui, mais le souci, c'est que c'est pas activé par défaut. Le particulier en question veut être secure, mais si ça empêche des tas de choses genre "envoyer ma clé privée sur gmail pour faire un backup", ou "ne plus pouvoir utiliser firessh", il va raler :)
Je vois bien le nombre de gens (à commencer par des OEMs, donc des gens à priori techniques) qui commence par "faut désactiver selinux", c'est pas tip top.
Ensuite, les profiles de firefox/chromium ont aussi le souci de pas être aussi étanche qu'ils devraient, vu qu'il y a divers attaques sur les variables d’environnement, il y a dbus (qui n'est pas encore apparmor aware, et qui est selinux aware mais c'est pas trop utilisé), le keyring, etc. Les soucis pour le confinement d'application sont bien détaillé dans le document d'ubuntu que j'ai donné.
Mais c'est mieux que rien, je le concède.
[^] # Re: iptables + logs
Posté par Misc (site web personnel) . En réponse au message être au courant des ping reçu. Évalué à 2.
Le framework d'audit du kernel :
http://doc.opensuse.org/products/draft/SLES/SLES-security_sd_draft/cha.audit.comp.html
ça va enregistrer les modifications dans syslog, et tu peux réagir en regardant du coté de audidsp ( plus loin dans la doc que j'ai cité ).
[^] # Re: AppArmor et Selinux
Posté par Misc (site web personnel) . En réponse au journal OpenSUSE 13.1 Milestone1. Évalué à 10. Dernière modification le 18 mai 2013 à 00:13.
Alors, AppArmor et SELinux, ce sont 2 modules de sécurité du noyau (LSM, linux security module). L'idée est d'avoir des extensions du kernel pour accepter ou pas certaines opérations sur la base de critères externes ( voir ça comme un firewall pour les fonctions du kernel ).
Les LSM permettent plus que ces 2 la, mais je vais pas me disperser. Les 2 servent à appliquer des règles de qui a le droit de faire quoi plus souple que le simple modèle unix.
Ensuite, la ou ça diffère, c'est comment tu le fait. SELinux est un système de label couplé avec des règles. Tu mets un label sur les utilisateurs, sur les fichiers, sur les processus, etc, et tu écrit des règles pour régir l'interaction.
Par exemple, quelqu'un avec le label admin_u ( _u comme user ) a le droit de faire exec sur un fichier avec le label network_t ( _t comme type ), ce qui va donner un processus avec network-exec_t ( y a une regle qui dit comment les labels évoluent ). Et ce processus a le doit de faire tel ou tel chose, comme ouvrir un socket, et ainsi de suite.
Apparmor, c'est la même idée, sans les labels. IE, tu donnes direct les chemins de fichiers. Tu va dire "tel programme /usr/bin/toto a le droit de lire tel fichier, tel fichier, et faire tel opération". Par exemple, tu va dire que evince n'a pas le droit de lire ton .ssh, même si tu as le droit toi en tant qu'utilisateur de manipuler les fichiers. Si jamais un pdf contient un malware, il va pas piquer ta clé ssh.
Personnellement, je trouve SELinux plus souple, mais je suis partiel.
L'idée à la base, c'est de pouvoir confiner les processus et/ou les utilisateurs, ou de gérer des politiques obligatoires ( MAC, mandatory access control, par opposition à un DAC, discretionnary access control, qui sont les droits unix gérés par les utilisateurs eux mêmes, et donc potentiellement non conforme à ce que l'organisation veut ).
Ceci permet par exemple par une isolation des utilisateurs sur une plateforme comme openshift, ou chacun n'a accès qu'à son répertoire, ne voit pas les processus des autres ( http://www.youtube.com/watch?v=VaxkrSpBr6M pour les anglophones ), etc, à l'isolation des VMs les unes des autres ( voir libvirt et svirt http://namei.org/presentations/svirt-lca-2009.pdf , mais ça marche aussi avec AppArmor ), à la limitation des droits des applications bureautiques ( voir les propositions de Canonical sur le sujet : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement ), etc.
Il existe par exemple plusieurs projets de sandbox comme https://www.stgraber.org/category/arkose/ , http://danwalsh.livejournal.com/28545.html , etc.
L'idée est que si tu as une faille dans un processus confiné, en temps normal ( ie non confiné ), il peut faire ce qu'il veut. Par exemple, si je prends la main sur apache via une faille, j'ai l'accès d'un utilisateur non privilégié et de la, je peux rebondir, faire des connexions vers l'extérieur, lancer des programmes avec d'autres failles, lire des fichiers non protégés, etc. Avec SELinux/AppArmor, tu peux interdire de faire ça.
Ça implique d'avoir une politique de sécurité, mais justement, Ubuntu propose des politiques ( appelés profil ) pour certains démons, Fedora/RHEL/Centos propose une politique SELinux des plus complètes
A partir de SELinux, tu peux aussi mettre en place différents modèles de sécurité des données, souvent mis pour des organisations militaires :
modèle Bell Lapadula, ou grosso modo, chacun a une classification ( donc un label assigné ), chaque document a une classification ( donc un label aussi ), par exemple, public, privée, confidentiel, top secret, par ordre de criticité. Les gens avec l'habilitation privée peuvent écrire un document privée, confidentiel, et top secret, et ne peuvent lire que public et privé. Ce qui fait que l'information top secret ne va jamais devenir moins que top secret ( sauf personne non soumise à la politique de sécurité ).
modèle Biba, qui est l'inverse, ou tu as par exemple 3 classifications, soldat, colonel, général. Les gens de rangs le plus haut peuvent écrire des documents à destination des gens en dessous, mais pas les lire. Et tout le monde peut lire les documents venant d'en haut. Et ça permet donc de formaliser la chaine de commandement d'une armée, ou par exemple, tu es sur que les ordres viennent bien d'une personne au dessus de toi. Le soldat ne peux pas donner d'ordre à un colonel, mais le général peut.
Formaliser la politique de sécurité permet de s'assurer que personne ne va faire des conneries comme virer les droits top secret par erreur.
( ensuite, il faut je précise d'autres mesures pour éviter d'autres attaques )
Enfin bon, je pourrais parler de SELinux pendant des heures, un peu moins de AppArmor ( je connais moins ) mais j’espère que mon explication t'a aidé.
# AppArmor et Selinux
Posté par Misc (site web personnel) . En réponse au journal OpenSUSE 13.1 Milestone1. Évalué à 3.
Alors ça, c'est un sujet ou j'aimerais avoir un peu plus de détail, et je ne sais pas si des gens peuvent me répondre.
1) est ce que apparmor est mis par défaut ?
je vois assez souvent des gens qui ralent sur la présence de selinux ( et qui AMHA, rale à tort ), et je vois pareil pour apparmor, dans une moindr emesure, sur ubuntu. Quid de Suse ?
2) apparmor et selinux, sans policy, tu va pas très loin.
est ce qu'il y a plus de profiles que sur Ubuntu, ou des développements particuliers à ce niveau ?
[^] # Re: travailler avec debian est-il possible pour Ubuntu ?
Posté par Misc (site web personnel) . En réponse au journal Un nouveau format de paquets pour Ubuntu. Évalué à 1.
Non mais j'ai vraiment réfléchi à savoir si c'était une vraie personne ou pas. Et si c'est pas quelqu'un qui existe vraiment, alors la personne derrière tout ça a vraiment fait des efforts en créant des comptes facebook, google, en posant à gauche à droite, etc.
C'est un chouia plus flippant
( sinon, je réponds car je vois que j'ai des réponses sur le tableau de bord, hein )
[^] # Re: La question en elle même ne permet pas de répondre à la problématique
Posté par Misc (site web personnel) . En réponse à la dépêche L'État essaie d'évaluer le coût des logiciels non libres. Évalué à 5.
parce que ton soft à coté ( exemple, remedy de bmc, ou secureid de RSA, même si je suis pas sur pour celui la ) demande à avoir une db Oracle ou des tas d'autres trucs d'Oracle. Faut pas se leurrer, le standard SQL n'a que la base de standard.
Et il y a des features avancés chez Oracle qu'on a/avait pas encore sur postgresql. Même si postgresql a fait des gros progrès sur ce point depuis quelques années, la réplication n'était par exemple pas fourni de base, et il fallait passer par des projets qui n'avait l'air pas forcément pérenne ( et je me base sur le fait qu'il y avait l'air d'avoir plus une compétition commercial autour qu'une franche collaboration pour pousser ça upstream :/ ).
Et quand je lit les différents threads sur le sujet ( genre https://linuxfr.org/news/migrer-de-oracle-a-postgresql-ora2pg ), il y a l'air d'avoir encore des features vachement avancés que Oracle propose qui fait que les grandes boites vont avoir besoin de ça ( ou plutôt, préfère prendre un produit que d'avoir des ingés pointus sur le sujet vu qu'ils se font débauchés de tout les cotés ).
Ensuite, je vois aussi que plein de gens semblent avoir des expériences pas terrible avec Oracle…
Comme quelqu'un le fait remarquer, oracle, c'est plus qu'un moteur SQL, donc il faut plus chercher de ce coté la que de croire que forcément, les DSI sont idiots et incapables de choisir.