Il est tout à fait exactement que, dans les navigateurs webs, les attaques internes aux données du navigateur (cookies, scripting cross-domaine etc.) sont au moins aussi préoccupantes que les attaques contre le systèmes (exécution de code), car plus proches du domaine applicatif. Pour la même raison, elles sont plus difficiles à éviter par des mécanismes génériques; ça fait écho de la discussion sur les navigateurs dans la news sur seccomp (sandboxing dans Linux).
Cependant je trouve qu'il y a un peu de déni dans ta réaction. Certes, l'insistance des gens de Chrome sur le sandboxing a aussi des effets marketing; d'ailleurs ton message lui aussi est un message de communication, pas vraiment un message technique. Mais s'ils peuvent se permettre d'insister dessus de façon parfois exagérée, c'est parce que ce choix technique de fond est bon, et que Mozilla est à la traîne là-dessus. C'est un fait, et je trouve bien que les gens de Chrome vous mettent la pression (par des moyens qu'on peut critiquer) pour bouger sur ça : dans le fond c'est une vraie différence technique.
D'ailleurs les failles dont tu parles sont toutes des problèmes de compartimentation/isolation (même le DoS : pour gérer les attributions de ressources il faut avoir compartimenté au préalable). Dans l'architecture actuelle des navigateurs, elles ne correspondent pas forcément à des limites de processus et donc les techniques de sandboxing ne sont pas forcément utiles; par exemple si les cookies ou les objets de scripting vivent dans un espace de nommage global partagé, des attaques sont possibles. Mais dans le fond ça reste un manque de compartimentation, et des architectures différentes (par exemple le choix de multiprocessing de Chrome pour le rendu, ou pour aller plus loin une organisation plus "everything is a file" à la Plan9) pourraient rendre ça accessible aux techniques systèmes standard d'isolation.
Bref, pour moi ton message se lit comme un "ouin les gens de Chrome ils sont vilains, ils se font mousser sur leur sandboxing mais en vrai c'est pas la seule solution à tous les problèmes". Peut-être mais en attendant vous proposez quoi sur le terrain technique ? Les gens de Google poussent l'état de l'art en matière de sécurité sur les navigateurs (Google Caja, Capsicum, le travail de Mark Miller sur la standardisation de Javascript), ce ne sont pas les seuls, mais ils font du bon boulot. J'attends avec impatience que les gens de Mozilla fassent eux aussi des avancées dans le domaine, mais il faudra un peu plus qu'un simple "oui mais c'est que de la communication".
# Oui, mais
Posté par gasche . En réponse à la dépêche Quelques aspects de la sécurité qui n'ont rien a voir avec le « Sandboxing ». Évalué à 8.
Il est tout à fait exactement que, dans les navigateurs webs, les attaques internes aux données du navigateur (cookies, scripting cross-domaine etc.) sont au moins aussi préoccupantes que les attaques contre le systèmes (exécution de code), car plus proches du domaine applicatif. Pour la même raison, elles sont plus difficiles à éviter par des mécanismes génériques; ça fait écho de la discussion sur les navigateurs dans la news sur seccomp (sandboxing dans Linux).
Cependant je trouve qu'il y a un peu de déni dans ta réaction. Certes, l'insistance des gens de Chrome sur le sandboxing a aussi des effets marketing; d'ailleurs ton message lui aussi est un message de communication, pas vraiment un message technique. Mais s'ils peuvent se permettre d'insister dessus de façon parfois exagérée, c'est parce que ce choix technique de fond est bon, et que Mozilla est à la traîne là-dessus. C'est un fait, et je trouve bien que les gens de Chrome vous mettent la pression (par des moyens qu'on peut critiquer) pour bouger sur ça : dans le fond c'est une vraie différence technique.
D'ailleurs les failles dont tu parles sont toutes des problèmes de compartimentation/isolation (même le DoS : pour gérer les attributions de ressources il faut avoir compartimenté au préalable). Dans l'architecture actuelle des navigateurs, elles ne correspondent pas forcément à des limites de processus et donc les techniques de sandboxing ne sont pas forcément utiles; par exemple si les cookies ou les objets de scripting vivent dans un espace de nommage global partagé, des attaques sont possibles. Mais dans le fond ça reste un manque de compartimentation, et des architectures différentes (par exemple le choix de multiprocessing de Chrome pour le rendu, ou pour aller plus loin une organisation plus "everything is a file" à la Plan9) pourraient rendre ça accessible aux techniques systèmes standard d'isolation.
Bref, pour moi ton message se lit comme un "ouin les gens de Chrome ils sont vilains, ils se font mousser sur leur sandboxing mais en vrai c'est pas la seule solution à tous les problèmes". Peut-être mais en attendant vous proposez quoi sur le terrain technique ? Les gens de Google poussent l'état de l'art en matière de sécurité sur les navigateurs (Google Caja, Capsicum, le travail de Mark Miller sur la standardisation de Javascript), ce ne sont pas les seuls, mais ils font du bon boulot. J'attends avec impatience que les gens de Mozilla fassent eux aussi des avancées dans le domaine, mais il faudra un peu plus qu'un simple "oui mais c'est que de la communication".