Autenticación y control de acceso

Transcripción

1 Autenticación y control de acceso Seguridad en Redes de Ordenadores Enrique Soriano LS, GSYC 17 de febrero de 2015

2 (cc) 2015 Grupo de Sistemas y Comunicaciones. Algunos derechos reservados. Este trabajo se entrega bajo la licencia Creative Commons Reconocimiento - NoComercial - SinObraDerivada (by-nc-nd). Para obtener la licencia completa, véase También puede solicitarse a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

3 Términos Identificación: Alguien dice ser un sujeto concreto. Autenticación: Alguien demuestra su identidad. Autorización: Otorgamiento de privilegios a un sujeto para realizar una operación de acceso sobre uno o varios objetos. Control de acceso: Permitir o denegar una operación de acceso sobre un recurso en base a la autorización del sujeto.

4 Autenticación Un programa se autentica ante el sistema a nombre de un usuario y pasa a ejecutar a su nombre. Cómo te autenticas? Algo que conoces. Algo que tienes. Algo que eres. Algo que haces. Donde estás.

5 Contraseñas La forma más común y sencilla de autenticación: el usuario proporciona un secreto que sólo él y el sistema conocen. Riesgos: Que vean nuestra contraseña. Que la adivinen. Spoofing (suplantación). Que se hagan con el almacén de contraseñas.

6 Que vean nuestra contraseña: No se deben compartir. Contraseñas No se deben apuntar en claro. No se debe usar la misma contraseña para distintos servicios. Aplicaciones keyring: Password Safe (Windows), Keychain (OSX), etc.

7 Contraseñas Que adivinen nuestra contraseña: Ataque de fuerza bruta. Búsqueda inteligente. Ataque de diccionario online.

8 Keyspace: Ataque de fuerza bruta Siendo S la longitud de la contraseña y N el número de símbolos que se pueden usar en las contraseñas. Keyspace = s N i i=0 Ejemplo: Contraseñas de sólo minúsculas y de 0 a 8 caracteres: Ejemplo: Con mayúsculas, minúsculas, números y símbolos de puntuación, de 0 a 14 caracteres:

9 Imagen (C) xato.net Ataque inteligente

10 No usar passwords comunes: Contraseñas

11 Contraseñas Contraseñas de calidad: Nnemotécnicos: TabletMipefaesstwa3 de Mi peĺıcula favorita es star wars 3 Rimas: SEGURIDAD-0-calamidad@casa Repetición: hey.h0.hey.h0.6

12 Contraseñas Distintas contraseñas para distintos servicios: Se puede tener un método para generar las contraseñas para distintos servicios. Por ejemplo, poner al principio el número de caracteres del servicio o servidor: Amazon: A6m1--mej0r--SECRETO Msn: M3m1--mej0r--SECRETO Apple: A5m1--mej0r--SECRETO

13 Contraseñas Medidas de protección: No permitir contraseñas vacías en el sistema. Obligar a cambiar las contraseñas por omisión. Ejemplo: routers adsl. Obligar a que tengan una longitud mínima (no menos de 8 caracteres). Obligar a que no sean palabras del diccionario: requerimos puntos, números, mayúsculas y minúsculas, etc.

14 Contraseñas Medidas de protección: Pasamos crackers para validarlas. Ejemplo: John the Ripper. Obligar a cambiar las contraseñas periódicamente. No permitir reusar contraseñas antiguas. No es buena idea generar contraseñas aleatorias para los usuarios las apuntan. Si son aleatorias, no deben ser predecibles.

15 Contraseñas Medidas de protección: Limitar el número de intentos de autenticación. Aumentar el tiempo entre autenticaciones fallidas. Compromiso: seguridad vs. obstrucción.

16 Contraseñas Más riesgos: que nos timen. Spoofing Keyloggers Ingeniería social...

