Ecco la seconda parte sulla sicurezza in Java. dopo accurate riflessioni ho ritenuto molto più importante trattare prima dei permessi dei programmi standalone contenuti nel file java.policy che trattare crittografia asimmetrica, impronte ecc... Argomenti che verrano cmq rimandati più avanti.
L'argomento che affronterò ora saranno, come li chiamo io, i "grant" o come si chiamano normalmente i file di policy.
Sono dei blocchi di codici contenuti appunto nel file java.policy situato in JAVA_HOME/jre/lib/security  (JAVA_HOME è la radice della vostra JDK naturalmente, tipo C:\jdk1.5_3)

ora vi posto il file in questione fornito di default da Sun e lo analizzeremo:

---------------------------
// Standard extensions get all permissions by default

grant codeBase "file:${{java.ext.dirs}}/*" {
    permission java.security.AllPermission;
};

// default permissions granted to all domains

grant {
    // Allows any thread to stop itself using the java.lang.Thread.stop()
    // method that takes no argument.
    // Note that this permission is granted by default only to remain
    // backwards compatible.
    // It is strongly recommended that you either remove this permission
    // from this policy file or further restrict it to code sources
    // that you specify, because Thread.stop() is potentially unsafe.
    // See "http://java.sun.com/notes" for more information.
    permission java.lang.RuntimePermission "stopThread";

    // allows anyone to listen on un-privileged ports
    permission java.net.SocketPermission "localhost:1024-", "listen";

    // "standard" properies that can be read by anyone

    permission java.util.PropertyPermission "java.version", "read";
    permission java.util.PropertyPermission "java.vendor", "read";
    permission java.util.PropertyPermission "java.vendor.url", "read";
    permission java.util.PropertyPermission "java.class.version", "read";
    permission java.util.PropertyPermission "os.name", "read";
    permission java.util.PropertyPermission "os.version", "read";
    permission java.util.PropertyPermission "os.arch", "read";
    permission java.util.PropertyPermission "file.separator", "read";
    permission java.util.PropertyPermission "path.separator", "read";
    permission java.util.PropertyPermission "line.separator", "read";

    permission java.util.PropertyPermission "java.specification.version", "read";
    permission java.util.PropertyPermission "java.specification.vendor", "read";
    permission java.util.PropertyPermission "java.specification.name", "read";

    permission java.util.PropertyPermission "java.vm.specification.version", "read";
    permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
    permission java.util.PropertyPermission "java.vm.specification.name", "read";
    permission java.util.PropertyPermission "java.vm.version", "read";
    permission java.util.PropertyPermission "java.vm.vendor", "read";
    permission java.util.PropertyPermission "java.vm.name", "read";
};
---------------------------

Conoscendo Java o altri linguaggi simili si avrà capito la struttura di un blocco di grant, essenzialmente è:

grant  _parametri_ {
permission _tipo-permesso_  _target_ _azione_;
};

Prendiamo per esempio:

grant codeBase "http://www.pierotofy.it/-" {
permission java.io.FilePermission "${/}file.txt", "read, write";
};



Parafrasando il codice prima so ottiene praticamente:

"Garantisci al dominio http://www.pierotofy.it/ e incluse le sotto cartelle di tutti i livelli(sepcificato con -) il permesso FilePermission con azione di lettura e scrittura sul tafget file c:\file.txt"

s invece facciamo un

grant {
permission java.util.PropertyPermission "java.version", "read"
permission java.io.FilePermission "${/}file.txt", "read";
permission java.net.SocketPermission "127.0.0.1:1111-", "listen" signedBy "netarrow"
permission java.io.FilePermission "${/}file.txt", "read, write, delete" signedBy "netarrow";
};

Tutto il codice potrà leggere la proprierà java.versione e leggere file.txt(${/} è un separatore di directory indipendente dalla piattaforma), se il codice è firmato da netarrow(come eseguire firme digitali, certificati e inserire nel keystore verrà illustrato in altre guide) può eseguire listen sul host locale sulla porta 1111, inoltre può leggere, scrivere e cancellare file.txt.

Volendo il signedBy può essere inserito all'inizio:

grant signedBy "netarrow" {
permission java.net.SocketPermission "127.0.0.1:1111-", "listen";
permission java.io.FilePermission "${/}file.txt", "read, write, delete";
};

E volendo si possono anche inserire sia il codeBase e il signedBy:

grant signedBy "netarrow", codeBase "http://www.google.it/-" {

Per quanti  riguarda i file e i path i caratteri speciali sono_

- (il trattino meno) dice di includere anche le sotto directory ed è ricorsivo, quindi include le sottodirectory delle sottodirectory e così via

*  uguale a quello sopra, ma NON è ricorsivo, quindi include sono le directory immediatamente sotto a quella indicata

${carattere o variabile} tutto cià che sta fra il dollaro e le due parantesi verrà trattato come una variabile, quindi se io faccio: ${{java.ext.dirs}} verà inserita nella stringa il vaore di java.ext.dirs, ovvero il path in cui si trovano le librerie di Java non standard e che sono così dette estensioni.

Questi sono i fondamentali, rimando alla documentazioni per approfondire.

Dopo questa introduzione potete sbizzarrirvi a dare e togliere permessi al codice Java, ad esempio... io il provider crittografico di Sun non lo sopporto, infatti ho installato il bouncy caste ma per farlo ho dobuto togliere quello di Sun(che non fa andare altri provider se non certificati, anche questo non mi andava giù); togliendolo io non posso più vedere quella finestrella che viene quando un applet è firmato e vuole uscire dalla SundBox... secondo voi come faccio per la chat del sito?

grant codeBase "http://www.pierotofy.it/-" {
permission java.security.AllPermission;
};

Mi raccomando, io ho dato tutti i permessi perchè conosco chi ha fatto la chat, in altri casi consiglio sempre di concedere lo stretto necessazio... inoltre quando avete un programma standalone in Java ricordatevi CHE GLI VENGONO ACCORRDATI TUTTI I PERMESSI quindi se un programma in Java vuole fare cose altamente rischiose nessuno gli dice di no, ma VOI potete dire di no cambiando i permessi in anticipo... ;-)

Bene, spero di aver fatto chiarezza su una parte della sicurezza di java, devo dire un argomento molto interessante, invito tutti coloro che volessero fare un sistema di sicurezza a hoc vada sulla documentazioni ad approfondire.

Disponibile sul forum e via email naturalmente.