Les développeurs de Google sont toujours à la recherche de solutions permettant d'améliorer la sécurité du navigateur web Google Chrome (ou son implémentation libre Chromium), ou de leur projet ChromeOS. Dans la dépêche à ce sujet, je vous avais raconté leur participation au projet Capsicum, qui apporte une gestion très fine des privilèges d'un processus, maintenant intégré dans FreeBSD.
Bien que les techniques mises en place par Capsicum soient pensées pour tous les systèmes inspirés d'UNIX, il n'y a pas grand espoir aujourd'hui qu'un port Linux soit accepté par les développeurs noyau ; Capsicum est un projet externe qu'il faudrait d'abord intégrer, ré-exprimer en terme des fonctionnalités existantes dans le noyau ; et les mainteneurs sont notoirement mécontents de la multiplication des solutions de sécurité (les Linux Security Modules en particulier) et ne verraient pas d'un bon œil l'apparition d'un nouveau candidat. Les développeurs Chromium utilisent sous Linux le primitif système de sandboxing seccomp, bien qu'il soit beaucoup moins flexible que Capsicum et donc nettement plus pénible et difficile à utiliser.
Depuis 2009, les développeurs Chrome essaient d'étendre les capacités de seccomp pour mieux répondre à leurs besoins. Les changements se sont révélés beaucoup plus difficiles à faire accepter que prévu : la situation a semblé bloquée à de nombreuses reprises et n'a pas évolué pendant de nombreux mois. Après plusieurs tentatives infructueuses, Will Drewry vient de proposer une nouvelle approche qui pourrait obtenir l'approbation des développeurs noyau ; mais rien n'est encore gagné…
Sommaire
Capsicum et le sandboxing Chrome
Les fonctionnalités du projet Capsicum peuvent se résumer en deux points clés. En activant un mode capabilities, un processus rentre dans un état où :
- Toutes les opérations (appels systèmes en particulier) qui utilisent de l'autorité ambiante (droit de désigner n'importe quel fichier, mémoire partagée…) sont interdites, à lui ainsi qu'à ses processus fils. Les opérations ne demandant pas de privilège particulier (comme le fait de forker un processus fils par exemple) restent autorisés.
- Les descripteurs de ressources, en particulier les descripteurs de fichiers, permettent d'indiquer que certaines opérations sont autorisées sur la ressource qu'ils désignent. Un programme qui crée ces descripteurs « autorisés » avant d'entrer dans le mode capabilities peut donc utiliser ces droits restants et les transmettre à d'autres programmes (en transmettant le descripteur).
Ces deux fonctionnalités permettent à un processus de choisir lui-même l'ensemble des droits/privilèges très restreints (beaucoup plus que les droits d'un utilisateur UNIX classique) pour mener à bien sa mission, et à se priver volontairement de tous les autres. Cela augmente la sécurité du système, puisque cela empêche une faille dans ce programme de causer beaucoup de dégâts — il n'a plus les droits pour le faire.
Les fonctionnalités de Capsicum ont permis aux développeurs Chrome d'implémenter la compartimentation des différents onglets du navigateur web de façon satisfaisante (sans donner plus de droits que nécessaire), en seulement une centaine de lignes.
Au contraire, la version Linux de Chrome doit se contenter des fonctionnalités de sécurité présentes dans le noyau Linux. Cela se fait en utilisant le mécanisme seccomp qui est beaucoup plus rigide : c'est du « tout ou rien », activer seccomp interdit tous les appels systèmes autres que read, write ou exit. Pour arriver à faire quand même quelque chose, Chrome doit implémenter son contrôle d'accès maison : les processus sous seccomp, quand ils veulent effectuer une action, envoient un message à un processus ayant les droits de l'utilisateur, qui vérifie que l'action est autorisée avant de l'exécuter. Cette méthode ressemble à celle utilisée par PolicyKit pour donner certains droits systèmes aux programmes utilisateurs. Mais c'est lourd à implémenter, il y a 11 000 lignes de code pour faire ça dans Chrome. Heureusement, notre orgueil de libristes est sauf, il faut environ 22 000 pour faire la même chose sous Windows.
Filtrer les appels systèmes
Pour se simplifier la vie, les développeurs Google ont proposé d'étendre seccomp pour permettre, au moment d'entrer dans le mode sécurisé, de choisir quels appels systèmes autoriser. Ils pourraient alors autoriser les appels qu'ils jugent inoffensifs, et se concentrer sur la vérification (à la main, comme avant) des cas délicats.
Après quelques discussions de conception, le 7 mai 2009, Adam Langley (Google) proposait donc un patch tout simple pour seccomp : à l'entrée du mode sécurisé, on fournit un masque de bits (bitmask) qui indique, pour chaque appel système, si oui ou non il sera autorisé.
Mais Ingo Molnar, un des principaux développeurs du noyau, avait une meilleure idée : plutôt qu'un bit oui/non, on pourrait contrôler les appels systèmes selon des filtres plus complexes, par exemple autoriser les read sur STDIN mais pas sur le reste. Il se trouve qu'Ingo avait tout récemment participé, avec moultes flamewars, à des modifications du code de tracing/monitoring du noyau (sous-systèmes ftrace et perf), qui implémentaient justement du filtrage sur les événements systèmes (compter le nombre de fois que read est appelé sur STDIN chaque seconde). Il propose donc de se baser sur les sous-systèmes de tracing pour permettre ces filtres beaucoup plus flexibles.
Remarque : pour plus d'information sur les événements de ftrace et son système de filtrage, vous pouvez regarder la documentation noyau, comme par exemple Documentation/trace/events.txt.
Cependant, cela demande du travail (beaucoup plus que le simple bitmask de départ) et tout le monde n'est pas convaincu par cette approche, donc Langley ne va pas plus avant et la modification de seccomp tombe dans l'oubli.
L'histoire avait déjà été résumée par un article LWN.net de l'époque : Seccomp and sandboxing, par Jonathan Corbet.
Le détour ftrace/perf
En janvier 2011, le développeur Eric Paris (Red Hat), qui travaille sur QEMU, s'intéresse indépendamment à seccomp ; après avoir implémenté, seul dans sa tanière, une approche par bitmask, il jette un œil à la liste de diffusion et tombe sur la discussion. Pour suivre les conseils d'Ingo Molnar, il implémente un début de filtrage dans ftrace et propose un petit patch expérimental. Il se voit répondre par des mainteneurs des systèmes de tracing (autres qu'Ingo) que ftrace n'est sans doute pas le bon endroit pour mettre de la sécurité, et que la couche LSM (Linux Security Modules) serait plus appropriée. C'est encore raté.
En avril 2011, Will Drewry (Google) revient à la charge et propose une vraie série de patchs utilisant l'approche proposée par Ingo : réutiliser le code de tracing qui a déjà des hooks sur tous les événements importants du noyau, en particulier les appels systèmes. Celui-ci est très impressionné : « j'apprécie cette approche, beaucoup plus que toutes les techniques de sandboxing que j'ai déjà rencontrées ».
La discussion sur le patch va bon train, avec en particulier des remarques sur l'implémentation du développeur (francophone) Frédéric Weisbecker, qui connaît bien les sous-systèmes de tracing. D'autres développeurs indiquent qu'ils sont intéressés par une telle fonctionnalité de sandboxing volontaire, par exemple ceux de vsftpd ou LXC. Will Drewry publie une deuxième version du patch, en intégrant les corrections demandées, mais Ingo Molnar n'est toujours pas satisfait. Will Drewry utilise le code de ftrace pour intercepter les appels systèmes et les filtrer, mais seulement en interne, il propose une interface propre. Ingo voudrait plus généralement permettre de faire des contrôles d'accès sur tous les éléments tracés, et pas seulement les appels systèmes, transformant ainsi le sous-système de tracing en une sorte de contrôle de sécurité flexible permanent.
Article LWN.net : Seccomp: replacing security modules?, Jonathan Corbet.
Will décide d'aller dans la direction demandée par Ingo mais rencontre une opposition féroce en la personne de Peter Zijlstra, co-mainteneur avec Ingo du sous-système perf, et qui refuse de mélanger tracing et sécurité. Après une belle flamewar avec Ingo, il annonce qu'il mettra son veto à toute version du patch qui utilise directement l'interface de tracing. Will propose de revenir en arrière, mais Ingo refuse : le patch utilisant l'interface de tracing est le plus court et le plus général, et donc forcément la bonne façon de faire, il refuse d'accepter une autre méthode. En juin, après neuf révisions de la série de patch, Will Drewry abandonne la bataille et admet que la situation est à nouveau bloquée.
Article LWN.net : Seccomp_filter : no clear path.
Malgré des essais de médiation de la part d'autres développeurs, et une table ronde organisée à ce sujet au Kernel Security Summit, la situation n'a pas beaucoup évolué en automne. En octobre, Łukasz Sowa, un étudiant, propose une autre méthode à base de cgroups, mais à part quelques réponses de Will Drewry il ne reçoit pas beaucoup de retours.
La nouvelle approche, par le Berkeley Packet Filter
Le 11 janvier 2012, alors que les franchouillards s'apprêtent à se ruer sur leurs forfaits Free Mobile, Will Drewry fait une opération père-noël en retard avec l'annonce d'une nouvelle approche, relativement saugrenue, pour filtrer les appels systèmes dans seccomp : réutiliser du code de filtrage des paquets réseau (Berkeley Packet Filter) !
Le BPF, qui vient du monde BSD, propose au développeur de construire des filtres sophistiqués en assemblant des petits programmes dans un langage dédié au filtrage, comprenant des tests conditionnels sur des « registres » (remplis avec les métadonnées du paquet réseau inspecté) et des sauts vers d'autres tests ou la décision d'accepter, refuser ou rediriger le paquet. Ces programmes-filtres sont interprétés par le système réseau, et même compilés vers l'assembleur dans certaines implémentations pour plus de performance. Will Drewry réutilise cette logique de filtrage, mais en remplissant les registres non pas avec les métadonnées d'un paquet réseau, mais avec le numéro et les arguments de l'appel système en cours. Plus besoin du code de filtrage de ftrace, et on peut se passer complètement du sous-système de tracing. Will Drewry doit avoir de grands espoirs que cette approche soit acceptée, car il se permet même de dire qu'après réflexion, il pense que réutiliser le tracing n'est pas une bonne idée — perdant ainsi son droit de retour en arrière.
Pour l'instant, les retours sont bons. Il y a des subtilités sur le traitement des changements de contexte, en particulier de l'appel d'exécutables setuid depuis un programme ayant des privilèges restreints. Linus Torvalds est intervenu, sans casser de sucre directement sur le travail de Drewry, ce qui est bon signe. Rien n'est encore gagné, mais il est donné d'espérer que cette approche permette l'intégration d'un mécanisme de sandbox flexible au noyau Linux.
Bien sûr, cela n'est pas directement lié à Capsicum et ça n'est pas encore aussi riche : un seccomp flexible permettrait d'empêcher le gain d'autorité ambiante, mais il n'est pas possible pour l'instant (et ce n'est pas dans le champ de vision des gens qui discutent ces patches) de transférer des privilèges dynamiquement, comme le permettent les descripteurs de fichier enrichis de Capsicum. Ça reste un excellent pas en avant pour permettre aux développeurs de limiter d'eux-mêmes le risque de sécurité et la surface d'attaque de leurs applications — ce qu'Andy Lutomirski appelle en plaisantant le « Voluntary Access Control ».
# Coquilles
Posté par Anonyme . Évalué à 2.
C’est non et non nous :)
[^] # Re: Coquilles
Posté par claudex . Évalué à 2.
Corrigé. Merci.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Et la solution serait pas simplement...
Posté par 100prout . Évalué à 3.
de laisser tomber Linux pour passer à FreeBSD 9 ? Au moins comme ça tout est réglé !
[^] # Re: Et la solution serait pas simplement...
Posté par Maclag . Évalué à 10.
On va pas changer à chaque nouvelle fonctionnalité. On a déjà migré depuis FreeBSD vers Linux pour avoir systemd y'a pas longtemps!
------------> [ ]
[^] # Re: Et la solution serait pas simplement...
Posté par 100prout . Évalué à 1.
Traitre...
[^] # Re: Et la solution serait pas simplement...
Posté par gasche . Évalué à 8.
Sous ses dehors trollesques, c'est une question qui mérite en effet d'être posée. Ce n'est pas l'avis général mais je suis personnellement convaincu que Capsicum (ou équivalent) est une fonctionnalité majeure qui pourra être amenée à de gros gains en sécurité pour les utilisateurs. C'est un atout de FreeBSD aujourd'hui (pas forcément par choix de la communauté FreeBSD d'ailleurs, il se trouve juste que les chercheurs qui travaillent sur Capsicum connaissent bien FreeBSD, et les gens de Google travaillent dessus aussi), qui contrebalance peut-être d'autres atouts du noyau Linux.
Le problème c'est que cette fonctionnalité d'abandon de privilège ne sera pas utilisée en pratique dans les applications tant qu'elle ne sera pas disponible à un minimum d'utilisateurs. C'est bien que des gens essaient de convertir lentement les couches inférieures de l'userspace FreeBSD vers Capsicum, mais pour moi les vrais bénéfices se feront sentir quand de grosses applications utilisateur, KDE ou Gnome par exemple, commenceront à l'utiliser. Et il sera difficile de justifier cet effort d'adoption dans ces communautés tant que le code sera limité à FreeBSD, et qu'il n'y aura pas de fonctionnalités équivalentes (au moins partiellement) sous Linux.
Bref, pour ce genre de fonctionnalités de sécurité, on ne peut pas raisonner dans son coin, pour en profiter vraiment il faut que le maximum de gens l'adoptent.
[^] # Re: Et la solution serait pas simplement...
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
C'est pas communautaire ça ?
[^] # Re: Et la solution serait pas simplement...
Posté par gasche . Évalué à 5.
Ce que je voulais dire c'est que c'est plus les chercheurs Capsicum qui ont poussé leur truc dans FreeBSD que les devs BSD qui ont pullé le travail de Capsicum; aujourd'hui la communauté FreeBSD découvre ce nouvel outil et se demande ce qu'elle va en faire. Enfin comme un des chercheurs Capsicum (Robert Watson) est aussi un dev. FreeBSD de longue date, les cartes sont un peu brouillées. De toute façon l'important c'est que ce soit dedans.
[^] # Re: Et la solution serait pas simplement...
Posté par reno . Évalué à 2.
Note que
1) les applications web prennent de plus en plus d'importance
2) Chrome supporte déjà Capsicum
ça fait déjà une adoption très importante..
Après bien sûr, un framework de sécurité n'est intéressant que si les applications l'utilisent.
La vitesse d'adoption de nouveauté est très variable: les outils d'analyse de consommation électrique ont fait évoluer les logiciels rapidement,
l'adoption d'XCB par GTK/Qt/EFL traîne, la sécurité est peu vendeur (la preuve: les capabilities n'arrivent que maintenant en mainstream) donc l'adoption risque d'être longue surtout quand à l'heure actuelle, elle n'est dispo que pour FreeBSD!
[^] # Re: Et la solution serait pas simplement...
Posté par gasche . Évalué à 6.
Oui mais il y a un soucis de couches d'abstractions. Les failles de sécurité dans les applications web ne sont pas forcément dans l'interaction avec les appels systèmes de l'OS hôte. Il y en a (des exécutions de code arbitraire sur des images JPEG ou quoi), mais ce n'est pas vraiment du ressort des "applications web" qui tournent dans le navigateur. Celles-ci s'inquiètent plus des attaques cross-domaines, des cookies abusifs, des failles d'injection de scripts, etc., et tout ceci ne se voit pas au niveau de Capsicum par exemple.
On peut faire des couches de sécurité inspirées des capabilities au niveau du Web. C'est ce que je fait le projet Google Caja par exemple, qui est un travail remarquable (son auteur principal, Mark Miller, fait des capabilities depuis longtemps et participe maintenant au comité Javascript). Mais c'est à un autre niveau, et il faut les deux pour être sécurisés.
[^] # Re: Et la solution serait pas simplement...
Posté par barmic . Évalué à 2.
Peut être que ce qu'il faudrait c'est que les développeurs qui sont intéressés (chez Gnome, KDE, Mozilla, Debian, RedHat, autre), le notifie de manière un peu plus prononcé histoire que les hackers du noyau se sentent un peu plus concernés (et au passage s'ils pouvaient garder la compatibilité avec ce qui est fait chez FreeBSD).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et la solution serait pas simplement...
Posté par gasche . Évalué à 6.
Les développeurs que QEMU, LXC et vsftpd se sont déjà fait entendre sur
seccomp_filter, donc je pense que le message est passé; de plus les communautés des couches supérieures sont relativement peu habituées à bosser avec le noyau ou sur les points de sécurité, donc ils ne sont sans doute pas trop au courant de ce qui se discute et des avantages que ça pourrait leur apporter.Au niveau de la "compatibilité" Capsicum, ça n'est pas envisagé pour l'instant. Les gens qui poussent
seccomp_filteront fait le choix explicite de ne pas parler de Capsicum, parce qu'un port Capsicum serait trop invasif et que les devs kernel (à raison) sont très conservateurs. Ils préfèrent pousser des amélioration incrémentales des mécanismes existants pour obtenir quelque chose d'intégré, et faire valider chaque étape. Quand on voit le mal qu'ils ont à avancer sur une fonctionnalité plus modeste, on se dit que c'était le bon choix.La question de la compatibilité pourrait être intéressante, mais le mieux pour l'instant c'est d'espérer que les fonctionnalités soient là, quelle que soit l'interface. De toute façon, adapter son code de sécurité aux différentes interfaces des différents OS, les devs Chromium par exemple sont déjà obligés de le faire aujourd'hui. Le travail sur
seccomp_filterne peut qu'améliorer leur situation -- il vaut mieux avoir avoir à maintenir deux codes différents de 100/200 lignes, plutôt qu'un code de 100 lignes et un code à 11 000.[^] # Re: Et la solution serait pas simplement...
Posté par Grunt . Évalué à -1.
Moi j'ai une autre idée pour améliorer la sécurité : utiliser un logiciel qui fait une chose, et la fait bien. Par exemple, discuter avec un client de discussion, qui reçoit un protocole destiné à ça (que ce soit IRC, XMPP, MSN..), et sur lequel il sera facile, par construction, de ne pas laisser le client "déborder" sur le reste du système et ne pas se laisser contrôler par des données bidouillées à cet effet.
Au lieu d'utiliser un "navigateur Internet" qui fait tout un tas de choses avec un protocole élargi aux forceps (HTTP), et une demi-douzaine de langages empilés dessus (javascript, Flash, java, HTML5..).
La plupart du temps, quand j'entends parler d'une vulnérabilité Web dans un navigateur que j'utilise, je m'aperçois que je ne suis pas impacté, parce que je tends à limiter mon navigateur Web à un usage "Web" et à utiliser un vrai logiciel pour faire des choses qui n'ont rien à voir. (Bon, quand t'as des idiots qui se contentent de mettre une appli Flash de chat sur un site sans fournir de lien irc:// c'est emmerdant, mais tant pis pour eux s'ils se privent de moi.)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Et la solution serait pas simplement...
Posté par gasche . Évalué à 9.
Ça ne suffit pas : il faut en plus appliquer le principe d'autorité minimale. Ton client de conversation a beau juste être un client de conversation, il va quand même faire du parsing pour afficher les messages reçus du serveur. Le code de parsing en C est propice aux buffer overflow. Statistiquement, dans ton système, il a presque toujours du code qui tourne sous ton autorité et qui contient une faille de buffer overflow, "une seule chose bien" ou pas.
Une fois que tu as une faille, la question est de savoir ce que l'attaquant peut faire avec. Avec le système de sécurité UNIX classique basé sur les droits utilisateurs, un attaquant peut faire tout ce que l'utilisateur peut faire. Donc une faille dans le code de parsing de ton serveur de messagerie peut être exploitée pour lire tes fichiers, les effacer, envoyer des messages sur le réseau comme tu le fais, etc. C'est un défaut de sécurité immense qui touche tous les systèmes d'exploitation mainstream actuel, et que l'on essaie de tempérer de l'extérieur, avec des politiques systèmes pour créer des contextes d'exécution restreint.
Bref, ces deux aspects sont indépendants: ton idée de minimiser les fonctionnalités permet de réduire la surface de vulnérabilité (en ayant simplement moins de code), mais pas le danger lié à une vulnérabilité donnée (et comme ton système reste assez gros, tu es donc en danger); permettre aux applications d'abandonner les privilèges permet, à quantité de code potentiellement buggué constant, de diminuer le danger, donc la surface d'attaque effective.
Après le design UNIX dont tu parles revient à mettre en place une forme de compartementalisation. C'est bien, car il est plus facile ensuite d'abandonner des privilèges : quand le logiciel est bien conçu, il est découpé en parties indépendantes qui correspondent à la fois aux fonctionnalités et à l'autorité nécessaire pour le fonctionnement. Donc on peut juste dire "dans tel sous-programme je me contente de tels droits", et on obtient déjà un découpage assez fin (ce qui n'est pas forcément pas vrai pour du logiciel spaghetti ou le traitement de tel ou tel aspect est éparpillé tout au long du programme).
[^] # Re: Et la solution serait pas simplement...
Posté par barmic . Évalué à 4.
C'est tout aussi utile sur des « petites » appli, c'est juste plus simple à utiliser dans celles-ci.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et la solution serait pas simplement...
Posté par Anonyme . Évalué à 2. Dernière modification le 17 janvier 2012 à 14:26.
Pour un usage "Web", tu as quand même plusieurs langages à gérer : les différents
HTML,CSS, plus tout ce qui peut-être contenu par l'élémentSCRIPT.Pour
JavaetFlash, ce sont des plugins. Est-ce qu'on les bannit aussi ?[^] # Re: Et la solution serait pas simplement...
Posté par bubar🦥 (Mastodon) . Évalué à 2. Dernière modification le 17 janvier 2012 à 15:28.
Un autre ajout (oui je suis c'est difficile de passer après vous), en fait deux :
Oui, mais cela n'enlève pas un état de fait : le navigateur est là, existe, et rempli de plus en plus de fonction pour de plus en plus de personnes. Il s'agit donc d'une politique d'usage local par un utilisateur attentif, qui n'entre pas en contradiction avec le besoin exprimé, et qui n'y apporte pas une réponse autre que locale.
On peut aussi légitimement se dire exactement l'inverse :
Que le navigateur soit le SEUL logiciel à interagir avec le réseau, considéré comme hostile par défaut. On applique alors des politiques adaptées et spécifiques à ce logiciel là. Et le bureau s'en trouve très allégé en terme de surface réseau... Perso ça me déplairait pas un bureau où aucun logiciel autre que le navigateur puisse bénéficier d'un accès réseau... Le navigateur devient "usine à gaz", certes, mais d'un autre côté quelle tranquilité...
mes 0,002 cents...
[^] # Re: Et la solution serait pas simplement...
Posté par Kerro . Évalué à 2.
Je suis assez d'accord avec toi, mais pas pour des raisons de sécurité. Plutôt pour une raison d'évidence que je ne sais pas argumenter. Un marteau pour taper, une scie pour couper, etc.
Contre exemple question sécurité: bind
Même si on peut prétendre que bind ne fait pas qu'une seule chose, il est grosso-modo dédié à un seul usage. Et pourtant, les trous, mazette !
[^] # Re: Et la solution serait pas simplement...
Posté par barmic . Évalué à 3.
Ce n'est qu'une question de granularité. Est ce que c'est le boulot du navigateur de télécharger des fichiers ? Les marque pages ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et la solution serait pas simplement...
Posté par Grunt . Évalué à 2. Dernière modification le 18 janvier 2012 à 10:03.
Ça marche mieux avec wget ça, pour diverses raisons :
Du coup, ouais, je gère mes téléchargements avec wget.
Malheureusement certains sites codés avec les pieds mettent les liens de téléchargement en javascript, ou bloquent le téléchargement si le referrer n'est pas indiqué, ou si le User Agent ne leur plaît pas.. le Web devient vraiment un gros tas de boue pénible à utiliser dès qu'on ne se contente pas de faire "Ce que le développeur du site a décidé qu'on fera". Le Web devient propriétaire dans sa façon de fonctionner. Et ça n'est pas une question de plugin, de licence, de codec MPEG ou pas MPEG. C'est une question d'usage : si le développeur d'un truc limite l'usage que j'en fais, me met des bâtons dans les roues, me dicte à moi utilisateur ce que je dois en faire, c'est propriétaire dans l'esprit.
Bon, fin du hors-sujet.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Et la solution serait pas simplement...
Posté par barmic . Évalué à 3.
J'ai tout de même un droit de réponse ?
Je le prends de toute manière.
Ma question n'était pas rhétorique. C'est un choix de l'utilisateur. Chaque utilisateur a son usage et fait ses choix.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et la solution serait pas simplement...
Posté par Grunt . Évalué à 2.
Ben justement, je critique le fait que parfois l'utilisateur n'a pas le choix, et que le Web (par rapport à d'autres protocoles) est de plus en plus conçu pour limiter ce choix. Pour, autrement dire, transformer "une ressource accessible via un certain protocole" en "une application obfusquée que l'utilisateur fait tourner dans une machine virtuelle".
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Et la solution serait pas simplement...
Posté par Anonyme . Évalué à 4.
Il y a un gros problème avec wget : il ne connait pas les cookies de ton navigateur !
Si DLFP te proposait de télécharger l’archive de tes messages, dépêche, journaux, depuis le tableau de bord, tu ne pourrai pas le faire avec wget (sauf à copier le cookie bien sûr).
À quand une libcookies commune à tous les navigateurs ?
# autre solutions
Posté par bilboa . Évalué à 2.
en meme tps on peut faire des choses un peu similaires avec selinux, rsbac, etc.
bon c'est sur c'est plus facile pour le enduser quand c'est toujours intégré au programme :-)
Il faut voir aussi que lsm c'est pas la panacée niveau framework, et que bon, ca plait pas à tout le monde la concurrence a droite et a gauche hehe
[^] # Re: autre solutions
Posté par barmic . Évalué à 2.
Par rapport aux LSM il me semble qu'il y a 2 différences importantes :
Mais l'usage de l'un n'interdit pas l'utilisation de l'autre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: autre solutions
Posté par claudex . Évalué à 6.
Ils sont plutôt complémentaires pour moi. L'administrateur système (ou la distribution) ne pense pas forcément comme le développeur de l'application. Par exemple, je peux vouloir que Chrome n'aille pas dans le dossier /Banque quoi qu'il arrive, par contre, tous les processus de Chrome ne doivent pas écrire dans /Téléchargement.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: autre solutions
Posté par gasche . Évalué à 3.
Tout à fait, et c'est ce que j'avais essayé de dire dans la dépêche Capsicum:
Comme SELinux et compagnie sont aujourd'hui les seules options disponibles, on essaie de les faire jouer sur les deux tableaux (et SELinux est assez expressif pour le faire, au moins en partie), mais dans l'absolu on veut que les deux méthodes cohabitent. Quelque chose comme Capsicum reste beaucoup plus flexible puisqu'il peut être géré directement au niveau de l'application (qui sait à partir de quand elle n'a plus besoin de certains droits, par exemple, sans transition observable par une politique MAC), et les transferts dynamique de droits du style capabilities (pas (encore?) permises par
seccomp_filterpar contre) sont à une granularité encore plus fine, qui serait difficile à codifier par MAC (déjà pas facile à administrer).# Prendre son temps pour bien faire
Posté par NanoTech . Évalué à 5.
On peut se plaindre que des possibilités qui semblent techniquement correctes au premier abord, ont été refusées, mais il faut savoir qu'une fois une API de l'espace utilisateur est définie, la politique du noyau oblige à la conserver définitivement, sauf exception rare (p.e. sysctl(2) pourrait être supprimée). Donc, une erreur de design est conservée définitivement (p.e. dnotify). Mieux vaut donc réfléchir à deux ou quatre fois avant d'implémenter quelque chose.
[^] # Re: Prendre son temps pour bien faire
Posté par barmic . Évalué à 6.
On a tout de même énormément de chance qu'il y ai des gens vachement motivés et qui ne souffrent pas d'un égo surdimentionné contrairement à certains « gros » hackers du noyau (bourrés de qualité par ailleurs). Quand tu vois que les deux mainteneurs de perf/ftrace demandent des solutions opposés et ne veulent pas entendre parler de l'autre solution, on se demande comment trouver la motivation de continuer (évidement un salaire est une source de motivation comme une autre ;) ).
Très franchement la dernière solution ne me plaît pas. À mon sens il faudrait sortir BPF du sous système réseau et faire en sorte que le sous système réseau, seccomp et les traçage (perf/ftrace) se basent dessus. Ainsi il n'y a plus de dépendance entre seccomp et le traçage ni entre seccomp et le réseau. Et ils bénéficient tous d'un système cohérent entre eux et performant pour définir des « pointcup » (oui je sais je réutilise la terminologie de programmation par aspect mais je ne sais pas comment l'appeler autrement) dans le noyau.
Vous attendez mon patch ? …
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Prendre son temps pour bien faire
Posté par reno . Évalué à 2.
Bah tu es trop optimiste, il y a beaucoup de gens intéressés par améliorer le noyau Linux, donc parfois ça finit par rentrer ok, mais il y a aussi des fonctionnalités très, très intéressantes qui ont été rejetée, et qui n'arriveront peut-être jamais dans le noyau..
Un exemple: une "synchronisation" entre le gestionnaire de mémoire virtuelle et un GC, ce qui permet d'avoir le bénéfice du swap même avec un GC: gain de performance potentiellement très important..
Ceci dit, ces super-fonctionnalités, j'ignore quel était la maturité de leurs demandes d'inclusions: les fonctionnalités ne sont pas tout, il y a la maintenabilité du code, de l'API aussi..
[^] # Re: Prendre son temps pour bien faire
Posté par r_p . Évalué à 1.
des "pointcut" plutôt :)
[^] # Re: Prendre son temps pour bien faire
Posté par barmic . Évalué à 2.
Mon clavier a fourché toutes mes excuses.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Prendre son temps pour bien faire
Posté par gasche . Évalué à 4.
Certes, et le but de la dépêche n'est pas de râler sur les développeurs noyaux. Par exemple je pense que Zijlstra a bien fait de mettre son veto sur le tracing, d'ailleurs même Drewry en est aujourd'hui convaincu.
On a quand même de la sympathie pour ce dernier quand il se retrouve coincé entre deux mainteneurs qui émettent des avis si contradictoires. Tout le monde était frustré, je pense, par les blocages sur cette fonctionnalité qui pourrait devenir très importante -- je suis amusé de voir que je suivais l'histoire en parallèle avec Jonathan Corbet, on pourrait presque croire que la dépêche est une traduction des articles LWN.net correspondants.
# De l'intérêt côté Ubuntu
Posté par gasche . Évalué à 7.
Je viens de tomber sur ce rapport de bug qui indique qu'il y a de l'intérêt pour cette fonctionnalité du côté de la Ubuntu Server Team. C'est assez logique puisqu'ils essaient de renforcer leur offre "Cloud", et la sécurité de la compartementalisation (ici de LXC) est importante. On retrouve des développeurs qui ont participé à la discussion sur la mailing-list du noyau, Serge Hallyn et surtout Kees Cook.
# Dommage
Posté par fweisbec . Évalué à 2.
Très bon article.
C'est dommage qu'on ne se soit pas penché un peu plus sur la solution ftrace/perf. Il y a avait vraiment quelque chose à faire de ce côté là. Passer par l'interface de ftrace ou perf est probablement une mauvaise idée effectivement mais par contre son infrastructure de filtrage pouvait tout à fait être réutilisée.
Avec ça on pouvait introduire une nouvelle classe de hooks indépendante du tracing qui permettait, selon le filtrage défini, de rejeter ou non un syscall. Et ça pouvait également s'appliquer à des évènements autres que les syscalls, donc les possibilités étaient vraiment intéressantes.
Enfin bon. Je ne connais pas cette solution à base de filtres BPF, mais j'espère qu'elle fournira autant sinon plus de flexibilité.
[^] # Re: Dommage
Posté par gasche . Évalué à 5.
Dans son premier mail BPF, Will Drewry explique longuement pourquoi il pense que ftrace/perf n'est pas l'endroit adapté. Je t'invite à aller lire son explication qui est très complète. Sa conclusion :
[^] # Re: Dommage
Posté par fweisbec . Évalué à 0.
Oui mais son argumentation concerne surtout l'usage du tracing pour implémenter seccomp. Et là je suis d'accord, c'est plutôt une mauvaise idée.
En revanche créer une nouvelle classe de hooks, parallèle aux tracepoints mais uniquement pour la sécurité et qui serait basée sur l'infrastructure de filtrage du tracing (qui peut être rendue générique pour ce genre de besoin), ça aurait pu être intéressant.
Ca avait été discuté un peu sur LKML mais malheureusement ça n'a pas pris...
# euh je ne suis pas certain d'avoir compris
Posté par polo77 . Évalué à 1.
Bonjour à tous,
Avant de me clouer les mains à la croix du rtfm, je suis ce projet depuis quelques temps http://theinvisiblethings.blogspot.com/ .
Nous somme tous (enfin presque) conscients du fait que les sandbox sont potentiellement plus sécurisante, Cependant une(voir plusieurs) question(s) se pose(nt) (pour l'utilisateur que je suis) vous pouvez m'appeler mme Michou.
ça va se traduire par quoi/comment. ?
confiance aveugle vis à vis du noyau? ou alors :
.bashrc -RW-R--R--R--X-rw-r--x-w-x-r.....R.......X....RW... (image non représentative du bash vue par un néophyte)
L'admin que vous êtes comprends et gères, mais pour le ''enduser'' ça se passe comment?
Une autre question :
la sandbox des app: est elles en rapport avec émulateurs wmware/virtualbox/ ou que sais-je encore ? ça fait pas un peut beaucoup de ram tout ça ?
sortez vos clous j'ai prévenu ma femme que l'affaire stigmata n'était pas un mythe urbain...
[^] # Re: euh je ne suis pas certain d'avoir compris
Posté par gasche . Évalué à 6.
seccomp_filterpermet à une application de dire au noyau : "à partir de maintenant, je n'ai plus besoin de l'appel système ; si je l'appelle par mégarde (par erreur ou parce qu'un utilisateur malicieux me pousse à le faire), interdis-le s'il te plaît, pour m'empêcher de faire des bêtises". En fait c'est plus fin que ça, il peut dire "je vais utiliser cet appel mais seulement sous telle et telle condition, le reste tu me l'interdis".C'est le développeur de l'application qui insère ces appels à seccomp, donc qui décide d'abandonner certains de ses privilèges. S'il se trompe et en fait l'application avait bien besoin de cet appel, l'appli va planter; mais ça c'est un bug qu'il va (on espère) repérer pendant le développement. Dans le cas normal, les droits sont limités mais personne ne s'en rend compte, puisque l'application n'essaie pas de les utiliser de toute façon. Et si on repère un bug ou une faille de sécurité dans le logiciel après cet abandon, on a une meilleure idée de ce qui peut se passer, et surtout de ce qui ne peut pas se passer : une tranche entière de "mauvais comportement" est exclue. Par exemple si l'application abandonne son droit à lire le système de fichier (sauf /tmp), on sait que le bug n'autorisera pas un attaquant à lire mes fichiers de configuration.
L'utilisateur lambda n'a même pas besoin de savoir que cette protection existe. Il en entendra seulement parler quand il lira "une faille a été détectée dans libpng, sous Windows elle permet l'exécution de code arbitraire, mais sous Linux ou FreeBSD elle est inoffensive car à cet instant le processus de rendu n'a plus aucun droit".
[^] # Re: euh je ne suis pas certain d'avoir compris
Posté par reno . Évalué à 1.
Ahem, pour que l'exemple que tu donne soit réaliste il faudrait que toutes les applications qui utilisent libpng utilisent une sandbox correctement ce qui est peu réaliste.
Donc en théorie ça ne change rien: il faut mettre à jour le système rapidement, mais en pratique ça peut changer beaucoup de chose car si ton webbrowser et ton filebrowser sont tous les deux "sandboxisés" correctement et bien comme ce sont les applications que tu utilises 99% du temps, le risque que tu sois affecter par la faille est très, très inférieur.
[^] # Re: euh je ne suis pas certain d'avoir compris
Posté par gasche . Évalué à 4.
Non, l'abandon de privilège peut être fait au sein de
libpng, de façon purement locale. Par exemplelibpngpourrait choisir de forker un thread pour parser les headers (opération notoirement sensible aux buffer overflow comme tout ce qui touche aux chaînes en C) qui, à la naissance, abandonne tous ses privilèges sauf celui de renvoyer des données correspondant au header sur un pipe pour son papa. Une faille de sécurité dans ce code de parsing de headers sera donc probablement sans danger¹.Je n'aime pas trop le mot "sandbox" car il fait penser à un changement de contexte à un coup, qu'on peut utiliser quelque part une seule fois et c'est fini. L'abandon de privilège de capsicum ou seccomp_filter est composable, peut se répéter pour s'affiner encore. Si les tâches qui utilisent libpng ont déjà abandonné une partie de leurs privilèges pour la partie de leur travail qui appelle libpng, c'est tant mieux, mais dans tous les cas libpng peut se re-compartimentaliser en interne, pour gérer les droits restants avec une granularité plus fine.
¹: dans le sens où une exécution de code arbitraire ne sera pas possible; par contre un attaquant peut injecter le header qu'il veut, et parier sur un bug ensuite de traitement du header. C'est à regarder avec soin, mais le gain de sécurité lié à l'abandon de privilège reste très important (on passe de "hop avec une image craftée je peux te pousser à formater ton /home/foo" à quelque chose de beaucoup moins dangereux dans le cas courant).
[^] # Re: euh je ne suis pas certain d'avoir compris
Posté par barmic . Évalué à 2.
Une confiance aveugle dans le noyau et le logiciel (comme c'est déjà le cas).
Un système à base d'ACL étendues comme tu le montre, ça existe déjà depuis longtemps avec les LSM (SELinux pour le plus anciens). C'est quelque chose que tu peut configurer tu peut interdire à ton éditeur de texte d'accéder au réseau d'ouvrir les fichiers autrement qu'en mode « append ». Bref la sécurité et déléguée à l'administrateur.
Ici il s'agit de quelque chose de plus dynamique. Ce ne sont pas des règles qui s'appliquent à un fichier, mais à un thread à partir d'un certain moment. Un navigateur peut se forker pour créer un processus par onglet, un autre pour gérer l'interface et garder un processus pour gérer tout ce petit monde. Le développeur pourras définir des autorisation particulières pour chaque processus, alors qu'ils sont tous issu du même binaires et sont donc tous impactés par les même règles de LSM.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: euh je ne suis pas certain d'avoir compris
Posté par oinkoink_daotter . Évalué à 3.
QubeOS est (en gros) un habillage un peu sexy autour de la virtualisation d'un système invité en utilisant Xen. Le domaine 0 fait tourner X et un window manager restreint. Les applis sont groupées par des labels propres au niveau de confiance que leur accorde l'utilisateur (bank, work, internet, whatever). Chaque label se traduit par une instance d'un OS linux (une fedora) dans lequel on fait tourner lesdites applis. Ca n'utilise pas de label à proprement parler au sens SELinux ou Solaris TX. X11(et/ou le wm?) est patché pour afficher autour de la fenêtre un bandeau de couleur pour indiquer le label dont la fenêtre de l'appli dispose. Le copier/coller est patché pour péter un avertissement lorsque l'on tente de copier coller d'un label à l'autre.
Toute la sécurité repose sur le fait que l'on cloisonne l'accès aux données par la virtualisation. Si une appli est vérolée elle ne peut accéder qu'aux données qu'on veut bien donner à la VM qui la fait tourner, elle et les autres applis du même 'label'.
C'est fondamentalement différent de la technique de sandboxing au niveau appli via setcomp qui est beaucoup plus fin et évoluer mais beaucoup plus complexe à auditer (QubeOS nécessite d'auditer les fonctions de cloisonnement de Xen via VT-x, setcomp, en gros tout le noyau linux). En outre seccomp nécessite la collaboration du développeur de l'appli qui doit dire ce que fait son appli (au sens appel système) et ce qu'elle ne doit pas faire.
Je ne sais pas si je suis tres clair ...
# Comportement de ftrace
Posté par Anonyme . Évalué à 3.
Je prend le risque de poser une question tellement bête que ça va devenir un mème.
Au vu de la documentation, Ftrace semble tracer les appels avant coup (ou sinon je ne comprends pas comment il aurait pu être réutilisé pour filtrer les appels systèmes). Si c'est bien le cas, permet-il de récupérer la valeur de retour de l'appel système (succès, errno) ?
[^] # Re: Comportement de ftrace
Posté par fweisbec . Évalué à 5.
C'est pas du tout une question bête.
Pour chaque syscall il y a un tracepoint à l'entrée qui renseigne sur ses paramètres et un tracepoint en sortie qui informe sur la valeur de retour.
Si ta distro est suffisamment récente, tu devrais les trouver dans /sys/kernel/debug/tracing/events/syscalls/
Les tracepoints d'entrée commencent par sys_enter et ceux de sortir sys_exit
[^] # Re: Comportement de ftrace
Posté par Anonyme . Évalué à 2.
Ah merci. J'étais allé voir là, et les traces n'indiquaient pas de points d'entrée et de sortie.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.