Capsicum a été évoqué sur LinuxFr.org une première fois en 2011. C'est un projet de chercheurs de Cambridge concernant de nouvelles primitives de gestion des droits pour les systèmes UNIX, très prometteur et en passe d'être intégré à FreeBSD.
Voyons quels sont les mouvements autour de ce projet.
Linux n'avait à l'époque pas de bonne solution pour un sandboxing (littéralement garder dans le bac à sable) fin; en 2012, une revue complète du système seccomp (dépêche LinuxFr.org) apportait un mécanisme très fin de contrôle des appels systèmes, mais ne gérant pas le transfert de droits qui fait de Capsicum un mécanisme si complet. Seccomp avait ensuite été mentionné dans deux journaux, un journal de 2012 sur le sandboxing de Google Chrome (qui se mettait à utiliser Seccomp sous Linux, en plus d'une solution interne de passage de message; alors que la version BSD utilise déjà Capsicum), et un de cette année 2014, par Pinaraf, sur l'implémentation finale seccomp-bpf qui réutilise le Berkeley Packet Filter (qui a récemment récupéré un compilateur JIT).
Vous serez ravi-e-s d'apprendre que David Drysdale, un ingénieur Google, est en train de travailler sur un support Capsicum dans Linux. Il a déjà envoyé une première, puis une deuxième série de patches (le 30 juin, puis le 25 juillet), qui essaient différents choix techniques pour intégrer Capsicum à Linux. Il y a une bonne quantité de retours sur les patchs, du positif (ça intéresse beaucoup les gens de Chrome, dont Julien Tinnes résume les choix de design pour la sécurité dans ce fil, mais aussi les gens de QEMU, avec Paolo Bonzini qui est très en faveur de cette approche), mais aussi des critiques. Ne vous attendez pas à voir Capsicum dans la prochaine version du kernel (et même dans la suivante à mon humble avis), mais ça a l'air de bouger pas mal et si/quand ça arrive ce sera une très grande, et très bonne nouvelle.
Je note que l'équipe de sécurité de Chrome est partout dans ces discussions de bonnes idées issues du monde de la recherche. Ils ont pas mal interagi avec les chercheurs au départ, poussé Capsicum en production dans leur version FreeBSD, et sont ceux qui font le boulot pour l'intégration aussi dans le monde Linux—alors même que la compartementalisation est un sujet très en vogue avec l'explosion de popularité de Docker par exemple. On a plein de raison de râler contre Google dans le monde du libre, mais cette petite équipe fait un excellent travail de conception et d'ingénérie, qui pourrait nous apporter beaucoup à tous.
Enfin, si je peux vous parler de tout ça c'est parce que je lis attentivement Linux Weekly News, qui fait un excellent travail de vulgarisation de tout ce qui se passe autour du noyau Linux et dans le monde du libre en général. Pour les soutenir, je me suis inscrit à leur contenu pour 7 dollars par mois (il est possible de réclamer à ne payer que la moitié), et je vous encourage à faire de même si le contenu ci-dessus vous a intéressé.
Aller plus loin
- Journal à l'origine de la dépêche (324 clics)
- Site du projet Capsicum (346 clics)
# Qu'est ce qui a changé?
Posté par djano . Évalué à 10.
Je me souviens de ta premières dépêches sur le sujet et j'avais été très enthousiasmé par cette approche: très simple a utiliser par les programmeurs, ce qui pouvait vraiment aider a diffuser son utilisation et une amélioration globale de la sécurité sur nos OS.
Cependant je me rappelle que Linus avait jeté le bébé avec l'eau du bain en disant qu'il y avait suffisamment de modules de sécurité et qu'il ne voulait pas en intégrer un nouveau. C’était donc une fin de non recevoir absolument indépendante des qualités de la solution qui ne laissait entrevoir aucune possibilité d’intégration dans Linux.
J'avais été très déçu par cette fin en queue de poisson, a la hauteur de l'excitation et des espoirs qu'avait provoque cette technologie.
D’où ma question: Qu'est-ce qui ferait que le résultat sera différent cette fois-ci ?
Pourquoi Linus accepterait-il d’intégrer Capsicum maintenant ?
[^] # Re: Qu'est ce qui a changé?
Posté par MadWatch . Évalué à 2.
Question de quelqu'un qui ne connaît rien au kernel : ne serait-il pas possible d'implémenter Capsicum sous forme d'un LSM (au même titre que SELinux, AppArmor, Tomoyo…) ? Après tout les LSM ont été conçus pour ça non ? Pouvoir ajouter des mécanismes de sécurité au kernel sans impacter tout le code.
[^] # Re: Qu'est ce qui a changé?
Posté par reno . Évalué à 3.
Oui enfin Linus, par défaut il dit non et puis après il discute..
Vu le nombre de fonctionnalités qu'on doit lui demander d'introduire dans Linux, ça me parait d'ailleurs une stratégie tout à fait raisonnable!
Alors
1) les LSM ne sont pas 'stackable'/additionnable donc si tu implémente Capsicum sous forme d'un LSM alors tu aurais l'alternative d'utiliser Capsicum XOU SELinux XOU …
2) Capsicum c'est pour les devs qui veulent rendre leur logiciel plus robuste, c'est donc assez différent des politiques de sécurité qui sont plus pour les admins.
Donc si Capsicum n'est pas présent en standard, il y a peu de chance que les devs vont faire l'effort de modifier leur code pour en tenir compte.
[^] # Re: Qu'est ce qui a changé?
Posté par djano . Évalué à 3.
Tu as sans doute raison. C'est plutôt sain comme fonctionnement pour trier les gens sérieux et déterminés des gens pas sérieux.
Ça dit aussi: "quel est le cas d'utilisation?"
Je me rappelle que l'épisode Capsicum arrivait immédiatement après celui des innombrables intégrations de modules de sécurité. Linus avait vu rouge a cette occasion et avait tapé du poing sur la table ce qui avait amené a la création du framework LSM pour mutualiser les hooks de sécurité.
[^] # Re: Qu'est ce qui a changé?
Posté par tyoup . Évalué à 1. Dernière modification le 05 août 2014 à 23:26.
Si j'ai bien suivi non en finnois ça se dit utter d**n f*****g b******t, j'ai bon ?
[^] # Re: Qu'est ce qui a changé?
Posté par SalvadorDalek . Évalué à 2.
Je crois qu'il faut tout de même le dire vite. Dans le cas de SElinux, par exemple, si changer une étiquette sur un fichier, ou faire un audit2allow est tout à fait faisable pour le sysadmin lambda, rédiger un module complet de sécurisation d'une application reste une tâche très complexe qui est généralement faite plutôt en amont soit par les développeurs de l'application eux-mêmes, soit par les mainteneurs de la distribution/du paquet.
Le sysadmin de base, genre niveau RHCE, n'a pas la connaissance pour écrire efficacement des modules pour sécuriser des applications tierces avec des primitives propres pour ne pas provoquer d'effets de bord dans d'autres polices.
[^] # Re: Qu'est ce qui a changé?
Posté par gasche . Évalué à 10.
L'idée fondamentale de Capsicum est que les droits que l'on a sur un objet dépendent de la façon dont y accède et pas de l'objet lui-même: si A envoie à B une description de l'objet O, il choisit lesquels de ses droits sur O lui transférer dans cette description. Concrètement ces droits sont véhiculés par des descripteurs de fichiers (étendus avec des informations de droit d'accès et plus généralement d'appels systèmes utilisables sur l'objet pointé par le descripteur), et non les fichiers eux-mêmes. On peut avoir deux descripteurs différents vers le même objet et utiliser l'un ou l'autre qui donnent des droits différents (un peu comme en Role-Based Security à un niveau moins fin).
Cette approche d'attacher des droits aux descripteurs ne correspond pas du tout au design de LSM qui est une interface générale pour les solutions de type "mandatory access control": étant donné un sujet A et un objet O, A a-t-il le droit d'effectuer une opération donnée sur O ? C'est une façon très différente de concevoir le contrôle d'accès¹, et il n'est pas à ma connaissance possible d'implémenter Capsicum comme un module LSM --- du moins sans un surcoût important, moralement il faudrait un label différent pour chaque paire d'objet et de sujet.
Le patch actuel communique un peu avec l'interface LSM (par exemple il appelle des hooks LSM si un module de sécurité est déjà chargé), et cela lui a été reproché—on préfère une solution soit complètement dans le moule LSM, soit complètement en dehors.
¹: Capabilities: je ne connais qu'une petite partie du monde et c'est cette connaissance qui limite intrinsèquement mes droits, et que je peux transmettre. MAC: tout le monde peut parler avec tout le monde, mais un oracle externe décide d'interdire certains accès selon les identités des sujets/objets.
.
Sur l'avis de Linus : il ne s'est pas exprimé de nouveau sur ces séries de patches, donc je ne sais pas quel est son avis et s'il est toujours le même. Je crois que comme toujours les mainteneurs Linux reprochent aux gens qui veulent intégrer un gros morceau de l'extérieur de ne pas assez se reposer sur ce qui existe déjà dans le noyau, et que les premières versions des patches se font toujours rejeter pour cette raison. Je ne serais pas surpris qu'il ait senti Capsicum à l'époque comme un "gros bousin repris en bloc de FreeBSD" et réagi fortement à cause de cela—les premiers prototypes développés en 2011 avaient probablement ce défaut. Les patches actuels semblent plus Linux-centriques et ont sans doute de meilleures chances—même si rien n'est joué pour l'instant. Il s'agit d'un comrpomis à trouver, et il va certainement y avoir encore pas mal de changements.
[^] # Re: Qu'est ce qui a changé?
Posté par patrick_g (site web personnel) . Évalué à 10. Dernière modification le 04 août 2014 à 23:13.
A mon avis le fait que certaines personnes (Julien Tinnes ou Paolo Bonzini) se soient manifestés sur la LKML pour dire que Capsicum répondait à un vrai besoin est très positif pour l'acceptation par Linus et l'intégration future dans le noyau.
Linus est remarquablement constant dans ses exigences :
# Virtualisation par défaut
Posté par keyser.dyson . Évalué à 0.
Pourquoi on ne gérerait pas la sécurité via de la virtualisation légère façon conteneur ?
Chaque programme tournerait dans sa VM à lui, avec son système de fichier et une vue partielle du système global.
Ca pourrait même (surtout) marcher sous windows. On pourrait lancer n'importe quel binaire sans aucun risque. Plus besoin d'anti-virus.
Ca simplifierait aussi l'administration. Pour désinstaller un programme, on jette le fichier VM. C'est tout.
[^] # Re: Virtualisation par défaut
Posté par patrick_g (site web personnel) . Évalué à 10.
https://wiki.qubes-os.org/wiki
Mais ça ose de redoutables problèmes d'ergonomie et d'interfaces. Les logiciels ont besoin de communiquer entre eux pour être efficaces.
[^] # Re: Virtualisation par défaut
Posté par Albert_ . Évalué à 3.
Il y a aussi le problème des donnés je pense et comment tu partages sans risque entre les vm.
[^] # Re: Virtualisation par défaut
Posté par gasche . Évalué à 9.
Je pense que tu mets le doigt sur le problème qui est la "communication". La virtualisation donne une façon de séparer les processus—qui est sans doute plus robuste que des solutions internes au noyau comme les process groups, puisque la surface d'attaque est plus petite. Séparer c'est bien mais il faut aussi communiquer, et c'est sur cet aspect que les approches par capacités apportent un point de vue intéressant—qui est applicable même par-dessus des solutions à base de virtualisation, même si la réalisation technique ne sera pas exactement Capsicum.
Les applications qui peuvent être complètement séparées (le client-mail boulot et le lecteur de musique) ne posent pas de problème. La difficulté est sur celles qui doivent collaborer, par exemple le navigateur-web-boulot et le client-mail-boulot (on veut télécharger un document du web et l'envoyer ensuite par pièce-jointe). Tu ne peux pas complètement isoler ces deux processus (pour qu'ils répondent à ton besoin il faut qu'ils puissent échanger de l'information). Mais si tu te contentes de les mettre sur la même machine virtuelle, sans essayer de les protéger l'un de l'autre, tu laisses la porte ouverte à des attaques (par exemple une faille dans le décodeur PNG du browser permet d'exécuter du code arbitraire et donc de lire le carnet d'adresse du client mail). Il faut soit re-isoler au sein de la VM (en utilisant Capsicum par exemple), soit les mettre sur deux VMs mais avec des outils de partage de données entre les deux.
Pour ce partage, les solutions de virtualisation comme Qube-OS proposent des solutions spécialisées selon le type d'objet à partager (fichier, texte…); à chaque fois, le système fait une médiation entre les VMs en demandant à l'utilisateur (dans un processus privilégié) de désigner la donnée à faire traverser. Ce sont des cas particuliers de l'"approche capacités", où c'est la désignation des ressources qui contient/transmet les droits sur ces ressources. On peut donc voir Capsicum comme (une implémentation pour Linux d') une généralisation de ce mode d'échange.
[^] # Re: Virtualisation par défaut
Posté par reno . Évalué à 4.
L'approche de qube-os ne me parait pas si mal que ça: par exemple, tu mets une VM différente pour des contextes différents: une pour ton boulot, une pour tes activités perso, une pour les enfants et une autre pour les activités risquées: installation d'une appli dont tu ne sais pas trop si elle inclut un adware ou pas, etc.
Les contextes étant différent le besoin de communication entre les VMs est réduit..
Après comme le dit Michel Barret, la virtualisation ça consomme énormément de RAM et de disque, ce qui est un sacré inconvénient..
[^] # Re: Virtualisation par défaut
Posté par djano . Évalué à 2.
Pas de souci: la compartementalisation arrive a la rescousse ! ;)
[^] # Re: Virtualisation par défaut
Posté par gasche . Évalué à 7.
Oui enfin il ne faut pas se leurrer, toute méthode de sécurité comme Capsicum ou LXC/Docker qui repose sur le noyau Linux est dans la catégorie "pas secure" pour les gens sérieux, puisque la surface d'attaque est l'ensemble du noyau—c'est énorme.
Les containers ont une utilité claire pour faciliter le déploiement et l'administration, mais les utiliser pour la sécurité est inconscient aujourd'hui. Capsicum a aussi ce problème, et il faut plus le voir comme une mesure complémentaire d'autres techniques (par exemple la virtualisation) avec une surface d'attaque plus réduite mais moins expressives (genre Qube-OS), et surtout comme une façon de pousser les développeurs d'application à reconcevoir leur conception pour faciliter la compartementalisation et la sécurité—ce qui ne peut sur le long-terme qu'apporter des gains réels en sécurité, mais aussi en robustesse.
[^] # Re: Virtualisation par défaut
Posté par reno . Évalué à 3.
Je ne mettrais pas LXC/Docker et Capsicum dans la même catégorie..
Pour LXC/Docker effectivement pouvoir attaquer tout le noyau ça fait beaucoup.
Pour Capsicum, je ne sais pas si je suis d'accord, certes ça dépend beaucoup de l'application et de la façon dont elle conçue, mais en général tu restreins beaucoup ce qu'il est permis de faire ce qui complique quand même énormément la vie d'attaquant.
Ce qui est sympa avec Capsicum, c'est que les gens d'OpenSSH et de Chrome s'y intéressent et rien qu'avec ces 2 applications "capsicumisées", cela devrait apporter un réel gain en sécurité..
[^] # Re: Virtualisation par défaut
Posté par patrick_g (site web personnel) . Évalué à 3.
Ben c'est pareil avec seccomp-bpf. Mieux même puisque c'est déjà utilisé par OpenSSH et Chrome.
[^] # Re: Virtualisation par défaut
Posté par djano . Évalué à 3.
oui, mais s'il sont intéressés par Capsicum c'est que seccomp-bpf ne répond pas totalement a leurs besoins.
Je n'ai pas compris s'ils veulent remplacer l'un par l'autre ou s'ils veulent profiter de sécurités accrues.
[^] # Re: Virtualisation par défaut
Posté par barmic . Évalué à 4.
Je pense que si ces messieurs et ces dames peuvent retirer du code spécifique entre BSD et linux ils ne s'en porteraient que mieux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Virtualisation par défaut
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Un container ne sécurise pas une application codé comme les pieds ;-) Les containers et la virtualisation, c'est bien pour les serveurs mais au niveau applicatif, ce n'est pas forcément toujours une bonne idée. C'est une dérive de type Windows de faire du développement en variable globale pour moi…
Capsicum, c'est un peu la généralisation que ce qui se fait avec Postfix par exemple. Chaque application diminue ces droits sur certaines parties en fonction de ce qu'elle a besoin. La réduction des droits se fait à la source par un choix du développeur. Cela me semble une approche personnellement plein d'avenir pour les applications critiques.
[^] # Re: Virtualisation par défaut
Posté par oinkoink_daotter . Évalué à 4.
C'est surtout fait pour que s'il y a une merde, elle reste confinée au bac à sable (eg. les créations d'adobe). C'est une très bonne solution pour la gestion des applis en boîte noire. C'est donc très adapté au logiciel propriétaire mais aussi à n'importe quel projet un peu d'envergure ou l'on ne peut passer immédiatement 5/6 hommes.mois (plus les tests, c'est important et cher les tests) à adapter le contexte de chaque fonction pour voir de quels droits elle a réellement besoin, en fonction du LSM à la mode sous Linux cette semaine.
C'est quoi une dérive de type Windows ? Parce que ce genre d'interventions laisse plutôt un arrière de méconnaissance crasse de la concurrence plus qu'une bonne connaissance des fonctions que l'on a de ce côté du libre.
[^] # Re: Virtualisation par défaut
Posté par barmic . Évalué à 5.
Ouai enfin faut se détendre aussi un peu.
Capsicum n'adresse absolument pas la même problématique que les hyperviseurs et les containers. C'est pas les même personnes qui s'en servent et ils ne s'en servent pas pour faire la même chose. Tu peut détourner l'un et l'autre pour leur faire faire la même chose, mais ça ne sera pas efficace (autant d'un point de vu performance que pour le coté pratique).
Capsicum est un outil pour développeurs. Il incite assez peu à "réachitecturer" les appli parce qu'il est fait justement pour éviter de se fader des sécurités basés sur des processus (ce qui est souvent fait dans les projets OpenBSD par exemple). Par exemple avec capsicum apache httpd, peut garder mod_php en son seins, plutôt que d'utiliser une solution type (f)cgi/fpm. Tu ne pourra jamais te baser sur capsicum pour faire de lé sécurité basée sur des hyperviseurs ça n'a rien avoir.
Quant à la bagarre conteneur/hyperviseur, je ne connais pas bien les hyperviseurs, mais je me méfis des gens qui me disent que magiquement parce que c'est un hyperviseur c'est d'un coup hypersécurisé. Des failles dans les hyperviseurs ça existe aussi. C'est peut être plus sécurisé, mais je ne m'en méfierais pas moins qu'autre chose (que ce soit à cause de véritables failles, des failles liées à des configurations mal fichues, des administrations mal foutue (mauvais dimensionnement des VM par rapport aux machines physiques par exemple et hop le déni de service),…).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Virtualisation par défaut
Posté par djano . Évalué à 2.
Je parlais du souci des perfs, pas de la sécurité intrinsèque.
Je ne suis pas sur de comprendre ce que tu veux dire: Je comprend que LXC puisse ne être considéré comme pas secure. Effectivement un programme a accès a l’intégralité du noyau. Par contre je ne comprend pas ce qui pourrait être considéré comme secure. A quels systèmes penses-tu?
Capsicum me semble tout de même un bon moyen de limiter la portée des attaques sur des processus ayant les moindres privilèges. Tout ceci est module bug dans l’implémentation bien entendu, mais c'est le cas de toutes les solutions de sécurité. De toute façon si l’implémentation est foireuse peu de choses peuvent te sauver a moins d’empiler les techniques de sécurité mais alors la bonjour le surcoût de maintenance.
Bref, peux tu étayer ton propos? J'aimerai bien comprendre ce que tu veux dire.
[^] # Re: Virtualisation par défaut
Posté par gasche . Évalué à 6.
Je pense qu'aujourd'hui la sécurité d'un système utilisateur est déplorable, en raison d'une combinaison de choix de conception (du contrôle d'accès) qui ne font de chaque possibilité d'exécuter du code arbitraire une faille de sécurité globale du système (tout ce qui est donnée utilisateur est compromis), et de choix techniques (utiliser le langage C) qui font qu'on continue à avoir plusieurs failles d'exécution de code arbitraire par semaine dans des programmes que tout le monde utilise. Le principe fondamental de "moindre privilège" n'est pas respecté et en plus les outils de développement favorisent les trous.
Capsicum permet d'améliorer la conception des programmes utilisateurs pour être plus comportementalisés, et de rendre (dans les processus qui ont abandonné leurs privilèges superflus) des exécutions de code arbitraire beaucoup moins efficaces, ou plutôt sensiblement plus difficiles à exploiter (il faut aussi une faille en espace noyau). Le problème est que "plus difficile" ne veut pas dire impossible et que le modèle d'attaque aujourd'hui (et dans le futur) est très différent de celui des années 90. Ce n'est plus deux virtuoses motivés qui veulent soit se marrer soit siphonner des numéros de carte bleue, mais des criminels très riches (forcément, ça rapporte) et des agences gouvernementales qui collectionnent les attaques dans une course à l'armement ou pour faire de l'espionnage de grande échelle.
Si tu veux un système le plus sûr, la seule approche raisonnable est de supposer qu'il y a des failles partout; le nombre de bugs/failles est en gros proportionnel au nombre de lignes de code, selon un facteur qui dépend du degré de qualité de l'application (et donc du temps et de l'argent investi). Plus un système est gros, plus il a de failles; un système aussi gros que le noyau Linux a mécaniquement un grand nombre de failles; sa "surface d'attaque" est très large.
Pour la réduire, deux solutions:
- diminuer la surface d'attaque : revoir la conception du système pour restreindre la taille de la partie privilégiée (la base de confiance)
- rendre plus robuste le code de la base de confiance : audit régulier, mais surtout méthodes formelles pour prouver l'absence de la plus grande classe de bugs possible et prouver les propriétés de correction les plus fortes possibles
Aujourd'hui l'argent qui va dans le développement du kernel Linux ne va (à ma connaissance) dans aucune de ces directions, et les bénévoles ne font pas grand chose non plus. Linux est un système non-sûr, et la dynamique semble indiquer qu'il va le rester pour un bon moment.
Capsicum reste, malgré tout cela, un gain mesurable en sécurité puisque ça permet de faire passer la surface d'attaque de "absolument titanesque" (tout le code qui tourne avec les droits utilisateurs et le droit (SELinux etc.) de lire ce qui est dans mon $HOME) à juste "complètement énorme" (le noyau Linux). En plus du gain immédiat de cette réduction de surface d'attaque, il pousse les développeurs d'application à réfléchir aux privilèges dont ils ont besoin, et ça c'est un changement de culture qui peut révolutionner la sécurité des applications userland.
[^] # Re: Virtualisation par défaut
Posté par reno . Évalué à 3.
La fin pourrait être "affinée": à une partie du noyau Linux puisque tu peux restreindre les appels systèmes autorisés.
[^] # Re: Virtualisation par défaut
Posté par patrick_g (site web personnel) . Évalué à 4.
Je te propose de nous écrire une belle news sur le passage en licence libre de seL4 ;-)
http://sel4.systems/
C'est exactement ce que tu veux : un micro-noyau GPLv2 dont le code est validé par des méthodes formelles.
[^] # Re: Virtualisation par défaut
Posté par gasche . Évalué à 3.
Je fais la gueule à Sel4 parce qu'ils auraient dû donner les sources (et surtout la preuve !) dès les premières publications. Je trouve plus que discutable de ne pas l'avoir fait dès le début et, même si c'est mieux de le faire maintenant que pas du tout, je ne vais pas pour autant m'empresser de leur faire de la pub auprès du grand public.
[^] # Re: Virtualisation par défaut
Posté par djano . Évalué à 4.
J'ai cru comprendre que tu étais dans la recherche.
Je pense que la recherche en informatique devrait publier tous les codes sources ou jeux de données sous licences libres. Cela permettrait facilement de reproduire les expériences et résultats conformément a la méthode scientifique.
Actuellement, j'ai l'impression que certains papiers trichent en disant "voila ce que l'on obtient", alors qu'ils peuvent raconter n'importe quoi ou alors ils ont effectivement obtenus ces résultats mais en passant par d'autres moyens que ceux décrit dans l'article (par exemple, photoshop au lieu de l'application directe de l'algo) par manque de temps, etc.
J'en ai discute avec un chercheur et effectivement, cela soulèverait d'autres problèmes: cela prend du temps de rendre tout disponible, il faut l’héberger, ce n'est pas vraiment le boulot d'un chercheur, etc.
Qu'est ce que tu en penses?
[^] # Re: Virtualisation par défaut
Posté par gasche . Évalué à 10.
Je pense que ce sont des arguments à la con. Les gens qui ne publient pas leurs sources/données/preuves font mal leur boulot, et il est tout à fait légitime de leur reprocher.
(Par contre je fais une distinction entre "publier" et "mettre sous licence libre". Certains chercheurs insistent pour mettre des restrictions "pas d'utilisation commerciale" sur ce qu'ils diffusent, je ne suis pas de cet avis mais ça ne rentre pas pour autant dans ce que j'appelle "faire mal son boulot".)
[^] # Re: Virtualisation par défaut
Posté par barmic . Évalué à 1.
Ça c'est un aigri ou alors je ne m'y connaît pas.
Tu reproche aux gens de ne pas utiliser de méthode formelle et tu reproche aux gens de s'y mettre avec l'existant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Virtualisation par défaut
Posté par gasche . Évalué à 4.
Si ce genre de choses t'intéressent, tu peux aussi regarder le projet Bedrock; ce n'est pas présenté comme un OS, mais ça va quand même de l'assembleur à un petit serveur web, le tout entièrement vérifié (au niveau fonctionnel).
Ce qui est dommage c'est que la communauté Linux s'intéresse très peu à ces sujets-là. L'université (et l'armée) australienne a financé SeL4, Microsoft finance largement la recherche en méthodes formelles (le meilleur SMT solver vient chez eux, tout le monde s'en sert, mais il est propriétaire…), mais côté Linux, à part encourager mollement le travail sur Coccinelle et se plaindre des lint-like qui font trop de faux négatifs, il n'y a pas grand chose. Qui a essayé Cylone ou ATS ne serait-ce que 5 minutes, ou d'encoder des propriétés du kernel avec des descriptions ACSL?
[^] # Re: Virtualisation par défaut
Posté par keyser.dyson . Évalué à 0.
Parce que ce sont des bricoleurs. Ce n'est pas péjoratif pour moi.
ACSL, que tu cites, semble parfaitement utilisable et très intéressant. On pourrait même générer certaines descriptions à partir des "asserts" déjà dans le code.
J'ai vu une conférence sur sqlite. Ils font des choses assez poussées dans ce domaine mais ce n'est pas du "formel" (des tests de couverture).
En fait, il faudrait utiliser clang et LLVM pour faire des choses en automatique sur l'AST directement. Les projets dont tu parles sont antérieurs. Ca va arriver.
[^] # Re: Virtualisation par défaut
Posté par reno . Évalué à 2.
Bricoleurs? Quand tu vois la difficulté de prouver même des petits programmes..
seL4 est l'exception pas la règle et quand tu lis leur FAQ sur le multicoeur..
Par contre pour l'utilisation du C plutôt qu Ada (par exemple) là je suis d'accord.
[^] # Re: Virtualisation par défaut
Posté par gasche . Évalué à 4.
Ce que je reproche à la communauté Linux n'est pas un manque de compétences techniques, mais un manque d'intérêt pour les méthodes formelles pour le logiciel. C'est une culture qui s'acquiert, qui est présente dans certains environnement (par exemple Mozilla a fait des choses très louables dans cette direction, et surtout Microsoft a su intégrer ça étonnamment bien en production, y-compris pour le développement kernel), mais absente en grande majorité du milieu du libre—qui aurait pourtant aujourd'hui la "puissance", en terme d'argents et de ressource, pour faire des choses très intéressantes dans ce domaine.
Il y a beaucoup de choses intéressantes à faire avant d'essayer de faire des preuves de correction complètes. Par exemple, garantir l'absence de comportements indéfinis dans une partie la plus grande possible du code serait déjà un très bon pas en avant; et ACSL par exemple peut servir à spécifier ce genre de propriétés de sûreté (un pointeur reste dans la bonne région mémoire).
Les gens de Microsoft ont développé des annotations formelles pour les drivers et le code noyau, qui peuvent être vérifiées par des outils d'analyse statique. Ça demande que les développeurs acceptent de s'en servir—et il y a sans doute des faux négatifs qui sont parfois casse-pieds—mais ça marche bien et ça a eu de bons effets. Ça existe depuis une décennie environ maintenant.
Je ne comprends pas trop le sens de ta (deuxième) remarque sur le multi-cœur dans SeL4. C'est vrai que la mémoire partagée est très difficile à gérer (formellement, mais aussi quand on programme) et que l'état de l'art ne gère pas bien cet aspect là. Est-ce une bonne raison de ne pas faire d'efforts pour intégrer les outils existants dans nos pratiques de développement, là où ils peuvent apporter quelque chose ?
[^] # Re: Virtualisation par défaut
Posté par reno . Évalué à 1.
Pour seL4, ça fait 5 ans que c'est sorti et ils marquent toujours que le support du multicœur comme 'expérimental'.. Même mon téléphone est multicœur, donc je maintiens: seL4 est un jouet (à l'heure actuelle).
Pour le reste, c'est probablement une question de temps..
[^] # Re: Virtualisation par défaut
Posté par gasche . Évalué à 0.
J'ai demandé
et tu réponds
J'ai le sentiment que tu t'accroches à "bouh seL4 ne gère pas le multicœur" comme un argument pour… quoi ?
[^] # Re: Virtualisation par défaut
Posté par keyser.dyson . Évalué à 1.
C'est la même histoire que Thorvalds/Tannenbaum Linux/Minix.
[^] # Re: Virtualisation par défaut
Posté par gasche . Évalué à 2.
Mais je n'ai jamais suggéré que la communauté Linux devrait passer à des micro-noyaux (c'est un autre débat), seulement qu'elle fasse des efforts pour adopter des outils d'analyse statique et les méthodes formelles en général.
[^] # Re: Virtualisation par défaut
Posté par keyser.dyson . Évalué à 0.
Je ne retrouve plus la discussion de 1992.
Thordvalds a admis tout de suite que les micro-noyaux sont plus fiable.
Après Tannenbaum l'a piqué en lui disant qu'il n'aurait pas eu son diplôme avec lui.
Il faudrait faire tourner des moulinettes sur le code du kenrel et leurs montrer concretement les possibilités.
Avec un peu de temps, les gens seraient convaincus. Il faut "faire".
[^] # Re: Virtualisation par défaut
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Dans ce même registre, j'aurai aimé connaître ton avis sur Rust (en faisant abstraction du fait que la v1.0 ne soit pas sortie) ; il me semble qu'en ayant une bonne part de la puissance (concision/sûreté etc…) de langage comme Haskell/OCaml/Erlang tout en étant un vrai langage système (plus son concept de référence protégeant statiquement des data races par exemple), j'ai l'impression qu'une bonne part des analyses statiques sont déjà parties intégrante du langage (sans rebuter gens qui cherchent les performances brutes).
Quand les gens faisant du Rust s'appuient naturellement sur les forces du langages, dans le but d'obtenir des programmes élégants et performants, on y gagne en sécurité "gratuitement". Les programmes ne deviennent évidemment pas sécurisés par magie (la sécurité ça n'est pas que supprimer les buffer-overflows et cie), et pour le coup Capsicum ne perd aucun intérêt
Mais évidemment cela nécessite la ré-écriture des programmes, peut-être que c'est pour ça que tu évoques d'autres solutions.
[^] # Re: Virtualisation par défaut
Posté par reno . Évalué à 2. Dernière modification le 05 août 2014 à 16:28.
Oui enfin quand tu lis leur FAQ sur le support expérimental du multi-coeur par seL4, ça calme plutôt à l'heure actuelle, non?
[^] # Re: Virtualisation par défaut
Posté par djano . Évalué à 8. Dernière modification le 05 août 2014 à 16:11.
Si je te suis bien, ce que les gens de la securite considerent comme "secure", ce seraient des architecture a micro-noyaux (comme patrick_g l'indique ci-dessous). N'est ce pas?
Maintenant, je blâme régulièrement les utilisateurs/clients (c'est a dire tout le monde, nous, moi) pour la qualité des productions de l'industrie informatique, mais cela s'applique aussi bien a la sécurité: les utilisateurs choisissent les logiciels sur leurs fonctionnalités puis le prix (le moins disant) avant les autres facteurs. Ils ne s’intéressent pas du tout aux facteurs tels que performance, qualité du produit ou sécurité lors de l'achat, mais lorsqu'il y a un problème, c'est un problème totalement inacceptable qui doit être résolu pour hier. Il ne semblent pas comprendre que leurs choix initiaux entraînent presqu'inévitablement le résultat final (bugs, performances horribles, failles béantes de sécurité).
Je ne dis pas que c'est facile.
Le succès de Linux s'explique par un processus de développement ouvert et une architecture modulaire ou l'on ne paye que pour ce que l'on utilise.
Le choix du langage C a attiré beaucoup de contributeurs car c'est un langage très répandu dans la programmation système. Ceci a permis a Linux de développer sa base de développeurs malgré les faiblesses criantes du langage. C'est un choix "social".
L'architecture modulaire a permis de limiter l'impact de fonctionnalités pour ceux qui ne les utilise, d’où la grande adaptabilité du noyau a des machines très différentes: super ordinateurs, PCs de bureau, smartphones, embarque, etc.
Le succès de Linux doit beaucoup a cette combinaison de facteurs.
Une architecture micro noyau rend le développement beaucoup plus difficile (algorithmes distribues, débogage infernal, etc.), et potentiellement désastreux pour les performances si l’implémentation n'est pas correcte. Certes la sécurité est accrue, mais dans notre monde actuel, la sécurité passe après les fonctionnalités, perfs, etc.
Utiliser des méthodes formelles rend le développement bien plus compliqué et limite la base des contributeurs. A nouveau cela réduit le succès des projets utilisant ce type de technologies.
La sécurité a un coût réel, et notre monde n'a jusque la pas considéré que le coût en valait la chandelle.
J’espère que cela changera aussi bien pour ton dada (la sécurité), que pour le mien (la qualité).
[^] # Re: Virtualisation par défaut
Posté par gasche . Évalué à 7.
Je comprends bien l'argument "c'est comme ça", et c'est justement ce qui est chouette avec Capsicum : il s'agit d'un essai très honnête de faire du bon travail non pas en re-partant de zéro (facile d'avoir un bon design, mais voué à l'échec côté adoption) mais en améliorant incrémentalement l'existant. J'applaudis des deux mains, mais il ne faut pas non plus se voiler la face en s'imaginant que ça suffit—comme des gens se sont à mon avis fourvoyés pendant bien trop longtemps en pensant que other-group-user était un modèle de droits d'accès satisfaisant.
[^] # Re: Virtualisation par défaut
Posté par djano . Évalué à 3.
Je ne suis pas de ceux qui considèrent que le monde tel qu'il est est abouti ou que l'on ne peut rien y changer.
J'essaie de faire bouger les choses a ma manière.
C'est pour ça que je trouve ta vision intéressante: elle bouscule les idées en place et essaie d'amener vers autre chose.
[^] # Re: Virtualisation par défaut
Posté par keyser.dyson . Évalué à -1.
On n'en tiens pas compte encore car il n'y a pas encore assez de demande.
On ne donne de valeur que à ce qui est "rare".
[^] # Re: Virtualisation par défaut
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Je ne suis pas sur que la sécurité soit accrue alors que le développement devient beaucoup plus difficile (algorithmes distribues, débogage infernal…). Il est donc probable qu'il y ait un bogue dans ton raisonnement !
[^] # Re: Virtualisation par défaut
Posté par djano . Évalué à 2. Dernière modification le 07 août 2014 à 02:20.
Le bogue est peut être l'explication pour laquelle les micro noyaux n'ont pas percé ? ;)
[^] # Re: Virtualisation par défaut
Posté par keyser.dyson . Évalué à 1.
Merci de m'avoir fait connaitre ce projet. Il est très intéressant.
[^] # Re: Virtualisation par défaut
Posté par barmic . Évalué à 10.
Ça consomme plus de ressources (disque, RAM,…), il faut gérer la communication inter application (c'est bien d'avoir télécharger ton iso avec transmission, maintenant va la graver ou la mettre sur ton disque), pour un gain au final assez faible (tu retrouve les même problèmes que ce qu'on a actuellement et l'intégration avec l'OS doit être poussée si tu veux qu'elle soit légère).
Depuis quelques années on a plusieurs techno qui convergent vers des conteneurs efficaces (cgroup, namespace et btrfs (pour du COW) pour donner LXC et maintenant docker).
Mais c'est une problématique différente de celle du sandboxing tel qu'on le voit via capsicum, dont l'objectif est pour une application d'avoir une partie d'elle même sécurisée. Pour l'exemple de Chrome si tu met V8 (le moteur javascript) dans une VM est que le reste de Chrome y accède par réseau tu va perdre énormément en performance (parce qu'il y a toute la page à partager entre le moteur et l'interface. Ça n'est pas une solution.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Virtualisation par défaut
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
J'ai surtout l'impression qu'avoir plusieurs "racines" différentes sur une machine pourrait faire une grosse partie du job. Chroot n'est pas vraiment une bonne réponse vu le nombre de trou (montage et création des /dev/sdxx, …). En plus, il faut tout faire à la main.
Il faudrait simplement un environnement racine (pour les binaires), et que ce que voit un programme soit contrôlable (par open(), fopen(), dir…).
"La première sécurité est la liberté"
[^] # Re: Virtualisation par défaut
Posté par barmic . Évalué à 3.
Ça doit pourvoir se faire avec un LSM voir avec un namespace fs (selon ce que tu veux faire exactement).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Virtualisation par défaut
Posté par keyser.dyson . Évalué à 1.
SELinux ne fait pas ce genre de choses ?
[^] # Re: Virtualisation par défaut
Posté par djano . Évalué à 2.
Cette approche a rarement perce au niveau applicatif.
Je l'ai vu sur des terminaux types citrix ou tu accèdes a une seule application qui ne communique avec rien sur ta machine.
L'autre approche est de séparer tout ce qui est personnel de tout ce qui est pro dans les smartphones (Samsung Knox) en utilisant 2 VM séparées pour effectivement cloisonner les 2 activités et éviter que le perso n'impacte le pro.
[^] # Re: Virtualisation par défaut
Posté par keyser.dyson . Évalué à 4.
Ils font ça aussi dans Qubes OS (cité plus haut) en plus étendus.
Extrait de leur "spec":
http://files.qubes-os.org/files/doc/arch-spec-0.3.pdf
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.