Este cap�tulo presenta dos t�picos de seguridades adicionales que podr�amos encontrar interesantes.
�Applets Firmados
Se puede definir un fichero de polic�a para requerir una firma de todos los applets o aplicaciones que intenten ejecutarse con el fichero de polic�a. La firma es una forma de verificar que el applet o la aplicaci�n vienen de una fuente fiable y que puede ser cre�ada para ejecutarse con los permisos concedidos por el fichero de polic�a.
Si un fichero de polic�a requiere una firma, un applet o una aplicaci�n pueden obtener el acceso concedido por el fichero de polic�a s�lo si tienen la firma correcta. Si el applet o la aplicaci�n tienen una firma err�nea o no tienen firma, no obtendr�n el acceso al fichero.
Esta secci�n muestra un ejemplo de firma de una applet, verificaci�n de esa firma, y ejecuci�n del applet con un fichero de polic�a.
�Ejemplo del Applet Firmado
El fichero de polic�a para conceder accesos puede configurarse para que requiera o no una firma. Si se requiere una firma, el applet tiene que est�r envuelto en un fichero JAR antes de poder ser firmado. Este ejemplo muestra c�mo firmar y conceder los permisos a un applet para que pueda crear un fichero demo.ini en el directorio Home del usuario cuando se ejecuta en el AppletViewer.
Estos ficheros son los usados en el ejemplo. Podemos copiarlos o crearlos en nuestro directorio de trabajo.
- El fichero SignedAppletDemo.java que contiene el c�digo del applet.
- Write.jp fichero de polic�a que concede los accesos al directorio home del usuario.
- Una etiqueta Applet embebida en un fichero SignedApplet.html.
<applet code="SignedAppletDemo.class" archive="SSignedApplet.jar" width=400 height=400> <param name=file value="/etc/inet/hosts"> </applet>
Normalmente un applet se envulve y se firma mediante un desarrollador de intranet y es manejado por el usuario final que verifica la firma y ejecuta el applet. En este ejemplo, el desarrollador de intranet performa los pasos 1 al 5, y el usuario final realiza lo pasos del 6 al 8. Para mantener las cosas sencillas todos los pasos ocurren en el mismo directorio.
- Compilar el Applet.
- Crear el Fichero JAR.
- Generar las Claves.
- Firmar el Fichero JAR.
- Exportar el Certificado de Clave P�blica.
- Importar el Certificado como Certificado Verdadero.
- Crear el Fichero de Polic�a.
- Ejecutar el Applet.
�Desarrollador de Intranet
El desarrollador de intranet, envuelve el ejecutable del applet en un fichero JAR, lo firma y exporta el certificado de la clave p�blica.
�1: Compilar el Applet
En su directorio de trabajo el desarrollador de intranet, usa el comando javac para compilar la clase SignedAppletDemo.java. La salida del comando javac es el SignedAppletDemo.class.
�2: Crear el Fichero JAR
El desarrollador de intranet almacena el fichero SignedAppletDemo.class compilado en un fichero JAR. La opci�n -cvf del comando jar crea un nuevo archivo (c), usando modo verboso (v), y especifica el nombre del fichero archivado (f). El nombre del fichero es SignedApplet.jar.
jar cvf SignedApplet.jar SignedAppletDemo.class
�3: Generar las Claves
Un fichero JAR se firma con la clave privada del creador del fichero JAR y la firma es verificada por el receptor del fichero JAR con el clave p�blica de la pareja. El certificado es una sentencia del propietario de la clave privada indicando que la clave p�blica de la pareja tiene una valor particular para que la persona que la est� usando puede estar segura de que es aut�ntica. Las claves p�blica y privada deben existir en el almacen de calves antes de que se puede usar jarsigner para firmar o verificar la firma de un fichero JAR.
El desarrollador crea un base de datos keystore llamada compstore que tiene una entrada para cada pareja de claves recientemente generadas con la clave p�blica en un certificado usando el comando keytool.
En su directorio de trabajo, el desarrollador crea una base de datos keystore y genera las claves.
keytool -genkey -alias signFiles -keystore compstore -keypass kpi135 -dname "cn=jones" -storepass ab987c
Este comando keytool -genkey invoca una pareja de claves que est�n identificadas con el Alias signFiles. Subsecuentes llamadas al comando keytool que usar�n este alias y la password (-keypass kpi135) para acceder a la clave privada en el par generado.
La pareja de claves generadas se almacena en un base de datos keystore llamada compstore (-keystore compstore) en el directorio actual y accedida con la password del compstore (-storepass ab987c).
La opci�n -dname "cn=jones" especifica un nombre distinguido X.500 con un valor de nombre com�n (cn). X.500 Distinguished Names identifica entidades para certificados X.509. En este ejemplo, el desarrollador usa su �ltimo nombre, Jones, para el nombre com�n. Podr�a haber usado cualquier otro nombre para este prop�sito.
Podemos ver todos las opciones y par�metros de ketool tecleando.
�4: Firmar el Fichero JAR
JAR Signer es una herramienta de la l�nea de comandos para firmar y verificar la firma de ficheros JAR. En su directorio de trabajo, el desarrollado usa jarsigner para firmar una copia del fichero SignedApplet.jar.
jarsigner -keystore compstore -storepass ab987c
-keypass kpi135
-signedjar
SSignedApplet.jar SignedApplet.jar signFiles
Las opciones -storepass ab987c y -keystore compstore especifican la base de datos keystore y password donde se almacena la clave privada pra firmar el fichero JAR. La opci�n -keypass kpi135 es la password de la clave privada, SSignedApplet.jar es el nombre del fichero JAR firmado, y signFiles es el alias de la clave privada. jarsigner extrae el certificado desde la base de datos cuya entrada es signFiles y lo adjunta a la firma del fichero JAR firmado.
�5: Exportar el Certificado de la Clave P�blica
El certificado de la clave p�blica se env�a con el fichero JAR al usuario final que usar� el applet. Esta persona usa el certificado para autentificar la firma del fichero JAR. Un certificado se env�a exportandolo desde la base de datos compstore.
En su directorio de trabajo, el desarrollador usa keytool para copiar el certificado desde compstore a un fichero llamado CompanyCer.cer de esta forma.
keytool -export -keystore compstore -storepass ab987c -alias signFiles -file CompanyCer.cer
Como el �ltimo paso, el desarrollador coloca el fichero JAR y el certificado en un directorio de distribuci�n o en una p�gina web.
�Usuario Final
El usuario final descarga el fichero JAR desde el directorio de distribuci�n, importa el certificado, crea un fichero de polic�a concediendo los accesos al applet, y ejecuta el applet.
�6: Importar el Certificado como Certificado Verdadero
El usuario descarga SSignedApplet.jar y CompanyCer.cer a su directorio home. Ahora debe crear un abase de datos keystore (raystore) e importar el certificado en ella usando el aplias company. El usuario usa keytool en su directorio home para hacer esto.
keytool -import -alias company -file
CompanyCer.cer -keystore
raystore -storepass abcdefgh
�7: Crear el Fichero de Polic�a
El fichero de polic�a concede al fichero SSignedApplet.jar firmado por el alias company permiso para crear demo.ini (y no otro fichero) en el directorio home del usuario.
El usuario crea el fichero de polic�a en su directorio home usando policytool o un editor ASCII.
keystore "/home/ray/raystore";
// A sample policy file that lets a program
// create demo.ini in user's home directory
// Satya N Dodda
grant SignedBy "company" {
permission java.util.PropertyPermission
"user.home", "read";
permission java.io.FilePermission
"${user.home}/demo.ini", "write";
};
�8: Ejecutar el Applet en el AppletViewer
AppletViewer conecta con documentos HTML y los recursos especificados en la llamada a appletviewer, y muestra el applet en su propia ventana. Para ejecutar el ejemplo, el usuario copia el fichero JAR firmado y el fichero HTML en /home/aURL/public_html y llama al Appletviewer desde su directorio ra�z de esta forma.
appletviewer -J-Djava.security.policy=Write.jp http://aURL.com/SignedApplet.html
Nota: Se teclea todo en una l�nea y se pone un espacio en blanco despu�s de Write.jp
La opci�n -J-Djava.security.policy=Write.jp le dice al AppletViewer que ejecute el applet referenciado en el fichero SignedApplet.html con el fichero de polic�a Write.jp.
Nota: El fichero de polic�a puede almacenarse en el servidor y especificarse en la invocaci�n al appletviewer como una URL.
�Ejecutar una Aplicaci�n con un Fichero de Polic�a
Esta invocaci�n de aplicaci�n restringe MyProgram a un entorno cerado de la misma forma en que se restringen los applet, pero permite los accesos especificados en el fichero de polic�a polfile.
java -Djava.security.manager
-Djava.security.policy=polfile MyProgram
�Applets Firmados en JDK 1.1
Los applets firmados del JDK 1.1 pueden acceder a recursos del sistema local si �ste est� configurado para permitirlo. Puedes ver la p�ginas ejemplos de Applets Firmados del JDK 1.1 para m�s detalles.
�Escribir un Controlador de Seguridad
Un controlador de seguridad es un objeto de la M�quina Virtual Java (JVM) que implementa un polic�a de seguridad. Por defecto, la plataforma Java 2� proporciona un controlador de seguridad que desactiva todos los accesos a los recursos del sistema local menos los accesos de lectura al directorio y sus subdirectorios d�nde es invocado el programa.
Podemos extender el controlador de seguridad por defecto para implementar verificaciones y aprovaciones personalizadas para applets y aplicaciones, pero la implementaci�n debe incluir c�digo de verificaci�n de accesos apropiado para cada m�todo checkXXX que sobreescribamos. Si no incluimos este c�digo, no suceder� ningun chequeo de verificaci�n, y nuestro programa escindir� el fichero de polic�a del sistema.
Esta secci�n usa una aplicaci�n de ejemplo para explicar c�mo escribir un controlador de seguridad personalizado antes de leer y escribir los ficheros especificados. La implementaci�n incluye c�digo de verificaci�n de accesos por eso una vez que el usuario pasa el chequeo de password, todav�a necesita que el fichero tenga permisos de lectura y escritua en su fichero de polic�a.
El ejemplo consiste en la aplicaci�n FileIO, y el programa PasswordSecurityManager que proporciona la implementaci�n del controlador de seguridad personalizado.
�El programa FileIO
El programa FileIO muestra un sencillo interface de usuario que pide al usuario que introduzca alg�n texto. Cuando el usario pulsa el bot�n Click Me, el texto se graba en un fichero en el directorio home del usuario, y se abre y se lee un segundo fichero. El texto le�do del segundo fichero se muestra al usuario.
 Antes de Pulsar el bot�n |
 Despu�s de Pulsar el bot�n |
