Par exemple tu mentionnes les debordements de tampons ("buffer overflow"). Selon les cas, un bug de ce type peut:
- soit permettre l'execution de code arbitraire, auquel cas les bonnes vieilles techniques dites ASLR et DEP (liens dans mon journal) limitent les possibilites d'y parvenir mais pas a 100%, et le sandboxing limite les possibilites pour du tel code d'agir sur le reste du systeme mais comme il y a deja plein de choses a manger a l'interieur du sandbox, c'est pas forcement un probleme pour l'attaquant.
- soit conduire a un bete plantage, ce qui est un cas de deni de service, et la non plus aucune des techniques envisagees n'est utile.
C'est vrai que les techniques d'isolation ne peuvent pas transformer une faille de sécurité en non-bug: un bug reste un bug et dégradera toujours localement la qualité du service. Cependant une compartementalisation assez fine peut souvent limiter les nuisances possibles; par exemple si un composant plante, on peut souvent faire un choix par défaut raisonnable et le relancer, sans mettre en danger l'ensemble du système; de même si la granularité est assez fine les "choses à manger" ne présentent pas de risque (par exemple on ne veut pas qu'une exécution arbitraire de code dans le code qui affiche des images puisse accéder aux mots de passe stockés en mémoire par le gestionnaire de clés du navigateur).
soit permettre aux scripts d'acceder en lecture ou en ecriture a de la memoire arbitraire, auquel cas aucune des techniques mentionnees ci-dessus n'est utile!
Si justement, une isolation assez fine (pour cela il faut de l'information sur quels scripts correspondent à quels principaux) permet de faire tourner des parties du système avec des droits restreints, et donc en particulier d'utiliser des protections mémoires pour éviter ces difficultés; un compartiment donné pourra accéder à et corrompre la mémoire qui lui est propre, mais si l'architecture est bien pensée on a seulement un échec local du compartiment, ou injection de résultats faux (ce qui peut contaminer les compartiments communicants en provoquant des erreurs de leur côté, ce qui est bien sûr toujours possible, mais c'est un cas plus rare).
[^] # Re: 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é à 3.
C'est vrai que les techniques d'isolation ne peuvent pas transformer une faille de sécurité en non-bug: un bug reste un bug et dégradera toujours localement la qualité du service. Cependant une compartementalisation assez fine peut souvent limiter les nuisances possibles; par exemple si un composant plante, on peut souvent faire un choix par défaut raisonnable et le relancer, sans mettre en danger l'ensemble du système; de même si la granularité est assez fine les "choses à manger" ne présentent pas de risque (par exemple on ne veut pas qu'une exécution arbitraire de code dans le code qui affiche des images puisse accéder aux mots de passe stockés en mémoire par le gestionnaire de clés du navigateur).
Si justement, une isolation assez fine (pour cela il faut de l'information sur quels scripts correspondent à quels principaux) permet de faire tourner des parties du système avec des droits restreints, et donc en particulier d'utiliser des protections mémoires pour éviter ces difficultés; un compartiment donné pourra accéder à et corrompre la mémoire qui lui est propre, mais si l'architecture est bien pensée on a seulement un échec local du compartiment, ou injection de résultats faux (ce qui peut contaminer les compartiments communicants en provoquant des erreurs de leur côté, ce qui est bien sûr toujours possible, mais c'est un cas plus rare).