3.3 La politica di sicurezza dinamica mediante Firewall
3.3.5 Regole di accesso a classi ed oggetti
Concludiamo questa nostra analisi del meccanismo di sicurezza dinamica implementato sulle Java Card elencando tutti i controlli che vengono effettuati dalla JCVM per garantire la sicurezza di tale meccanismo.
Un oggetto o una classe vengono acceduti ogni qualvolta viene eseguito un particolare bytecode; a seconda del bytecode eseguito la Java Card VM effettua i controlli di seguito riportati:
Bytecodes interessati: getstatic, putstatic
Se il CAC è il JCRE-context allora l’accesso è consentito. Se il bytecode è putstatic ed il campo dati interessato dall’operazione è di tipo reference ed il valore da inserire nel campo dati della classe è un riferimento ad un JCRE Temporary Entry Point Object o ad un global Array, allora l’accesso è negato.
In tutti gli altri casi l’accesso è negato. 2) Accesso ad un oggetto di tipo array
Bytecodes interessati: <T>aload, <T>astore, arralength, checkcast, instanceof
Se il CAC è il JCRE-context allora l’accesso è consentito. Se l’array appartiene ad una applet del CAC l’accesso è consentito.
Se l’array è designato global l’accesso è consentito.
Se il bytecode è aastore ed il campo dati interessato dall’operazione è di tipo reference ed il valore da inserire nel campo dati della classe è un riferimento ad un JCRE Temporary Entry Point Object o ad un global Array, allora l’accesso è negato.
In tutti gli altri casi l’accesso è negato. 3) Accesso a campi di una istanza di una classe
Bytecodes interessati: getfield, putfield
Se il CAC è il JCRE-context allora l’accesso è consentito. Se il campo appartiene ad una applet del CAC l’accesso è consentito.
Se il bytecode è putfield ed il campo dati interessato dall’operazione è di tipo reference ed il valore da inserire nel campo dati della classe è un riferimento ad un JCRE Temporary Entry Point Object o ad un global Array, allora l’accesso è negato.
In tutti gli altri casi l’accesso è negato. 4) Accesso ai metodi di una istanza di una classe
Se il metodo appartiene ad una applet del CAC l’accesso è consentito.
Se il metodo è designato come un JCRE Entry Point Object l’accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.
Se il CAC è il JCRE-context l’accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.
In tutti gli altri casi l’accesso è negato. 5) Accesso ai metodi di una interfaccia standard
Bytecodes interessati: invokeinterface
Se il metodo appartiene ad una applet del CAC l’accesso è consentito.
Se il metodo è designato come un JCRE Entry Point Object l’accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.
Se il CAC è il JCRE-context l’accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.
In tutti gli altri casi l’accesso è negato. 6) Accesso ai metodi di una interfaccia condivisa
Bytecodes interessati: invokeinterface
Se il metodo appartiene ad una applet del CAC l’accesso è consentito.
Se la classe cui appartiene l’oggetto implementa una shareable interface e se l’interfaccia invocata estende una shareable interface allora l’accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.
Se il CAC è il JCRE-context l’accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.
In tutti gli altri casi l’accesso è negato. 7) Accesso ad un oggetto di tipo “eccezione”
Se il metodo appartiene ad una applet del CAC l’accesso è consentito.
Se il metodo è designato come un JCRE Entry Point Object l’accesso è consentito.
Se il CAC è il JCRE-context l’accesso è consentito. In tutti gli altri casi l’accesso è negato.
8) Accesso ad una classe
Bytecodes interessati: checkcast, instanceof
Se l’oggetto appartiene ad una applet del CAC l’accesso è consentito.
Se il metodo è designato come un JCRE Entry Point Object l’accesso è consentito.
Se il CAC è il JCRE-context l’accesso è consentito. In tutti gli altri casi l’accesso è negato.
9) Accesso ad una interfaccia standard
Bytecodes interessati: checkcast, instanceof
Se l’oggetto appartiene ad una applet del CAC l’accesso è consentito.
Se il metodo è designato come un JCRE Entry Point Object l’accesso è consentito.
Se il CAC è il JCRE-context l’accesso è consentito. In tutti gli altri casi l’accesso è negato.
10) Accesso ad una interfaccia shareable
Bytecodes interessati: checkcast, instanceof
Se l’oggetto appartiene ad una applet del CAC l’accesso è consentito.
Se la classe cui appartiene l’oggetto implementa una shareable interface e se l’interfaccia invocata estende una shareable interface allora l’accesso è consentito.
Se il CAC è il JCRE-context l’accesso è consentito. In tutti gli altri casi l’accesso è negato.
11) Accesso ad un metodo di un oggetto array Bytecodes interessati: invokevirtual
Se l’array appartiene ad una applet del CAC l’accesso è consentito.
Se l’array è designato global l’accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.
Se il CAC è il JCRE-context l’accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.
Capitolo 4
Problemi di sicurezza: il flusso
illegale di informazioni
I meccanismi di sicurezza dinamica, di cui abbiamo parlato nel capitolo precedente, non sono tuttavia sufficienti a prevenire alcuni tipi particolari di attacco alla sicurezza dell’intero sistema.
In questo capitolo ci preoccuperemo di analizzare due diverse tipologie di attacco alla sicurezza proponendo metodologie e supporti utili per la pro- grammazione sicura di applet per Java Card multi-applicative.