17 Contraseñas Spoofing: Un atacante reemplaza al sujeto ante el que nos autenticamos, y nos roba la contraseña. Seguramente no nos demos cuenta: el resultado de la autenticación parece un error al escribir la contraseña, pero no lo es. Ataque clásico: reemplazar /bin/login En el WWW: te conectas a una página que no es la que crees (p. ej. te engañan con phishing).

18 Contraseñas Medidas de protección: Imprimir el número de intentos reales que se llevan. Trusted Path: estar seguros de que el usuario se comunica con el sistema operativo y no con un programa falso. Doble autenticación: el programa de login se autentica ante el usuario antes de que el usuario se identifique y autentique.

19 Contraseñas Keyloggers: Software: un programa captura todo lo que tecleamos. Hardware: espía el cable del teclado o la transmisión inalámbrica de ratones/teclados. Aprox. 50 Euros, 2Gb. Los hay WiFi.

20 Contraseñas Medidas de protección: Para PIN: mostrar una tabla por pantalla con una sustitución de los números por caracteres, distinta en cada autenticación. Usar el ratón para introducir la contraseña.... pero también nos pueden engañar con hardware (150 Euros, 2 Gb de screenshots).

21 Moraleja: The Big Stick Principle. Contraseñas

22 Contraseñas Si se hacen con el almacén de contraseñas: Las contraseñas se suelen guardar cifradas. Por lo general, se guarda un hash de la contraseña. Ataque de diccionario offline: mucho más efectivo que online.

23 Contraseñas Ataque de diccionario offline: Buscar la hash que se quiere romper en una tabla precalculada de tuplas (contraseña, hash) cambias tiempo de computación por espacio. Rainbow-tables (p. ej. ophcrack). Uso de Google para encontrar la hash. Qué contraseña tiene esta hash SHA-1? 99800b85d3383e3a2fb45eb7d0066a4879a9dad0 Búscalo en Google!

24 Compromiso espacio/cómputo: Rainbow Tables

25 Contraseñas Medidas de protección: Contraseñas largas. Hashes con salt. key strengthening: salt secreta.

26 Caso: autenticación clásica en Unix Pasos de arranque: 1. Scripts de arranque (init). 2. /bin/getty 3. /bin/login

27 Caso: credenciales en Unix Un proceso tiene credenciales 1 : PID: identificador de proceso. UID: identificador de usuario. GID: identificador de grupo. EUID: identificador de usuario efectivo, el que se usa para comprobar privilegios. EGID: identificador de grupo efectivo, el que se usa para comprobar privilegios Dependen del sabor de UNIX

28 Caso: autenticación básica en Unix /etc/passwd: Login. Contraseña ( x cuando tenemos shadow) UID. GID. Gecos info: datos sobre el usuario, separados por comas. Path del home. Programa de inicio.

29 Caso: autenticación básica en Unix /etc/shadow: Login. Hash: son tres campos separados por $. Algoritmo: p. ej. 1 es MD6, 6 es SHA-512. Salt Hash NOTA: Si tiene un valor que no se corresponde con una posible salida de crypt, el usuario no se podrá autenticar con contraseña (pero sí de otras formas). Por ejemplo, se pone o! para evitar que el usuario entre con contraseña. Si está vacío, el usuario no tiene contraseña (no es recomendable). En Linux recientes, la contraseña de root es!.

30 Caso: autenticación básica en Unix /etc/shadow (continúa): Fecha Unix del último cambio de contraseña. Mínima edad: mínimo número de días para permitir un cambio de contraseña. Máxima edad: días tras los que tiene que cambiar la contraseña. Días, antes de la caducidad según el campo anterior, para avisar al usuario. Días de prórroga desde que caduca, cuando pasan se anula la contraseña.

31 Caso: autenticación básica en Unix /etc/shadow (continúa): Fecha Unix de caducidad para la cuenta. Si llega, se cancela la cuenta. No es lo mismo que la edad de la contraseña, esta es más dura. Campo reservado para uso futuro.

