Hosting Tomcat
I provider che supportano gli standard web di Java, cioè servlet e pagine JSP, nella quasi totalità dei casi basano le loro soluzioni su una qualche versione di Tomcat, configurato in modo che sia condiviso fra più utenti e web application. Questa modalità operativa è sicuramente la più economica, dato che un’istanza di Tomcat in genere è avida di risorse (sia memoria che CPU), senza contare che se si avesse un’istanza per utente si arriverebbe velocemente alla saturazione del server, senza per questo avere evidenti benefici dal punto di vista delle prestazioni.
Come possiamo immaginare utilizzare un Tomcat condiviso ha enormi ricadute dal punto di vista della sicurezza: pensate a cosa succederebbe se un’applicazione si mettesse ad eseguire codice arbitrario, come modifiche di variabili di sistema, o addirittura lo shutdown del server!
Configurare il Security Manager
Per fortuna Tomcat eredita dalla piattaforma Java un meccanismo molto versatile di “messa in sicurezza” del codice, il cosiddetto Security Manager. Esso consiste in un file con estensione .policy che indica a quali classi, package o metodi si ha accesso all’interno della JVM. Il file di policy di default fornito con Tomcat è conf/catalina.policy
Avviare tomcat sotto security manager è un’operazione molto semplice, è sufficiente lanciare il server con l’opzione -security:
[bash]$CATALINA_HOME/bin/catalina.sh start -security (Unix)
%CATALINA_HOME%\bin\catalina start -security (Windows)[/bash]
Test in locale
Attivare il security manager non è affatto una semplice operazione del tipo “attivalo e dimenticalo”, perché una volta attivato la nostra applicazione (e qualsiasi libreria utilizzata) non avrà più accesso ad alcune funzionalità che in un ambiente di sviluppo “domestico” diamo quasi per scontate! È quindi necessario testare a fondo l’applicazione con una configurazione di sicurezza il più possibile simile a quella di produzione.
I pacchetti di hosting di Artera consentono di attivare il supporto alle JSP in modalità condivisa, le modifiche al file di policy sono le seguenti (aggiornate ad Agosto 2010):
[bash]// Required for JNDI lookup of named JDBC DataSource’s and
// javamail named MimePart DataSource used to send mail
permission java.util.PropertyPermission "java.home", "read";
permission java.util.PropertyPermission "java.naming.*", "read";
permission java.util.PropertyPermission "javax.sql.*", "read";
// OS Specific properties to allow read access
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";
// JVM properties to allow read access
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 "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";
// Required for OpenJMX
permission java.lang.RuntimePermission "getAttribute";
// Allow read of JAXP compliant XML parser debug
permission java.util.PropertyPermission "jaxp.debug", "read";
// Precompiled JSPs need access to this package.
permission java.lang.RuntimePermission
"accessClassInPackage.org.apache.jasper.runtime";
permission java.lang.RuntimePermission
"accessClassInPackage.org.apache.jasper.runtime.*";
// Precompiled JSPs need access to this system property.
permission java.util.PropertyPermission
"org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER", "read";[/bash]
Queste righe vanno a sostituire quelle presenti nella sezione WEB APPLICATION PERMISSIONS all’interno di catalina.policy, all’interno di un unico “grant”:
[bash]// ========== WEB APPLICATION PERMISSIONS =====================================
// These permissions are granted by default to all web applications
// In addition, a web application will be given a read FilePermission
// and JndiPermission for all files and directories in its document root.
grant {
[….] <=== queste righe vanno sostituite
}[/bash]
E se non funziona?
Purtroppo non sempre le web application funzionano senza problemi sotto security manager. I problemi maggiori sono dovuti solitamente dalle librerie, sviluppate senza tener conto di un possibile utilizzo in ambienti con restrizioni, ma non è raro trovare anche nel proprio codice chiamate a metodi “proibiti”.
In alcuni casi sarà possibile apportare delle modifiche alle librerie: se si tratta di librerie open source, se si ha molto tempo a disposizione e se sono particolarmente facili da modificare… condizioni decisamente rare! In tutti gli altri casi bisognerà necessariamente passare ad un pacchetto di hosting superiore, come un server dedicato (virtuale o meno), dove sarà possibile configurare con molta libertà ogni parametro di funzionamento e dedicare l’intero Tomcat alle proprie applicazioni, senza doversi preoccupare delle restrizioni del security manager.
Link
- documentazione ufficiale del Security Manager (Tomcat 5.5).
- Permissions in the Java™ SE 6 Development Kit (JDK)