El controlador de seguridad personalizado para este programa le pude al usuario final que introduzca una password antes de permitir que FileIO escriba o lea texto desde un fichero. El m�todo main de FileIO crea un controlador de seguridad personalizado llamando PasswordSecurityManager.
public static void main(String[] args){
BufferedReader buffy = new BufferedReader(
new InputStreamReader(System.in));
try {
System.setSecurityManager(
new PasswordSecurityManager("pwd", buffy));
} catch (SecurityException se) {
System.err.println("SecurityManager already set!");
}
�La Clases PasswordSecurityManager
La clase PasswordSecurityManager declara dos variables de ejemplar privadas, que son inicializadas por el constructor cuando se instala el controlador de seguridad personalziado. La variable de ejemplar password contiene el password real, y la variable de ejemplar buffy es un buffer de entrada que almacena la password de entrada del usuario final.
public class PasswordSecurityManager
extends SecurityManager{
private String password;
private BufferedReader buffy;
public PasswordSecurityManager(String p,
BufferedReader b){
super();
this.password = p;
this.buffy = b;
}
El m�todo accessOK le pide una password al usuario final, verifica la password, y devuelve true si el password es correcto y false si no lo es.
private boolean accessOK() {
int c;
String response;
System.out.println("Password, please:");
try {
response = buffy.readLine();
if (response.equals(password))
return true;
else
return false;
} catch (IOException e) {
return false;
}
}
�Verificar Accesos
La clase padre SecurityManager proporciona m�todos para verificar accesos de lectura y escritura a ficheros del sistema. Los m�todo checkRead y checkWrite tienen una versi�n que acepta un String y otra versi�n que acepta un descriptor de fichero.
Este ejemplo s�lo sobreescrie las versiones String para mantener el ejemplo sencillo, y como el programa FileIO usa accesos a directorios y ficheros como Strings.
public void checkRead(String filename) {
if((filename.equals(File.separatorChar + "home" +
File.separatorChar + "monicap" +
File.separatorChar + "text2.txt"))){
if(!accessOK()){
super.checkRead(filename);
throw new SecurityException("No Way!");
} else {
FilePermission perm = new FilePermission(
File.separatorChar + "home" +
File.separatorChar + "monicap" +
File.separatorChar + "text2.txt", "read");
checkPermission(perm);
}
}
}
public void checkWrite(String filename) {
if((filename.equals(File.separatorChar + "home" +
File.separatorChar + "monicap" +
File.separatorChar + "text.txt"))){
if(!accessOK()){
super.checkWrite(filename);
throw new SecurityException("No Way!");
} else {
FilePermission perm = new FilePermission(
File.separatorChar + "home" +
File.separatorChar + "monicap" +
File.separatorChar + "text.txt" ,
"write");
checkPermission(perm);
}
}
}
}
El m�todo checkWrite es llamado antes de escribir la entrada del usuario en el fichero de salida. Esto es porque la clase FileOutputStream llama primero a SecurityManager.checkWrite.
La implementaci�n personalizadapara SecurityManager.checkWrite chequea el pathname /home/monicap/text.txt, si es true le pide al usuario una password. Si la password es correcta, el m�todo checkWriterealiza el chequeo del acceso creando un ejemplar del permiso requerido y pasandolo al m�todo SecurityManager.checkPermission. Este chequeo suceder� si el controlador de seguirdad encuentra un fichero de seguridad de sistemam de usuario o de programa con el permiso especificado.
Una vez completada la operaci�n de escritura, al usuario final se le pide la password dos veces m�s. La primera vez para leer el directorio /home/monicap, y la segunda vez para leer el fichero text2.txt. Se realiza un chequeo de acceso antes de que tenga lugar la operaci�n de lectura.
�Fichero de Polic�a
Aqu� est� el fichero de polic�a que necesita el programa FileIO para las operaciones de lectura y escritura. Tambi�n conceder permiso al controlador de seguridad personalizado para acceder a la cola de eventos en representaci�n de la aplicaci�n y mostrar la ventana de la aplicaci�n si ning�n aviso.
grant {
permission java.io.FilePermission
"${user.home}/text.txt", "write";
permission java.util.PropertyPermission
"user.home", "read";
permission java.io.FilePermission
"${user.home}/text2.txt", "read";
permission java.awt.AWTPermission
"accessEventQueue";
permission java.awt.AWTPermission
"showWindowWithoutWarningBanner";
};
�Ejecutar el programa FileIO
Aqu� est� c�mo ejecutar el programa FileIO con el fichero de polic�a.
java -Djava.security.policy=polfile FileIO
�Informaci�n de Referencia
El Ap�ndice A: Seguridad y Permisos describe los permisos disponibles y explica las consecuencias de conceder permisos. Una forma de usar esta es informaci�n es para ayudarnos a limitar los permisos concedidos a un applet o aplciaci�n podr�an necesitar ser ejecutados satisfactoriamente. Otra forma de usar esta informaci�n es educarnos en la forma en un permiso particular puede ser explotado por c�digo mailicioso.
El Ap�ndice B: Clases, M�todos y Permisos proporciona lista de m�todos de la plataforma Java 2 que est�n implementados para chequeos de seguridad, los permisos que cada uno requiere, y el m�todo java.security.SecurityManager llamado para realizar el chequeo de accesos.
Podemos usar esta referencia para escribir implementaciones de nuestro propio controlador de seguridad o cundo implementamos m�todos abstactos que realizan tareas relacionadas con la seguridad.
El Ap�ndide C: M�todos del SecurityManager lista los chequeos de permisos para los m�todo de SecurityManager.