32 Caso: control de credenciales en Unix /bin/id: Permite ver tu UID y GID. /bin/su: Permite ejecutar un shell con otro UID. Por omisión, intenta ejecutar un shell con UID 0. /usr/bin/sudo: Permite ejecutar un comando con otro UID, proporcionando tu propia contraseña. El fichero /etc/sudoers especifica quién puede convertirse en quién, y para qué.

33 Caso: control de credenciales en Unix Ejemplo de sudoers (I): jose ALL = (root, bin : operator, system) ALL jose puede, en cualquier máquina adquirir el UID de root y bin adquirir el GID de operator y system para ejecutar cualquier comando

34 Caso: control de credenciales en Unix Ejemplo de sudoers (II): ramon mono = NOPASSWD: /bin/kill, PASSWD: /bin/ls, /usr/bin/lprm ramon puede, en la máquina mono adquirir el UID de root para ejecutar kill sin proporcionar contraseña para ejecutar ls y lprm proporcionando contraseña

35 Caso: autenticación en Windows Windows almacena las contraseñas en SAM: \windows\system32\config\sam El fichero está bloqueado en todo momento. Puede contener dos tipos de contraseñas cifradas: LM (Lan Manager). Inseguro! Windows 7 no la usa por omisión (pero se puede configurar para que las use, ojo). NTLM (NT Lan Manager): No tan seguro como debería.

36 Caso: autenticación en Windows En un terminal (cmd.exe )como administrador:

37 Caso: autenticación en Windows Contraseñas LM (Lan Manager): Convierte todos los caracteres de la contraseña a mayúsculas. Rellena con 0s la contraseña hasta llegar a los 14 caracteres. Parte la contraseña en dos bloques de 7 bytes. Usa los dos bloques como claves para cifrar con DES para un bloque de datos conocido: 0x4b Concatena el resultado de los dos cifrados DES. NO podían haber metido más la pata!

38 Caso: autenticación en Windows Contraseñas LM (Lan Manager): VS

39 Caso: autenticación en Windows Contraseñas NTLM (NT Lan Manager): Usa una hash MD4 de 128 bits, que era segura en 1991: Ataque de colisión en microsegundos. Ataque de pre-imagen teórico. Diferencia entre mayúsculas y minúsculas. No usa salt.

40 Caso: autenticación en Windows Syskey: Añade una capa extra de seguridad cifrando el almacén de claves de SAM. Opción I (activada por omisión): Usa una clave generada para cada sistema y que está oculta en el Registro. Viola el principio de Kerckhoffs: no sirve de nada. bkhive la encuentra, samdump2 descifra el archivo de SAM. Opción II:Generar la clave a partir de una contraseña adicional que se introduce en el arranque. Opción III: Almacenar la clave en un disco extraíble.

41 Caso: autenticación en Windows Ophcrack rompe contraseñas débiles de Windows NT (hashes MD4) con rainbow tables:

42 Caso: control de credenciales en Windows En Windows es común usar una cuenta de administrador. User Account Control (UAC) permite controlar los privilegios: Un administrador tiene un token de usuario y token de administrador. Idea: evitar el uso del token de administrador para operaciones que no lo requieren. Cuando se intenta usar el de administrador (elevación) se presenta una ventana de diálogo UAC para pedir permiso o credenciales.

43 Caso: control de credenciales en Windows Los diálogos de elevación usan un código de colores: Rojo (con escudo) si el firmante de la aplicación está bloqueado, es una aplicación sin firma bajada de Internet. Azul (con escudo) si es una aplicación administrativa de Windows (p.ej. Panel de Control). Azul (con interrogación) si la aplicación está firmada por terceros con Authenticode y se puede verificar. Amarillo (con escudo) si la aplicación no está firmada o está firmada pero no se puede verificar.

44 Caso: control de credenciales en Windows

45 Caso: control de credenciales en Windows UAC niveles Sólo el nivel más alto impide autoelevación silenciosa. Los niveles más bajos no usan el escritorio seguro.

