Clase 11 Javier Echaiz D.C.I.C. – U.N.S. jechaiz [email protected] JAVIER ECHAIZ

Clase 11

Javier EchaizD.C.I.C. – U.N.S.

http://cs.uns.edu.ar/[email protected]

JAVIERECHAIZ

http://cs.uns.edu.ar/~jechaiz

2

Seguridad en Sistemas: Protección en Sistemas OperativosSeguridad en Sistemas: Protección en Sistemas Operativos

Protección en Sistemas OperativosProtecció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 HistoriaUn 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 ProtegerObjetos 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)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.

PUEDEN

COMBINARSE

6



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



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



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)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



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



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ímite se fija el 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



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



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



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



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



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 GeneralesProtecció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 GeneralesProtecció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 ArchivosMecanismos 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ónFormas 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 PermissionsSingle 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 UsuariosAutentificación de Usuarios

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.

Fundamental poder probar que alguien es quien dice ser!

23


Ataques a PasswordsAtaques 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)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



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



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.

Documents

Clase 11 Javier Echaiz D.C.I.C. – U.N.S. jechaiz [email protected] JAVIER ECHAIZ