--Originally published at Héctor H.F. Blog
Hola a todos, aquí un nuevo post. Ahora les hablaré sobre cómo proteger un sistema operativo, independientemente de la marca (aunque contiene ejemplos de Windows). Para esto, copié y pegué un resumen que hice precisamente hace como dos semanas para otra clase (Sistemas operativos), que a su vez resumí de https://www.cs.columbia.edu/~smb/classes/s06-4118/l25.pdf. Algunos conceptos están algo extraños, así que si alguien no sabe a qué me refiero con algo, para eso están los comentarios.
Seguridad es mantener sin autorización entidades de hacer cosas que tú no quieres que hagan. Se puede dividir en confidencialidad, integridad y disponibilidad. Las características internas de un sistema protegen al SO de los usuarios y los permisos de archivo protegen a los usuarios de otros usuarios, pero esto no es suficiente. Los permisos de archivo están basados en la identidad del usuario (autenticación). Para autenticarse, se pueden utilizar contraseñas: es lo más común, lo más sencillo de adivinar, originalmente eran texto plano, pero ahora usualmente están hasheadas.
Las contraseñas hasheadas funcionan de la siguiente manera: guarda f(PW), donde f no es invertible, cuando el usuario ingresa PW, calcula f(PW) y compara. Para protegerse contra ataques de precomputación, asigna un salt al azar durante el cambio de contraseña y guarda (salt, f(PW, salt)). Los que atacan pueden seguir corriendo programas para adivinar contraseñas, por esto la mayoría de los SO usan control de acceso para proteger estas contraseñas hasheadas.
Otro tipo de autenticación es el challenge/response. Pregunta algo al usuario que nadie más sabe. Si el usuario tiene habilidad para el cálculo, lo hace criptográficamente. El servidor conoce PW y envía un número aleatorio N; ambos lados calculan f(PW, N), donde f es algo parecido a un algoritmo de encriptación.
Los tokens son algún tipo de dispositivo, tal vez hacen challenge/response. Los más populares
Los lectores de huella se están popularizando, aunque los escáneres de iris son tal vez más seguros. Esto es biométrica, y por lo general tiene una tasa de falsos positivos y una de negativos. Trabaja mejor si se almacena localmente (sobre la red, todo es visto como una secuencia de bits). Hay que cuidarse de los ataques de falsificación (spoofing).
Algunas técnicas de ataque son los caballos de Troya, la falsificación de inicio de sesión y software con bugs. Los caballos de Troya consisten en engañar a alguien para que ejecute un programa que hace cosas desagradables. Para protegernos de ellos, no basta con los permisos de archivo, ya que estos virus pueden modificarlos, así que se requiere control de acceso mandatorio (MAC). Una mejor idea es que el SO provea cajas de arena, un entorno donde el programa puede ejecutar pero no puede afectar el resto de la máquina. Una aislación fuerte es fácil: correr el programa en una máquina separada.
Las condiciones de carrera pueden ser un problema de seguridad. Considera un programa privilegiado que checa si un archivo es leíble y entonces trata de abrirlo como root, entonces el atacante puede pasar un symlink, en el intervalo entre las dos operaciones, el atacante remueve el symlink y lo reemplaza con un link a un archivo protegido. El SO debe proveer operaciones atómicas para abrir el archivo como ese usuario.
La suplantación de inicio de sesión es cuando una página o servicio se hace pasar por alguno para obtener usuarios y contraseñas.
Una ruta de confianza es una secuencia iniciada por el usuario que está garantizada para llegar al SO real (por ejemplo: Ctrl + Alt + Del).
Los virus se propagan por sí mismos dentro de una máquina, pero requieren la intervención de un ser humano para infectar otras computadoras. Los gusanos se propagan entre las máquinas, aunque pueden requerir ayuda humana.
¿Cómo se protege el SO? La protección de los archivos puede prevenir la contaminación del SO, pero los gusanos pueden expandirse con permisos del usuario.
Los SO pueden intentar bloquear contenido sospechoso. Es muy complicado de hacer. Windows XP SP2 etiqueta a los archivos descargados, cualquier cosa que esté etiquetada se considera no ejecutable, aunque hay cosas que el usuario quiere que se descarguen.
El Libro Naranja describía un conjunto de niveles seguros del sistema, de D (no seguro) a A1 (formalmente verificado). Los niveles más altos tenían más características y más seguridad.
El modelo de clasificación militar consiste en que los documentos son clasificados en cierto nivel y las personas tienen ciertas autorizaciones, así un usuario solo puede ver documentos que se le autorizaron ver. Los niveles son confidencial, secreto y ultra secreto. Los compartimentos son cripto, subs, noforn (No foreign nationals). Para leer un documento, debes tener al menos un nivel de autorización alto y debes estar despejado para cada compartimento. Los sistemas que soportan esto son conocidos como sistemas de seguridad multinivel.
Los más altos niveles del Libro Naranja demandaban más seguridad, incluyendo buena documentación, diseño estructurado, planes de prueba formales y programadores con seguridad despejada.
El Libro Naranja mezclaba características y seguridad, el criterio común los separaba. También permitía diferentes perfiles de protección, estos decían qué se suponía lograr. La lista de características dice cómo debe hacerse esto. El nivel de seguridad es qué tan confidente debes ser. El modelo de seguridad del Libro Naranja no era interesante comercialmente. Conseguir una evaluación del sistema era caro y consumía mucho tiempo. Los sistemas evaluados se quedaron muy por detrás de los comerciales y fueron más caros. Cosas menores como la conexión a la red no estaban incluidas.
Shadow Hawk es una persona que fue detenida por el FBI. Estuvo descargando software de varios sistemas de AT&T. Fue descubierto al tratar de usar uucp (un sistema de transferencia de archivos/correo electrónico que viene con Unix) para tomar archivos /etc/passwd de otras computadoras. Uucp registró todas las solicitudes de transferencia de archivos. Muchas personas en Murray Hill habían automatizado trabajos que escaneaban los archivos de registro por cualquier cosa sospechosa.
¿Qué hay que registrar? ¿Todo? Esto ocuparía mucho espacio en disco y sería un serio riesgo potencial de privacidad, pero se deben registrar eventos sensibles a la seguridad.
Solaris Basic Security Module (BSM) puede hacer muchas tareas de registro. Algunas categorías son: login/logout, ioctl, file write, eventos de red, mount/unmount, fork, exec, etc. Le da mucho cuidado a la protección de archivos de registro. Pero, ¿se puede procesar toda esta información?
El propósito real de un SO es correr ciertas aplicaciones. El problema no es qué tan seguro es el SO, es qué tan seguras son las aplicaciones (la mayoría de los gusanos no violan la seguridad del SO).
Un SO seguro útil debe facilitar escribir aplicaciones seguras. Esto significa cosas como las útiles cajas de arena. Necesita un modelo de permiso más flexible (DAC es muy simple y MAC, muy restrictivo).
Los SO comerciales no satisfacen estos criterios. Por supuesto, la mayoría de las aplicaciones son diseñadas para las comodidades que tenemos. Siempre tendremos código con bugs, el truco es construir una aplicación y un SO que resistirá ataques y protegerá los activos importantes.
Hasta aquí el resumen y mi post. Por supuesto, la mayoría de las cosas aplican tanto a SO de computadoras como de teléfonos celulares. Espero sus comentarios y nos vemos en mi próxima entrada.
Héctor H.F.