46 Caso: control de credenciales en Windows Ventajas de UAC: No hay que usar dos cuentas (usuario y administrador). No hay que entender para qué hay que usar la cuenta de administrador y para qué la otra. No hay que gestionar dos perfiles distintos (carpetas, escritorios, etc.). Aplica el principio de mínimo privilegio. Inconvenientes: No ha sido bien recibido por ser molesto El problema es la interfaz?

47 Algo que eres Nuestro cuerpo nos puede autenticar (biometría): Escaner de iris. Escaner de retina. Huellas dactilares. Palma de la mano. Reconocimiento de voz. Reconocimiento facial.

48 Algo que eres Aumenta el riesgo para la integridad física del usuario. Son más propensos a fallar: Falso positivo: autenticación errónea. Falso negativo: aumenta la obstrucción. Cómo se revoca una huella dactilar o una cara?

49 Algo que tienes Tu SmartPhone: Google Authenticator. SecureID Smart Cards RFID / NFC USB tokens Fortezza...

50 Algo que tienes Los dispositivos de autenticación: Pueden disminuir la obstrucción, como NFC. Pueden aumentar la obstrucción, como SecureID. Hay que fiarse del HW lector: igual que con las contraseñas, puede existir spoofing. Nuevo riesgo: puedes perder el objeto, o te lo pueden robar. Si lo piensas, corremos los mismos riesgos a diario con las llaves de nuestra casa o las tarjetas de crédito.

51 DNIe Por ejemplo, el DNI electrónico (DNIe): Se usa para cualquier tipo de tramitación telemática con el estado. Tiene la misma validez que el DNI normal.

52 DNIe El DNI electrónico (DNIe) es una SmartCard tamper-resistant con los siguientes ficheros dentro: Datos de filiación del titular Imagen digitalizada de la fotografía. Imagen digitalizada de la firma manuscrita. Plantilla de la impresión dactilar de los dedos índice de cada mano. Certificado X.509 para autenticación, y la clave privada correspondiente. Certificado X.509 para firma, y la clave privada correspondiente. Certificado X.509 de la autoridad emisora. La generación de claves, el cifrado/descifrado, la firma, etc. se realiza en el chip de la tarjeta.

53 DNIe Se entrega junto con un PIN (sic) (es una contraseña con 8-16 caracteres): algo que tienes + algo que sabes. Se puede cambiar la contraseña desde cualquier PC si sabemos la contraseña viejo. Se puede reestablecer la contraseña (sin conocer el viejo) en un terminal especial (Punto de Actualización del DNIe). Es necesario proporcionar la huella dactilar (la verificación se hace en el propio chip): algo que tienes + algo que eres.

54 Otras formas Algo que haces: por ejemplo, gestos ante una cámara, en un touchpad, etc. Dónde estás: el simple hecho de encontrarte en una localización física (p.ej., la sala de los servidores) te autentica.

55 Single Sign-On Una única autenticación para usar varios servicios distintos. Tendremos Single Sign-On para todos los servicios?

56 Combinación de métodos de autenticación SUN s PAM (Pluggable Authentication Modules): Objetivos: Combinar distintos métodos de autenticación proporcionados por distintos módulos independientes. Usar distintos métodos de autenticación sin modificar el código de las aplicaciones. Modificar la autenticación sin parar el sistema. PAM está disponible para distintos sabores de Unix.

57 Linux-PAM Seis primitivas englobadas en cuatro grupos: Auth: tareas para autenticar al usuario. Account: tareas de gestión de los datos de una cuenta. Password: tareas para administrar los mecanismos de la autenticación. Session: tareas a realizar al crear y destruir sesiones.

58 Linux-PAM Auth: pam authenticate: sirve para autenticar al sujeto. pam setcred: sirve para establecer y gestionar las credenciales. Tiene que llamarse después de pam authenticate y antes de establecer la sesión.

