Clase 11 Javier Echaiz D.C.I.C. – U.N.S. cs.uns.ar/~jechaiz je@cs.uns.ar

1. JAVIER ECHAIZ Protección en S.Os. (1) Clase 11 Javier Echaiz D.C.I.C. – U.N.S. http://cs.uns.edu.ar/~jechaiz je@cs.uns.edu.ar

2. Protección en Sistemas Operativos Veremos las contribuciones en cuanto a seguridad que nos brindan los Sistemas Operativos Veamos qué y cómo puede proteger la Seguridad un S.O

3. Un poco de Historia • Originalmente no habia S.O. Usuario = S.O. • Primeros O.S.s: ejecutivos: loaders, linkers, etc. • Multiprogramación. Nuevo rol del S.O. • Surge protección entre procesos de un mismo o diferentes usuarios.

4. Objetos a Proteger • memoria • procesador • dispositivos I/O compartidos, e.g. discos • dispositivos I/O compartidos serialmente, e.g. impresoras • programas compartidos • datos compartidos Los Sistemas Operativos tuvieron que hacerse cargo de la seguridad de estos objetos cuando asumieron la responsabilidad del sharing controlado.

5. Métodos de Seguridad (1) La base de la protección es la separación. Separar los objetos de un usuario de los objetos de otros usuarios. • Esta separación puede hacerse de 4 formas en un S.O: • Separación Física. Los procesos usan diferentes objetos físicos. Ej: una impresora por usuario. • Separación Temporal. Procesos con distintos requerimientos de seguridad corren en diferentes tiempos. • Separación Lógica. Los usuarios trabajan como si no existiera ningún otro proceso. • Separación Criptográfica. Los procesos protegen su entorno haciéndolo ininteligible desde su exterior. COMBINARSE PUEDEN

6. Métodos de Seguridad (2) Separación es solo la mitad de la respuesta. Queremos que los usuarios compartan algunos objetos. Protecciones en diferentes niveles. • Sin Protección. Apropiados si hay separación física/temporal. • Aislamiento. Cada proceso tiene su espacio de direcciones, archivos, etc. • Compartir Todo o Nada. El dueño de un objeto lo declara público o privado. Lo accede todo el mundo o nadie. • Compartir via Limitación de Acceso. El control de acceso se implementa para cada usuario y para cada objeto.

7. Métodos de Seguridad (3) Protecciones en diferentes niveles. (sigue) • Compartir por Capacidades. Extensión de Compartir por limitación de acceso: creación dinámica de objetos compartidos. El grado de sharing dependerá del objeto, entorno o del owner. • Limitar el Uso de un Objeto.No solo se limita el acceso sino también el uso de un objeto. Ej: permiso de lectura pero no de escritura sobre un archivo. • Nuevamente los modos fueron agrupados desde el más fácil al más difícil de implementar.

8. Métodos de Seguridad (4) La Granularidad del control es también muy importante. Por ejemplo los datos de un archivo se pueden controlar al nivel del bit, byte, word, registro o archivo. A mayor granularidad más fácil implementación pero menor control. Veamos ahora tipos específicos de protección según el tipo de objeto a proteger.

9. Protección de Memoria y Direccionado (1) El problema más obvio de la multiprogramación es la protección de memoria. Protecciones de Hardware (sin costo adicional para el S.O). Vallado (Fence) Es la protección de memoria más simple y fue introducida en los sistemas monousuario para evitar que un programa defectuoso destruya parte del S.O residente. Se puede implementar mediante una dirección de memoria predefinida o mediante un registro, fence register (más flexible). Protege al S.O pero no a los usuarios!

10. Protección de Memoria y Direccionado (2) Relocación Es el proceso de tomar un programa como si comenzara en la dirección 0 y cambiar todas las direcciones para reflejar las direcciones actuales. A veces se usa un relocation factor para marcar la dirección inicial del programa. Se puede utilizar el fence register para implementarlo.

11. Protección de Memoria y Direccionado (3) Registros Base/Límite El registro de relocación provee una dirección base o de comienzo. Todas las direcciones del programa son desplazamientos a partir de la dirección base. Registro Base. Con el Registro Límitese fijael límite superior del direccionado de un usuario. Ahora se puede proteger a un usuario de otro, pero todavía no se puede proteger de sí mismo. Para solucionar este problema se pueden usar más pares de registros… ideas?

12. Protección de Memoria y Direccionado (4) Arquitectura Etiquetada Otro problema del esquema base/límite es la continuidad de las áreas de memoria. Además la comparten todo o nada. La idea de este esquema es la de marcar cada word de memoria con permisos usando bits extras. Estos bits serán inicializados en modo privilegiado. Alternativamente se puede “etiquetear” un grupo de direcciones. Memoria hoy es barata, el problema de implementar ésta técnica son las costosas modificaciones en los S.O.s.

13. Protección de Memoria y Direccionado (5) Segmentación (1) Los últimos dos métodos pueden implementarse no tan costosamente, sobre arquitecturas comunes. Esta técnica es de 1965 y resultó ser sumamente útil para el direccionado y trae consigo el bono de la protección de memoria. En este esquema el programa se divide en piezas llamadas segmentos. Independencia lógica. Se direcciona así: <nombre de segmento, offset>. El S.O. mantiene una tabla de segmentos (una por proceso) para convertir estas direcciones a direcciones reales.

