Control de Acceso

Control de Acceso
El tema de Control de Acceso es el eje tradicional del estudio
de seguridad informática, porque trata de mecanismos que
operan en cada máquina en forma aislada, usualmente por una
combinación del diseño del sistema de operación (SOP) y la
arquitectura del hardware.
La función del SOP es mediar las interacciones entre los
principales previamente autenticados (usuarios, procesos – a
veces llamados sujetos) y los objetos (archivos, dispositivos
. . . ) que tratan de manipular.
12 de junio de 2002
Control de Acceso-1
Protección en el SOP
El modelo más general se llama la Matriz de Control de
Acceso, ej.:
SOP
Sam r w x
Alicia - - x
Bob r - x
MIDAS
rwx
--x
r--
Datos
rwrwr--
Pista
r---r--
MIDAS es un programa de contabilidad, Pista es un archivo
con la pista de auditoría. Sam es el administrador del sistema,
Alicia la gerente de finanzas, y Bob el auditor.
Las entradas expresan los derechos de acceso del sujeto (fila)
sobre el objeto (columna) en términos de leer (r), escribir (w),
y ejecutar (x).
Entonces, Sam puede cambiar todo menos la Pista, Bob sólo
puede leer más no cambiar, etc.
12 de junio de 2002
Control de Acceso-2
La matriz del ejemplo no refleja lo que queremos, porque
Alicia puede modificar los Datos directamente. Mejor sería:
SOP
Sam
rwx
Alicia r - x
MIDAS r - x
Bob
r-x
MIDAS
rwx
--x
r-r--
Datos
r---rwr--
Pista
r----wr--
Nota: ahora MIDAS es un objeto y un sujeto.
Esto todavía no es perfecto porque Sam podría sobreescribir a
MIDAS con su propio programa . . .
12 de junio de 2002
Control de Acceso-3
Grupos y Roles
Aunque el modelo de la matriz es teóricamente completo para
expresar los controles de acceso, es impráctico para sistemas
con muchos sujetos y/o objetos.
En sistemas reales, los principales se pueden clasificar en
categorías para reducir la complejidad. Hay varias formas de
enfocar esto:
Grupo: Un conjunto de principales, ej. “empleados del departamento
de contabilidad”.
Rol: Un conjunto de derechos de acceso que puede ser asumido por
uno o más principales en forma no-permanente, ej. “el oficial
de guardia”.
Los enfoques no son contradictorios, pero en la práctica el
enfoque de Grupos tiene mucha tradición, mientras el de Roles
es más experimental, e implementado más en la semántica de
aplicaciones que en el SOP.
12 de junio de 2002
Control de Acceso-4
Listas de Control de Acceso
Dado que la matriz es casi vacia (la mayoría de los sujetos no
tienen derechos sobre la mayoría de los objetos) podemos
ganar en eficiencia guardando las entradas no-vacias de cada
columna junto con el objeto correspondiente. Esto se llama
una lista de control de acceso o ACL.
Los ACLs permiten bastante flexibilidad, pero tienen un costo:
es dificil saber a cuales objetos un determinado sujeto tiene
acceso. En particular, es costoso revocar todos los derechos de
un sujeto (por ejemplo cuando se le cancela la cuenta).
No obstante, variantes de los ACLs existen en Unix y en
Windows NT. La implementación en NT es más compleja y
flexible, pero menos probado en el mundo real. Veamos la
versión implementada en Unix.
12 de junio de 2002
Control de Acceso-5
Capabilities
La alternativa a los ACLs es guardar las entradas no-vacias de
cada fila junto con el sujeto correspondiente. En este caso las
filas se llaman listas de capabilities (un capability es la tupla
[{derechos}, objeto]).
El uso de capabilities ofrece ventajas de eficiencia al tiempo
de ejecución porque el SOP puede chequear inmediatamente si
existe un derecho de acceso a un objeto, sin verificar quien es
el sujeto.
Además, facilita la delegación: Alicia le puede entregar a Bob
el derecho de accesar a su archivo Datos, por ejemplo a
determinada hora. Esto es dificil lograr con ACLs.
Problema: ahora es dificil saber quien tiene acceso al objeto.
Según las detalles de implementación, Bob podría haberlo
regalado a Manuel, sin preguntarle a Alicia. Esto complica la
revocación de todos los derechos sobre un objeto.
Los capabilities son menos usados que los ACLs, pero un
ejemplo real es el sistema AS/400 de IBM. También se puede
considerar que los certificados criptográficos son realmente
capabilities, con muchas de las mismas ventajas y problemas.
12 de junio de 2002
Control de Acceso-6
La meta de muchos administradores de redes locales o
intranets es lograr single sign-on, o sea que el usuario se
identifique una sola vez para obtener un abaníco de servicios,
por ejemplo leer correo, ver las notas de un estudiante,
consultar información personal de la Nómina, reservar un
salón de clase, etc., todos los cuales son implementados en
servidores distintos en unidades administrativamente
independientes.
A una escala más grande, se está empezando a trabajar en
servicios de autentificación globales para el Internet, ej.
Passport (Microsoft) o Liberty Alliance. Sin embargo, esto
acarrea sus propios problemas:
Requiere mucho cuidado en el diseño. Ej. el sistema Passport
tiene vulnerabilidades conocidas.
Implica depositar mucha confianza en el administrador central
del servicio de autenticación.
Puede permitir a un adversario (que puede ser el gobierno)
correlacionar distintas actividades de un usuario.
12 de junio de 2002
Control de Acceso-7
Protección en Hardware
El SOP sólo puede ser efectivo si siempre puede mediar los
accesos a los objetos. Tiene que ser posible garantizar que un
programa no pueda tomar control de la máquina y bloquear la
intervención del SOP, o lo altere indebidamente. Esto requiere
necesariamente cierto soporte de hardware, incluyendo como
mínimo:
Una arquitectura de procesador que soporte al menos dos
modos de ejecución, uno de los cuales tiene menos privilegios
que el otro. Cada modo debe tener su propio PC (contador de
programa) y registros internos.
En el modo no-privilegiado, debe ser posible:
• Restringir las direcciones de memoria accesibles.
• Limitar el acceso directo a los dispositivos.
• Evitar cambios de modo no-controlados.
Un reloj que interrumpe la ejecución periódicamente y pasa
control al modo privilegiado (para evitar denials of service).
Sin estos elementos, no es posible implementar controles de
acceso en una manera confiable.
12 de junio de 2002
Control de Acceso-8
Ataques a los Controles de Acceso
El ataque favorito es aprovechar la falta de cuidado en el
chequeo de parámetros a un programa que corre con
privilegios de root, por ejemplo:
{
char buffer[16];
printf ("Nombre: ");
gets (buffer); /* Leer nombre */
...
Nombre: unstringextremadamentelargo
El programa no chequea el tamaño de su entrada. Como esta
es más grande que el espacio reservado, se desborda el arreglo
buffer y se sobreescribe la pila. Con suficiente cuidado,
Manuel puede insertar instrucciones de máquina para que el
programa ejecute una llamada al sistema similar a:
system ("/bin/sh");
Ahora tiene un Shell corriendo en el servidor, con los
privilegios del dueño del programa. Esto se llama
stack-smashing.
12 de junio de 2002
Control de Acceso-9
Hay varias técnicas de defensa contra este tipo de problema:
Algunos sistemas (ej. Linux) tienen una opción en el kernel
para que el segmento de pila no sea ejecutable. En ciertos
casos (no comunes) esto puede romper algunos programas, y
en todo caso no es una solución 100 % efectivo.
Un producto llamado Stackguard (www.immunix.org)
envuelve las llamadas a funciones en código especial que
permite detectar cuando la dirección de retorno en la pila ha
sido alterada. Tampoco es 100 % efectivo.
Exhortar a los programadores a tener más cuidado cuando
crean programas setuid. Además, realizar auditorias para
que otros puedan revisar el código (por ejemplo el grupo
Open BSD se dedica a esto). En este contexto el acceso al
código fuente es crítico.
12 de junio de 2002
Control de Acceso-10
Condiciones de Carrera
Otro tipo de ataque explota pequeñas ventanas de tiempo en
que un sistema es vulnerable. Por ejemplo, a veces una
aplicación crea un archivo temporal en el directorio /tmp, y
luego lo borrar unos segundos después. Esto requiere que se
genere un nombre para dicho archivo, que no coincida con
otro ya existente:
for (;;) {
generar nombre aleatorio en /tmp
si /tmp/nombre-nuevo no existe {
crear /tmp/nombre-nuevo /* X */
break
}
}
Si Manuel es suficientemente astuto, puede predecir el valor
de nombre-nuevo y justamente en el punto “X” crear un
enlace simbólico con ese nombre, apuntando a un archivo de
su elección, por ejemplo /etc/passwd . . .
Defensa: crear nombres temporales atómicamente es
“truculento” pero hay rutinas de librería que lo pueden hacer.
Uselas.
12 de junio de 2002
Control de Acceso-11
Otros Ataques
Algunos ataques son legendarios:
El sistema TENEX chequeaba passwords en un lazo
secuencial, caracter por caracter, y devolvía un error tan
pronto lo detectaba. Manuel podía colocar su candidato para el
password al final de la memoria virtual:
legal ilegal
c andidato
Si el sistema retorna el error, el primer caracter es incorrecto y
Manuel intenta con otro. Si da una excepción por acceso ilegal
a memoria, el primer caracter es correcto. Manuel corre el
candidato una posición y repite:
legal ilegal
ca ndidato
Esta técnica permite atacar un espacio de AN posibles
passwords con un costo proporcional a A × N , por un alfabeto
de tamaño A y passwords de longitud máxima N .
Alternativamente, Manuel puede medir cuanto tiempo le tarda
al sistema en rechazar su candidato, para saber cuantas
iteraciones del lazo fueron ejecutados. En este caso se llama
un timing attack.
12 de junio de 2002
Control de Acceso-12
Ataques de denial of service (DOS):
Manuel ejecuta tantos procesos que llena una tabla interna de
tamaño fijo. Ni siquiera root puede ejecutar un comando de
Shell para matar su programa.
Manuel envia tantos paquetes SYN en la red (para abrir
conexiones TCP) que se llenan los buffers. Esto es un SYN
Flood.
Ataques de interfaz al usuario:
Manuel fabrica un programa (ej. un juego) y lo ofrece al
administrador, quien lo ejecuta con sus privilegios. El juego
funciona, pero también hace otras cosas . . .
Esto es el famoso Caballo de Troya. Funciona por una
violación del Principio de Mínimo Privilegio.
Un variante es que Manuel crea su caballo de Troya con el
nombre ls y lo deja en algún directorio donde tiene permisos.
Algún día el administrador entra en el directorio y ejecuta ls
para listar sus contenidos . . .
El administrador debe cuidarse de no incluir el directorio
actual “.” en su “camino de búsqueda” ($PATH en Unix).
12 de junio de 2002
Control de Acceso-13
Rootkits
Si Manuel logra obtener privilegios de root, procede a
encubrir sus acciones:
Instala nuevos binarios de comandos importantes, por ejemplo
con una “puerta trasera” para que le sea más fácil entrar la
próxima vez.
En los sistemas que permiten cargar módulos dinámicos del
sistema de operación, puede colocar un módulo suyo para
tomar control total sobre el sistema atacado.
Cambia el comportamiento de los utilitarios que hacen
“logging” en el sistema para que no le rastrean.
Altera los logs existentes (/var/log/wtmp etc.) para quitar
la evidencia de su penetración, y cambia las fechas de
modificación de archivos claves (/etc/passwd etc.) para
que no se note que han cambiado.
Para facilitar estas acciones (que requieren de bastante
sofisticación) puede utilizar un “rootkit” o paquete preparado
por un experto. Disponible en los mejores sitios del Internet.
Defensa: el sistema Tripwire mantiene una base de datos con
un hash criptográficamente fuerte de todo archivo importante,
y puede detectar cualquier cambio. La base de datos debe ser
guardado en otro sitio que no sea vulnerable. Nótese que el
programa tripwire en sí es un punto vulnerable a ataques.
12 de junio de 2002
Control de Acceso-14