59 Linux-PAM Session: pam open session: realiza las tareas asociadas con el inicio de sesión. Por ejemplo, actualizar logs de entrada, etc. pam close session: se encarga de las tareas asociadas con el fin de sesión. Por ejemplo, actualizar logs de salida, etc.

60 Linux-PAM Account: pam acct mgmt: verifica si la cuenta está en buenas condiciones. Por ejemplo si la contraseña caducó, si la cuenta está cancelada, etc.

61 Linux-PAM Password: pam chauthtok: cambia el objeto de la autenticación (p.ej., la contraseña), posiblemente comprobando que es suficientemente bueno, etc.

62 Linux-PAM En /etc/pam.d/ se crean ficheros con las poĺıticas para los distintos servicios. Un fichero de poĺıticas define una pila de reglas que determina el éxito de una operación: type control module-path module-arguments type: grupo (auth, account, password, session). control: cómo afecta al resultado de la operación. module-path: módulo. module-arguments: argumentos.

63 Linux-PAM Control: requisite: si la operación retorna error, se acaba la autenticación con fallo. required: si retorna error, el flujo continua aunque el resultado final ya está decidido: será un fallo. sufficient: si retorna éxito, termina inmediatamente la con éxito. Si retornar error, se sigue llamando al resto (y si el resto funcionan, la operación acaba con éxito). optional se ejecuta, pero lo que retorne (éxito o fallo) no se tiene en cuenta.

64 Linux-PAM: ejemplo Aplica un retardo, da igual lo que devuelva. Si existe el fichero /etc/nologin sólo root puede autenticarse en la máquina Comprueba que el contexto anterior se ha limpiado Se leen las variables de entorno y las variables del fichero /etc/default/locale Se aplican todas las reglas del fichero de PAM common-auth (normalmente pedir password, comprobar hash) Aplica filtros de /etc/security/group.conf para añadir al usuario a Aplica las reglas de esos tres ficheros de PAM Imprime si el usuario tiene correo. Imprime el MOTD (Message of the day) Imprime la fecha del último login. Establece los límites del usuario según /etc/security/group.conf grupos dependiendo de factores como la hora, TTY, etc.

65 Autenticación en sistemas distribuidos

66 Sistemas distribuidos: riesgos Los riesgos a los que se expone el sistema: Espionaje de los mensajes que viajan por la red. No se puede detectar desde los extremos. Eliminación, modificación, e inserción de mensajes transmitidos. Este ataque es activo, y se puede detectar. Repetición de mensajes antiguos. También es activo.

67 Challenge-Response Objetivo: que las contraseñas no viajen por la red. El servidor envía un reto. El cliente responde el reto. Los retos no se deben repetir!

68 Challenge-Response CRAM-MD5: 1. C S : nonce 2. C calcula r = HMACMD5(nonce, pass) 3. C S : r,login 4. S comprueba si r = HMACMD5(nonce, pass)

69 Challenge-Response: ejemplo de relay attack 1. M S : nonce 2. C M : nonce 3. C calcula r = HMACMD5(nonce, pass) 4. C M : r,login 5. M S : r,login 6. S comprueba si r = HMACMD5(nonce, pass)

70 Protocolo ejemplo I 1. C crea m = soy C 2. C crea m = E k (m, S) 3. C S : m, m 4. S verifica si m haciendo D k (m )

71 Protocolo ejemplo I: replay attack 1. M recupera m = E k (m, S) viejo 2. M S : m, m 3. S verifica si m haciendo D k (m ) solución: timestamps y nonces

72 Protocolo ejemplo II 1. C S : soy C 2. C S : nonce 3. C crea m = E k (nonce, C, S) 4. C S : m 5. S verifica que E k (nonce, C, S) == m

73 Protocolo ejemplo III Versión con algoritmo asimétrico: 1. C S : soy C 2. C S : nonce 3. C crea m = E KCpri (nonce, C, S) 4. C S : m 5. C S : Cert c 6. S verifica el Cert c con la CA 7. S verifica que D KCpub (m) == (nonce, C, S)

