Scurit des participants

1
Sous projet II Sandboxing et certification
de résultats
2
Participants

• George Bosilca (doctorant)
• Franck Cappello (CR CRNS)
• Adberhamanne Djilali (doctorant)
• Gilles Fedak (doctorant)
• Cecile Germain (MC Univ. PXI)
• Vincent Néri (IE)

3
Sécurité des ressources
Exécution de programmes en P2P
PC agressif
Internet ou LAN
Même un code dont lorigine est certifiée peut
être attaqué ! Comment garantir la sécurité
des ressources ? (le code utilisateur ne doit pas
pouvoir corrompre une ressource )
code agressive
Ressource dexécution
Sandboxing du code à exécuter
Exécution dun byte code Java ou .net dans
par une machine virtuelle
Exécution dun code binaire Dans un environnement
de confinement
4
Performance/pérennité des codes Byte code Java
ET Natif
Bytecode vs Natif
1311,84
1) Performance
1000
322,78
291,82
Conditions du test Pentium 4 1,7 Ghz 256Mo.
Linux 2.4.2 SciMark2.0 5 noyaux numériques.
187,98
100
82,46
56,17
151,8
20,78
15,09
18,48
17,04
16,69
12,92
12,77
10
3 Générations de JVM Sun Jdk 1.2.1 gtcompilation
à la volée Sun Jdk 1.3.1 gt hotspot Sun Jdk
1.4 IBM Jdk 1.3 gt -JIT Sélectif
6,36
6,55
5,98
5,87
5,55
5,51
5,5
Temps (sec)
4,74
4,63
3,32
3,41
3,85
3,69
3,76
3,64
bbbbbb
5,55
4,55
3,86
1,87
1,44
2,87
2,8
1
0,78
1,35
0,62
0,1
CG
EP
FFT
SOR
MC
MatMul
LU
Linpack
Avec le byte code, les performances dépendent
fortement de la machine virtuelle disponible sur
le Worker Meilleures performances du code natif
(écart peu significatif pour qq benchs)
2) Compatibilité avec les codes existants
Beaucoup de codes (et surtout en numérique)
existent en Fortran et C Beaucoup dapplications
propriétaires ne sont disponibles quen exécutable
5
Confinement de codes natifsSandboxing
PC agressif
Internet ou LAN
Fournir une sandbox pour confiner lexécution des
applications
code agressif
Ressource dexécution
Linux Security Module (immunix, NSA Linux)
Ptrace (subterfugue, User mode Linux, Janus)
Application
Appel système
Noyau
hook
Appel système vérifié par un module de sécurité
6
Résultats Performances comparées JVM Versus
codes natifs sandboxés
Pentium 4 1,7 Ghz, 256 Mo, Linux 2.2.4 Sun JVM
1.4.0
Benchmark Sandbox de code natif
120
105
100
99,4
85,7
100
80
60
du temps d'exécution
45
43
40
20
0
Sans securité
LSM
Subterfugue
UML

• Java plus performant pour les read/write
• Coût dinterposition LSM nul (mais actuellement
  sans vérification)

7
Certification de résultats
Ex Problème du calcul De la FFT de SETI_at_home
Cas de corruptions -Volontaire sur PC
client -Involontaire sur PC client
Comment détecter les corruptions -le
collecteur de résultats ne peut pas se fonder sur
lauthentification et le cryptage des
communications -Il doit pouvoir détecter les
erreurs en utilisant seulement lanalyse du
résultat une fois reçu
8
Certification de résultats
Approches pour la détection de corruption (aussi
appelées tolérance au sabotage)
Utilisateur (ou application)
Système
-Exécution redondante vote à la
majorité -Vérification ponctuelle (choix
aléatoiredun serveur et exécution dune
tâcheau résultat connu et vérifiable) -Combinaiso
n du vote à la majoritéet de la vérification
ponctuelle Approche fondé sur la
crédibilitéCrédibilité du Worker (augmente
avecle nombre de VP positives),Crédibilité du
résultat (augmente avecle nombre de résultats
concordants)
-Analyse statistique des grandes Populations sur
paramètres Caractérisant les résultats -Analyse
statistique (application Monté-Carlo
), -Résultats vérifiables simplement une
complexité ltlt calcul(ex solution dun systèmes
déq.) -Applications tolérante aux résultats de
faîble qualité ou aux fautes ponctuelles (films
en images de synth.)
9
Planning
Etude Sandbox
Etude certification
Réalisation proto
Réalisation proto
Expérimen tation
Expérimentation
t0
t012
t024
t036
t06
t018
t030

• Demande détachement pour Cécile Germain au CNRS
  avec comme sujet la certification (Globus) à
  partir de Septembre 2002
• PostDoc