Selaa lähdekoodia

chapters/why_sandboxing: correction du titre et des termes employés

Alexandre Janniaux 6 vuotta sitten
vanhempi
commit
818192076a
1 muutettua tiedostoa jossa 13 lisäystä ja 12 poistoa
  1. 13 12
      chapters/why_sandboxing.tex

+ 13 - 12
chapters/why_sandboxing.tex

@@ -52,19 +52,20 @@ de ces modules, laissant à l'exécution de code arbitraire la nécessité
 d'exploiter également des failles de sandboxing et plus seulement des failles
 d'exploiter également des failles de sandboxing et plus seulement des failles
 lié au travail multimédia réalisé par VLC.
 lié au travail multimédia réalisé par VLC.
 
 
-\section{Dans la vraie vie}
+\section{Exemples d'attaques}
 
 
-Si les objectifs et besoin décrits au dessus ne suffisent pas à convaincre,
-prendre des exemples de la vraie vie permet de se persuader d'avoir besoin de
-ces mesures. L'exemple le plus connu de sandbox intrusive est celle de Chromium,
-qui s'appelle lui-même «The Most Secure Browser.» Le développement de Chromium
-est basé depuis ses commencements sur un modèle de sandbox. L'application a donc
-dès le départ été écrite avec l'isolation des modules en tête. Plusieurs
-exemples d'attaques ont été montrées, comme celle de TODO:Xxxx utilisant des
-techniques de fuzzing pour trouver un déréférencement de pointeur invalide dans
-l'optimisation Just-In-Time du moteur javascript qui tourne dans un processus
-«Renderer» plus ou moins dédié à l'onglet. Les failles peuvent ainsi toujours
-exister, mais restent confinées au contenu apportant leur exploitation.
+Si les objectifs et besoin décrits au dessus paraissemt trop thérique, il est
+possible de prendre des exemples de la vraie vie pour se convaincre d'avoir
+besoin de ces mesures. L'exemple le plus connu de sandbox intrusive est celle
+de Chromium, qui s'appelle lui-même «The Most Secure Browser.» Le développement
+de Chromium est basé depuis ses commencements sur un modèle de sandbox.
+L'application a donc dès le départ été écrite avec l'isolation des modules en
+tête. Plusieurs exemples d'attaques ont été montrées, comme celle de TODO:Xxxx
+utilisant des techniques de fuzzing pour trouver un déréférencement de pointeur
+invalide dans l'optimisation Just-In-Time du moteur javascript qui tourne dans
+un processus «Renderer» plus ou moins dédié à l'onglet. Les failles peuvent
+ainsi toujours exister, mais restent confinées au contenu apportant leur
+exploitation.
 
 
 TODO: lien
 TODO: lien