74 Needham-Schroeder Se basa en un servidor de autenticación (A) que comparte secretos con todos los clientes y servidores. Las claves se centralizan en A. Establece una clave para la sesión: K cs

75 Needham-Schroeder 1. C A : C, S, N a 2. A crea m = E Kc (N a, S, K cs, E Ks (K cs, C)) 3. C A : m 4. C consigue N a y K cs haciendo D Kc (m) 5. C verifica N a 6. C S : E Ks (K cs, C) 7. S consigue K cs haciendo D Ks (E Ks (K cs, C)) 8. C S : E Kcs (N b ) 9. C S : E Kcs (N b 1) 10. S verifica D Kcs (N b 1) == N b 1

76 Needham-Schroeder Problema: si una clave de sesión vieja K cs queda comprometida, el atacante puede reiniciar la sesión antigua. 1. M recupera E Ks (K cs, C) viejo. 2. M S : E Ks (K cs, C) 3. S consigue K cs haciendo D Ks (E Ks (K cs, C)) 4. M S : E Kcs (N b ) 5. M consigue N b. 6. C S : E Kcs (N b 1) 7. S verifica D Kcs (N b 1) == N b 1 Solución: usar timestamps y tiempos de validez.

77 Kerberos Está basado en Needham-Schroeder. Usa dos servicios centrales (pueden ejecutar en el mismo nodo): KDC (Key Ditribution Center): autentica al cliente. TGS (Ticket Granting Service): proporciona tickets para acceder a los servicios.

78 Kerberos Fase 1 Fase 2 KDC TGS TGT? TICKET? TGT TICKET C TICKET+AUTHENTICATOR AUTHENTICATOR S

79 Kerberos Elementos: L n : tiempo de vida. T n : timestamp. N n : nonce. Fase 1: Conseguir un Ticket-granting ticket (TGT): 1. C KDC : C, TGS, L 1, N 1 2. KDC genera Ticket c,tgs = E Ktgs (K c,tgs, C, T 1, L 1 ) 3. C KDC : E Kc (TGS, K c,tgs, Ticket c,tgs, L 1, N 1 )

80 Kerberos Fase 2: Conseguir un ticket para el servicio: 1. C genera Authenticator s,tgs = E Kc,tgs (C, T 3 ) 2. C TGS : C, S, L 2, N 2, Ticket c,tgs, Authenticator s,tgs 3. TGS genera Ticket cs = E Ks (K cs, C, T 2, L 2 ) 4. C TGS : E Kc,tgs (S, K cs, Ticket cs, L 2, N 2 ) 5. C genera Authenticator c = E Kcs (C, T 4 ) 6. C S : Authenticator c, Ticket cs 7. S genera Authenticator s = E Kcs (T 4 ) 8. C S : Authenticator s

81 Plan 9 auth También está basado en Needham-Schroeder. Organizado en dominios de autenticación. El servidor impone el dominio para realizar la autenticación. Permite a un usuario hablar en nombre de otro usuario: UID r es el UID del proceso en el cliente; UID c es el UID del sistema cliente; puede que UID r UID c, en ese caso, UID c habla en nombre de UID r.

82 Plan 9 auth 1. C S : N 1 2. C S : N 2, UID s, Dom 3. C A : N 2, UID s, Dom, UID c, UID r 4. A genera Ticket sc = E Ks (N 2, UID r, UID c, K cs ) 5. C A : Ticket sc, E Kc (N 2, UID r, UID c, K cs ) 6. C incrementa CTR 7. C genera Authenticator c = E Kcs (N 2, CTR) 8. C S : Ticket sc, Authenticator c 9. S genera Authenticator s = E Kcs (N 1, CTR) 10. C S : Authenticator s

83 Autenticación en el WWW Comúnmente: 1. Se establece un canal TLS con el servidor. 2. El cliente se autentica con login y contraseña. 3. Se instalan cookies en el cliente. 4. El cliente presenta una cookie en posteriores peticiones de esta sesión.