14. Protección de Memoria y Direccionado (6) • Segmentación (2) • Este ocultamiento de direcciones brinda 3 ventajas al S.O.: • El sistema operativo puede mover el segmento a donde quiera, incluso durante la ejecución del programa. Solamente tiene que cambiar la tabla de segmentos. • Puede swappear a otro dispositivo (disco) un segmento no utilizado. • Toda dirección debe ser “traducida” por el S.O. Oportunidad para chequear protecciones.

15. Protección de Memoria y Direccionado (7) • Segmentación (3) • A cada segmento se le puede dar diferentes permisos. Ej: RO data, EO code, etc. • La segmentación ofrece lo siguiente a la protección de RAM: • Cada ref. a memoria es checkeada (permisos). • Distintos tipos de clase de datos puede tener distintos niveles de protección. • Dos o más usuarios pueden compartir el mismo segmento. • Un usuario no puede direccionar memoria de segmentos no permitidos. Problemas de implementación/eficiencia?

16. Protección de Memoria y Direccionado (8) Paginado En este caso una dirección es de la forma: <página, offset> El programa se divide en segmentos iguales: páginas y la memoria se divide en bloques de 1 página: page frames. Las páginas no siguen asignaciones lógicas. Esto es malo para la protección. Why? Paginado/Segmentado En este caso se combina lo mejor de los dos mundos: eficiencia de implementación del paginado y la protección posible en sistemas segmentados.

17. Protección de Acceso a Objetos Generales • La protección de memoria es de cierta forma sencilla, pues cada acceso debe necesariamente pasar por algún mecanismo de hardware. • Hay objetivos complementarios de protección: • Controlar cada acceso. Queremos poder revocar los permisos de algún usuario. • Permitir el menor privilegio. El sujeto debe tener acceso al menor número de objetos necesarios para realizar una tarea. • Verificar uso aceptable. No quiero solo acceso si/no, quiero también verificar que el uso de un objeto sea apropiado.

18. Protección de Acceso a Objetos Generales Mecanismos de Control de Acceso • Directorio. Lista de permisos: una por usuario. • ACL (Lista de Control de Acceso). Lista de permisos: una por objeto. • Matriz de Control de Acceso. Tabla usuarios/objetos. • Capacidad. Ficha que le da accesos a un dado objeto. Pionero de Kerberos. Transferencia o propagación de acceso. • Control de Acceso orientado a Procedimientos. Fuera del S.O. Procedimiento extra, por lo tanto hay información escondida.

19. Mecanismos de Protección de Archivos Existen muchos programas y mecanismos de protección de archivos. Veremos únicamente los más importantes/conocidos. Formas Básicas de Protección Todos los S.O.s multiusuario tienen algún mecanismo de protección para evitar problemas por descuido, desconocimiento o mala intención.

20. Formas Básicas de Protección • All-None. • IBM, no hay protección para nadie y todo es público. • Protección: confianza ciega, ignorancia. Comentarios? • Inaceptable!!! • Grupo de Protección • Grupos de usuarios que tienen cierta relación. Ej: UNIX. • Política de selección del grupo: necesidad de compartir. • Mejor que el anterior pero introduce algunos problemas.

21. Single Permissions • Password/Token. • Se pueden usar para proteger archivos. Ej: S.O. solicita passwd en cada acceso al archivo. No hay problema con los grupos. Pero: pérdida, revelación, revocación. • Permiso Temporal • Permiso suid (set userid). Permite acceso a un usuario que de otra forma solo podría acceder como root. • Protección por Objeto/Usuario • El principal problema de estos problemas está en la creación de grupos “útiles”. Ej: VMS.

22. Autentificación de Usuarios Fundamental poder probar que alguien es quien dice ser! • Uso de Passwords • Para que funcione como se espera el password debe ser únicamente conocido por el usuario y el sistema. • Sistemas “Reveladores”. • Información de Autentificación Adicional.

23. Ataques a Passwords • Brindan protección relativamente limitada: pocos bits. • Algunas formas de obtener el password de un usuario: • Probar todos los passwords. • Probar posibles passwords. • Probar passwords probables para este usuario. • Buscar en el archivo de passwords. • Preguntarle al usuario. • etc.

24. Ataques a Passwords (1) Ataque Exhaustivo/Fuerza Bruta Probar todos los posibles passwords. Ej: 27^n en español para passwd de n letras mayúsculas. En gral la búsqueda se agota mucho antes.  Passwords Probables Piensen en una palabra… Es larga, poco conocida y difícil de pronunciar? NO! Atacante prueba primero con palabras cortas y que sigan ciertas “costumbres”.

25. Ataques a Passwords (2) • Passwords Probables para un Usuario • En general el password tiene un significado para uno. Trabajo, película favorita, etc. Ej: Morris! • Búsqueda de archivo (plano) de Passwords • Si el atacante lo encuentra: pan comido… Nada de andar probando/adivinando. Dump de memoria, backups, etc…  • Archivo de Passwords Encriptado • Más seguro que el anterior. Funciones Hash. Ej: UNIX • salt.

26. Ataques a Passwords (3) • Preguntarle al Usuario su Password • Muy fácil. Visto en las primeras clases con ejemplos. • Un buen Password • No solo A-Z. • Largo (6 o más caracteres). • Evitar palabras de diccionarios. • Password no probable. • Cambiar passwd regularmente. • No escribirlo. • No divulgarlo.