Verso le Secure Shareable Interface Object

Verso le Secure Shareable Interface Object

Un importante sviluppo del lavoro svolto potrebbe essere ottenuto pensan-do di aggiungere le funzionalità offerte dal nostro meccanismo di rile-vazione di flusso illegale (a seguito di particolari catene di chiamate a metodi condivisi che formano un ciclo) direttamente nel JCRE, ad esempio sotto forma di un nuovo tipo di Shareable Interface Object - delle Shareable Interface Object sicure che potremmo pensare di denominare SSIO (Secure Shareable Interface Object) - in grado di non consentire, per particolari metodi, il formarsi di cicli di chiamate innestate a Shareable Interface.

Il vantaggio che si otterrebbe da questa soluzione sarebbe quello di mettere direttamente a disposizione del realizzatore di applet metodi del JCRE-context in grado di garantire lo stesso livello di sicurezza offerto dai nostri accorgimenti precedentemente illustrati.

La garanzia quindi di non poter effettuare cicli di chiamate innestate a metodi condivisi sarebbe direttamente controllata dal JCRE e non richiederebbe al programmatore l'aggiunta di strutture dati e codice necessario per preservare servizi da flussi illegali di informazioni.

Per poter realizzare il nuovo tipo di controllo dinamico sui metodi condivisi occorrerebbe definire le seguenti strutture dati nel JCRE:

r    Un campo denominato PreviousActiveContext (PAC) che, affiancando il CAC, permetterebbe di implementare correttamente i controlli necessari ad impedire cicli di chiamate innestate a metodi condivisi;

r    Una nuova interfaccia condivisa denominata Secure Shareable Interface (SSI) ovvero una interfaccia che ha la proprietà di segnalare al JCRE di applicare una serie di controlli di accesso più restrittivi di quelli attualmente previsti dal JCRE, al fine di evitare cicli di chiamate innestate a metodi condivisi per questo nuovo tipo di interfaccia.

Occorrerebbe inoltre definire due nuove versioni dei metodi Applet.get-ShareableInterfaceObject() e JCSystem.getAppletShareableInterface-Object() che potremmo denominare rispettivamente Applet.get-SecureShareableInterfaceObject() e JCSystem.getAppletSecure-ShareableInterfaceObject() in grado di ritornare un riferimento al SSIO anzichè un riferimento al SIO.

Infine occorrerebbe definire un nuovo blocco di regole di accesso da ag-giungere agli 11 blocchi visti nel capitolo 3, al fine di garantire l'impos-sibilità che avvengano cicli di chiamate innestate a metodi condivisi.

Ecco di seguito i blocchi di regole da aggiungere al JCRE:

Accesso ai metodi di una interfaccia condivisa sicura (SSI)

Se il metodo appartiene ad una applet del CAC l'accesso è consentito.

Se il PAC è il JCRE-context l'accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.

Se il PAC coincide con il contesto del metodo che si vuole invocare 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.

r    In tutti gli altri casi l'accesso è negato.

Accesso ad una interfaccia  Sicure Shareable (SSI)

Se l'oggetto appartiene ad una applet del CAC l'accesso è consentito.

Se il PAC è il JCRE-context l'accesso è consentito. Viene effettuata una commutazione di contesto al contesto del metodo invocato.

Se il PAC coincide con il contesto del metodo che si vuole invocare 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.

r    In tutti gli altri casi l'accesso è negato.

In figura 6.1 è illustrato un possibile schema di funzionamento del JCRE modificato applicato al caso di studio esaminato nei capitoli precedenti, mentre nella tabella 6.1 sono illustrati, per ciascuna invocazione di metodo condiviso, i controlli imposti dal JCRE.

Nella colonna "< 1"  della tabella 6.1 vengono riportati i valori di PAC e CAC quando ancora l'invocazione del metodo logFull di AirFRanceApplet non è stato ancora effettuata.

Come è possibile notare, a ciascuna chiamata a metodo condiviso, rap-presentata nella Figura 6.1 mediante freccia numerata, è dedicata una colonna della Tabella 6.1 (che riporta come intestazione proprio il numero della freccia con cui la chiamata è stata rappresentata). Questa colonna, oltre a riportare i valori che PAC e CAC avevano prima della chiamata in esame, riporta i controlli effettuati dal JCRE che debbono essere superati per rendere effettiva la chiamata al metodo condiviso.

É facile notare come per le chiamate n. 1 (chiamata a logFull di AirFrance-Applet) e n. 4 (chiamata a getBalance di RentaCarApplet), poichè sono SI, si applichino le note regole di accesso, mentre per  le chiamate n. 2 (chia-mata a getTransaction da AirFranceApplet) e n. 5 (chiamata al metodo getTransaction da RentaCarApplet), poichè sono SSI, si applichino le nuove regole di accesso proposte.

Concludiamo osservando come il nuovo sistema di controllo degli accessi ipotizzato riesca effettivamente ad individuare e fermare il flusso illegale di informazioni (l'accesso a getTransaction da RentaCarApplet è non consentito come illustrato nella colonna 5 della Tabella 6.1).

Figura 6.1 : Meccanismo di interazione tra applet con SSI

Tabella 6.1 : Controlli svolti dal JCRE per l'accesso a metodi condivisi