84 Autenticación en el WWW Algunos atributos de las cookies relacionados con la seguridad: Domain: sólo se puede usar para ese dominio. Path: sólo se puede usar para esa ruta en la URL. Expires: fecha de caducidad. Secure: sólo para usar con HTTPS. HttpOnly: no accesibles para scripts.

85 Autenticación en el WWW Riesgos comunes: Mallory puede reemplazar las cookies si se hace pasar por el servidor. Session hijacking: Mallory se hace con la cookie (nos roba la sesión). P. ej. cuando se mezcla HTTPS con HTTP ( muy mala idea!) hay riesgo de enviar cookies delicadas en claro. Session fixation: Mallory nos induce a crear una sesión con un ID determinado (por tanto, puede continuar con la sesión). P. ej. phising, pinchamos en el link.

86 Autenticación en el WWW Riesgos comunes: Cookie poisoning: Mallory forja sus propias cookies para autenticarse como otro usuario. Cross-site scripting (XSS): Mallory introduce scripts maliciosos en las páginas que visitas (de una tercera parte) que ejecutan como si fuesen legítimos. Ojo: los scripts maliciosos se pueden injectar en caches intermedias, en la cache del navegador, lo puede hacer el propio navegador, etc.

87 Autenticación en el WWW Open ID: Propósito: autenticación federada para el WWW. Idea: usas un servidor de Open ID para autenticarte ante una aplicación web de un tercero sin darle tu contraseña. Proveedores de Open ID: Google, Facebook, Yahoo!, Microsoft, AOL, MySpace. No confundir con OAuth. Riesgo: phising, se presenta una página exactamente igual que la del proveedor de Open ID, pero que no es del proveedor.

88 Imagen c Justen Stepka Autorización en el WWW

89 Control de acceso

90 Control de acceso Acceso: un sujeto activo que intenta interactuar con un objeto pasivo realizando una operación de acceso. El sistema permite/deniega en base a: Lo que le está permitido hacer al sujeto. Lo que está permitido hacerle al objeto. Errores en el diseño o la implementación pueden permitir realizar operaciones no autorizadas. Ejemplo: side-channel de Dropbox.

91 Operaciones de acceso Ejemplos: Añadir Leer Escribir Ejecutar Borrar Cambiar permisos Cambiar dueño Listar Buscar/atravesar

92 Pertenencia El control de acceso puede ser Discrecional (Discretionary Access Control o DAC): el usuario posee objetos y autoriza al resto para acceder a ellos. Obligatorio (Mandatory Access Control o MAC): los usuarios no gestionan el acceso a los objetos.

93 Mandatory Access Control Entornos muy restrictivos (p.ej., militares). Sistemas de Seguridad Multinivel (MLS): Usuarios con rango. Objetos con nivel de seguridad. Compartimentos. Centrados en la confidencialidad (modelo Bell-LaPaluda): Puedes generar documentos de tu nivel o de más alto nivel. Puedes observar documentos de tu nivel o de más bajo nivel. Centrados en la integridad (modelo BIBA): Puedes modificar documentos de tu nivel o de más bajo nivel.

94 Mandatory Access Control Ejemplo: Mandatory Integrity Control (MIC) en Windows 7 aplica MAC BIBA antes de aplicar el control de acceso discrecional: Cuatro niveles: Bajo (no confiable). Los ejecutables pueden ser marcados como nivel bajo si son peligrosos (p.ej. bajados de Intenet y no firmados). Sólo pueden modificar carpetas temporales, etc. Medio (usuario). Los usuarios normales y los objetos que no tienen etiqueta de integridad tienen este nivel. Alto (administrativo). Los administradores tiene este nivel, la carpeta de Archivos de Programa, etc. Sistema (control total). Los servicios del sistema tienen este nivel.

95 IBAC IBAC: Control de acceso basado en la identidad. Access Control Matrix: filas: usuarios, columnas: objetos. list.c a.doc word.exe esoriano r,w r - paurea r r w,x nemo r r,w - sdemingo - - r,w,x

96 IBAC Access Control List: una columna de la matriz. list.c esoriano r,w paurea r nemo r sdemingo -

97 Caso: UNIX Permisos POSIX: Permisos rwx para dueño, grupo, y resto. Los grupos se especifican en /etc/groups. chmod cambia los permisos. chown cambia el dueño de un fichero. Sólo puede hacerlo root.

98 Caso: UNIX Permisos POSIX: chgrp cambia el grupo de un fichero. Lo puede hacer el dueño del fichero (tiene que pertenecer al grupo al que se cambia). sticky bit (+t) en directorios: restringe la eliminación de entradas de directorio aunque el directorio tenga permisos de escritura para todo el mundo: sólo puede borrar/renombrar el dueño y root. P. ej. /tmp

99 Caso: ACLs en Mac OS X Ejemplo de ACLs, Mac OS X: Conviven con los permisos UNIX. Nota: Linux (ext3) también tiene ACL extendidas, pero no son iguales (man acl). La ACL extendida es una lista ordenada de ACEs (Access Control Entry). Se pueden listar las ACLs extendidas con ls -le

100 Caso: ACLs en Mac OS X La ACL extendida es una lista de ACE (Access Control Entry). Una ACE se compone de: Quién?: usuario o grupo. Permiso: Allow o Deny. Acción de acceso sobre el objeto. Un usuario tiene acceso a un recurso si alguna ACE Allow o los permisos UNIX se lo permiten, excepto si alguna ACE Deny se lo impide Los Deny mandan. Es más fácil controlar el acceso determinando los permisos de los contenedores (directorios) y que los ficheros los hereden.

101 Caso: ACLs en Mac OS X Acciones de acceso: delete, readattr, writeattr, writeextattr, readsecurity, writesecurity, chown. Directorios: list, search, add file, add subdirectory, delete child. Ficheros: read, write, append, execute. Herencia (para directorios): file inherit, directory inherit, limit inherit, only inherit. Ejemplo: chmod +a group:wheel deny delete,file inherit,directory inherit dir1

102 Caso: ACLs en Windows 7 Dos tipos: DACL (Discretionary ACL): lista de ACEs que permiten o deniegan un tipo de acceso para una cuenta o grupo. SACL (System ACL): usada para auditar, es una lista de ACEs que indican el tipo de acción que provocará una entrada en el Security Event Log.

103 RBAC RBAC: Control de acceso basado en roles. Rol: colección con nombre de permisos. Se asignan roles a los sujetos/grupos del sistema. Un usuario puede tener más de un rol. Los roles pueden ser dinámicos. Un grupo organiza identidades, un rol organiza permisos. Puede haber una jerarquía de roles. Es útil para implementar la separación de deberes. Escalabilidad: los usuarios del mismo tipo suelen tener los mismos privilegios. Cómodo: los usuarios cambian más que los privilegios que tienen las distintos clases de usuarios.

104 Capabilities Control de acceso basado en capablities: El sujeto presenta un capability junto con su petición para realizar una operación de acceso. La capability puede ser un certificado firmado, un ticket, una secuencia pseudo-aleatoria, etc. Facilita la delegación de privilegios y la escalabilidad. Dificulta la revocación de privilegios y la auditoría (quién puede hacer qué en un momento dado).

105 Autorización en el WWW: OAuth OAuth : Propósito: autorización para usar APIs de terceros sin dar las credenciales. El usuario permite a un tercero acceder a ciertas operaciones del API de un servicio web, sin darle tu contraseña. Usa timestamps, nonces y firmas digitales. Ejemplos: Twitter, YouTube.

106 Imagen c Google Autorización en el WWW: OAuth

107 ABAC Control de acceso basado en atributos: Un atributo del sujeto le autoriza a acceder a un recurso. Por ejemplo: edad, nacionalidad, etc.