Curso MIT "Seguridad de sistemas informáticos". Lección 4: "Compartir privilegios", Parte 1

Instituto de Tecnología de Massachusetts. Conferencia Curso # 6.858. "Seguridad de los sistemas informáticos". Nikolai Zeldovich, James Mickens. Año 2014

Computer Systems Security es un curso sobre el desarrollo e implementación de sistemas informáticos seguros. Las conferencias cubren modelos de amenazas, ataques que comprometen la seguridad y técnicas de seguridad basadas en trabajos científicos recientes. Los temas incluyen seguridad del sistema operativo (SO), características, gestión del flujo de información, seguridad del idioma, protocolos de red, seguridad de hardware y seguridad de aplicaciones web.

Lección 1: "Introducción: modelos de amenaza" Parte 1 / Parte 2 / Parte 3
Lección 2: "Control de ataques de hackers" Parte 1 / Parte 2 / Parte 3
Lección 3: “Desbordamientos del búfer: exploits y protección” Parte 1 / Parte 2 / Parte 3
Lección 4: “Separación de privilegios” Parte 1 / Parte 2 / Parte 3

Hoy hablaremos sobre compartir privilegios, ya que terminamos con desbordamientos de búfer en cierto nivel, pero volveremos a ello. No hablaremos sobre los detalles de cómo usar los desbordamientos del búfer, pero pasaremos a reducir este problema y hablaremos sobre cómo desarrollar un sistema en el que los desbordamientos del búfer no sean un gran problema para usted, como otras vulnerabilidades.



Por lo tanto, hoy hablaremos sobre compartir privilegios como un método que le permite crear un sistema más seguro, y en los materiales de la conferencia mencionamos un servidor web llamado OKWS . Este no es el ejemplo más revelador de la separación de derechos, pero el sistema está bien descrito allí para comprender cómo funcionan todas sus partes. Pero esto no significa que deba ir ahora mismo, descargue OKWS e inicie su sitio.

Entonces, antes de profundizar en los detalles de los permisos OKWS y Unix, veamos qué es el intercambio de privilegios y por qué es una buena idea. La semana pasada, James demostró que si escribe un programa en C, casi inevitablemente tendrá algo malo o incorrecto. El problema es que si tiene una aplicación lo suficientemente grande y hay algún tipo de vulnerabilidad, los atacantes pueden conectarse al programa, enviar solicitudes a esta aplicación, engañarla y hacer las cosas "malas".

Cualquier aplicación tiene privilegios de acceso. Esto significa que incluye muchos datos que se pueden obtener con el acceso. Incluso puede eliminar estos archivos, como lo hicieron en el laboratorio número 1. El problema es que una vulnerabilidad en esta gran aplicación podría permitir que un atacante modifique cualquiera de estos datos u obtenga suficientes privilegios para administrar el programa si no tiene cuidado.
En esta conferencia, veremos qué intenta compartir los privilegios. Vale la pena tomar el programa, dividiéndolo en partes y asegurándose de que cada uno de los elementos individuales tenga solo los privilegios necesarios para realizar correctamente su trabajo.



A la izquierda, tenemos un programa de 3 partes, y a la derecha, datos, que también constan de tres partes. Los privilegios asignados correctamente significan que cada parte de la aplicación tiene acceso solo a su parte de los datos. Y si tenemos una vulnerabilidad en el programa X, entonces nos permitirá tomar el control de solo una parte de los datos y no podremos afectar los datos en otras dos partes.
Entonces, esta idea de compartir privilegios es extremadamente fuerte. No sirve para afectar específicamente el problema de desbordamientos del búfer u otras vulnerabilidades; son simplemente requisitos generales para la arquitectura de los productos de software para garantizar que las vulnerabilidades en un lugar del sistema no afecten a sus otras partes. La separación de privilegios se usa bastante ampliamente. Por lo tanto, para garantizar el aislamiento de los componentes dentro de un programa, a menudo se utilizan máquinas virtuales.

Puede tomar su sistema grande y dividirlo en un grupo de máquinas virtuales para aislar las partes individuales, pero también puede usar Unix para realizar este aislamiento con "corte". Unix proporciona bastantes mecanismos que OKWS realmente utiliza para separar privilegios.

Muchas aplicaciones en realidad utilizan prácticas para compartir privilegios. Ustedes probablemente usaron SSH, o "shell seguro", con bastante frecuencia. Este es un protocolo de red que se utiliza para controlar de forma remota el sistema operativo y transferir archivos. Utiliza el uso compartido de privilegios en muchos de sus componentes para garantizar que sus claves de cifrado no se desenreden y que el servidor no se vea comprometido. El navegador web Chrome es más relevante para usted, en el que el uso compartido de privilegios también se implementa bastante ampliamente. Entonces, si hay algún tipo de "error" en Chrome, el adversario no podrá tener el control total sobre su computadora.

Este es un resumen muy breve de lo que es compartir privilegios y por qué OKWS es un ejemplo interesante. Sin embargo, él es más un ejemplo vívido que una pieza importante de software.

Entonces, OKWS , como mencioné, usará permisos de Unix y algún tipo de mecanismo de Unix para separar los diversos componentes. Es importante para nosotros entender cómo funcionan los mecanismos de seguridad de Unix. Unix como herramienta para compartir privilegios es importante no solo para comprender OKWS , sino que, como cualquier otra herramienta de aislamiento, como UID , VM , contenedores o cualquier tecnología similar, le permite comprender los detalles del proceso. Debido a que hay muchas partes complejas del proceso de obtención de derechos de acceso, y puede tratar con un atacante que aprovechará la vulnerabilidad de cualquiera de estas partes. Por lo tanto, analizaremos Unix con suficiente detalle para comprender qué es y cómo debería verse en un mecanismo de seguridad en particular.

Históricamente, Unix ha sido el mejor ejemplo de cómo construir un mecanismo de seguridad. Su mecanismo de seguridad surgió en el proceso de satisfacer la necesidad de separar a los usuarios entre sí en el mismo sistema Unix. Al mismo tiempo, se creía que hay un grupo de usuarios que usan la misma computadora, y usted necesita mantenerlos separados unos de otros. Por lo tanto, este no es necesariamente un mecanismo de propósito general, pero sigue siendo uno de los más comunes y ampliamente utilizados. Entonces, Chrome está tratando de usar muchos mecanismos para compartir privilegios de Unix.

Cuando piensa en un mecanismo de protección, debe pensar en sus principios, lo que significa que hay alguien con privilegios o derechos, y Unix inicia o respalda estos derechos. Por lo tanto, creo que el tema o tema de Unix es un proceso, ya que un proceso es compatible, porque cada operación o solicitud que consideramos desde un punto de vista de seguridad debería permitir o negar algo. Esta será probablemente la operación llamada por el proceso al hacer la llamada al sistema syscall . Lo que importa aquí es cómo describimos qué privilegios tiene este proceso.

A continuación, hay un objeto que nuestro proceso actúa como un sujeto. Puede modificar objetos, leerlos, observarlos. Hay muchos objetos en el sistema operativo que debe preocuparse por proteger. ¿De qué objetos crees que deberíamos preocuparnos?

Audiencia: sobre archivos!

Profesor: correcto, sobre archivos y directorios. Que mas



Audiencia: ¡ Acerca de los sockets de red!

Profesor: sí, genial con los enchufes de red. ¿Hay algo más en nuestro sistema?

Audiencia: otros procesos.

Profesor: Eso es correcto. De hecho, esto es similar a lo que debe cuidar la aplicación o el usuario, pero hay varios componentes internos del sistema que también debe proteger. Por lo tanto, el proceso en sí no es el sujeto que hace que el sistema llame, también es algo sobre lo que otro proceso puede actuar. Puede matarlo o crear uno nuevo. Por lo tanto, debe averiguar cuáles son las reglas para percibir un proceso como un objeto que puede ser manipulado. ¿Qué otras cosas nos pueden preocupar?

Audiencia: variables de entorno.

Profesor: Creo que probablemente no sean un tema que pueda cambiar en el sentido de administrar OC y tener algún tipo de política de seguridad. Creo que las variables de entorno son solo una especie de estado de un proceso contenido en la memoria. Pero, creo que, en general, nos importa esta parte del proceso, que está contenida en la memoria: variables de entorno, pilas, argumentos, esto también es bastante importante. Probablemente, en la memoria del proceso hay muchas cosas que son sensibles a la interferencia externa. Que mas

Público: descriptores de archivos en general.

Profesor: hay otra circunstancia interna que es de gran importancia. Los archivos que están en el disco deberían preocuparnos. Pero todavía existe una herramienta operativa como un descriptor de archivo, que OKWS intenta utilizar ampliamente, y veremos cuáles son. ¿Qué otras cosas te gustaría proteger en el sistema operativo?



Audiencia: hardware o hardware.

Profesor: sí, el hardware requiere protección no menos que las cosas abstractas que nos proporciona el sistema operativo, porque no queremos que nuestro procesador se "congele" por alguna razón.

Público: ¡También debes pensar en proteger los periféricos!

Profesor: ¡Oh sí! Entonces, dispositivos adicionales, tiene razón, especialmente en una computadora de escritorio, hay muchas cosas innecesarias: una unidad USB, una cámara web, probablemente la pantalla en sí misma; querrá proteger algo de esto, porque las aplicaciones relacionadas con ellos no deberían "dar un paseo" »Por toda la pantalla.

Creo que, de hecho, todos estos objetos no están en el lado del servidor, sino que están bastante cerca. En su teléfono, el micrófono probablemente también sea un objeto muy importante, que también desea proteger.

Pero dejaré esta lista, porque en lo que sigue hablaremos principalmente sobre aplicaciones de servidor, pero tiene toda la razón sobre la lista de objetos. Creo que para OKWS esta es probablemente una lista más o menos exhaustiva de cosas que podríamos proteger, o al menos que utiliza OKWS .

Entonces, hablemos sobre cómo el núcleo del sistema operativo decide cuándo un proceso puede hacer algo con cualquiera de estos objetos. Por lo tanto, a un nivel alto, pensamos principalmente en el proceso como una entidad que tiene los privilegios otorgados por este principio, y el principio en el sistema Unix es algo bastante complicado.

Hay algo llamado ID de usuario , que es un entero de 32 bits. Hay una ID de grupo , que también es un número entero de 32 bits. De hecho, no hay una razón particular por la que deberían ser diferentes.



Sería bueno que solo formaran un conjunto único de enteros de 32 bits, pero, desafortunadamente, Unix los divide en dos categorías. Hay enteros de ID de usuario y enteros de ID de grupo . Cuando hablamos de un proceso que tiene ciertos privilegios, nos referimos a un proceso asociado con un cierto valor uid . Por lo general, un proceso tiene un uid , así como una lista de identificadores de grupo de gid que tiene el proceso. Por razones históricas, sucedió que se combinan en un gid y luego se combinan en una lista de otros identificadores. En términos generales, un proceso puede ejercer los privilegios representados por todos estos identificadores. Entonces, si uid proporciona acceso a algo, entonces el proceso puede hacer cualquier cosa con él.

Ahora hablemos de archivos, directorios y otros tipos de objetos. Entonces, ¿qué sucede con los archivos, o más bien, cómo crear permisos Unix para trabajar con archivos? Todo es relativamente simple con los archivos; le preocupan las operaciones que se pueden hacer con ellos: lectura, escritura, posiblemente ejecución, así como la capacidad de cambiar los permisos mismos u otras propiedades de seguridad.

Audiencia: rompiendo lazos!

Profesor: sí, romper enlaces, desvincular : ¿cuál cree que es la propiedad del archivo o directorio en sí? En realidad, esta distinción es un poco poco clara. Cuando Unix piensa en eliminar un archivo, se trata más del directorio, porque en Unix, el archivo realmente es un inodo o un inodo. Por lo tanto, en Unix, puede tener varios enlaces duros a inodos y cuando desconecta un nombre de archivo Unix específico usando unlink, en realidad destruye solo uno de los nombres de archivo, pero puede tener otros nombres y otros enlaces. De hecho, es importante si puede cambiar el directorio que apunta al archivo y, al mismo tiempo, no hacer nada con el inodo del archivo. Por lo tanto, las operaciones de desvinculación , vinculación , cambio de nombre y creación son operaciones asociadas con un directorio, por lo que crear afecta tanto al directorio como al nuevo archivo. Por lo tanto, debemos averiguar qué reglas se aplican allí.



Para decidir que alguien puede leer o escribir un archivo, vamos a insertar algunos permisos, o bits, en el archivo inode . En Unix, cada inodo que finalmente es un archivo o directorio tiene varios campos interesantes por razones de seguridad. Aquí está la ID de usuario y el identificador del grupo, que, como decimos, posee el archivo o posee el directorio. Por lo tanto, puede administrar todos los archivos en su directorio de inicio debido al hecho de que Unix tiene su uid .
Unix también tiene un conjunto de bits de permiso que se pueden considerar como parte de la matriz, en el diseño básico se ven como r (lectura), w (escritura) yx (ejecución). Podemos especificar estos permisos para varias entidades, y en Unix se especifican para el propietario propietario , es decir, para el inodo uid , para el grupo de grupos al que pertenece el archivo dado, es decir, para gid y para todos los demás, otros .

Puede completar esta matriz binaria 3 por 3, donde 1 significa permiso para realizar una determinada acción y 0 prohíbe su ejecución:



Así es como Unix almacena los permisos. Hay una forma tradicional de codificar estas cosas que verá con frecuencia y que probablemente valga la pena mencionar. En Unix, esta matriz está codificada como un número octal, por lo que cada fila aquí debe considerarse como un número base de 8, por lo que nuestra matriz en esta codificación se verá así: r es 4 bits, w es 2 bits, x es 1 bit, respectivamente, propietario - son 6 bits, y el grupo y el otro contienen 4 bits.



A menudo verá tales designaciones en los materiales de la conferencia, por lo que puede decir que este archivo tiene una resolución de 6, 4, 4, es decir, el propietario puede leer y escribir el archivo, y el propietario del grupo y otros solo pueden leerlo.

Estas anotaciones nos dicen cuándo leer, escribir y ejecutar un archivo. ¿Qué pasa con el cambio de permisos para este archivo? Esta no es una pregunta justa, pero ¿qué piensan ustedes acerca de esto? ¿Cómo deberíamos decidir que alguien debería poder cambiar estos permisos porque esto también podría ser necesario? ¿Alguna idea sobre esto?

Público: si esta persona tiene acceso al archivo?

Profesor: quizás también depende de los privilegios de acceso. Por otro lado, puede crear un archivo regrabable regrabable que desee compartir con alguien para que pueda leer, agregar y modificar su archivo, pero también significa que puede cambiar repentinamente los permisos para que el archivo no sea regrabable o asignado solo para mi mismo.

Por lo tanto, los creadores de Unix decidieron que si tiene un archivo, es decir, su uid corresponde al uid ingresado en el archivo, entonces, de manera predeterminada, puede cambiar los permisos. De lo contrario, no puedes. Entonces, si solo tiene gid y este grupo tiene todos los permisos en el archivo, aún no puede cambiar los permisos para este archivo. Simplemente puede leer, reescribir, hacer cualquier cosa con él, pero sin uid no puede cambiar los permisos.

Los directorios de Unix siguen las mismas reglas. Por lo tanto, separar las entradas de unlink y unlink en un directorio significa que tiene permiso para escribir en este directorio. Si desea cambiar el nombre de un archivo, probablemente necesite tener acceso de escritura al directorio de donde lo obtiene y acceso de escritura al directorio en el que lo colocó. En algunos casos, los enlaces duros pueden causar problemas, y en los materiales de la conferencia se destacan estos detalles.

De hecho, hay otra operación interesante en el catálogo: la búsqueda. Gracias a ella, simplemente puede encontrar el archivo en el directorio. Los codificadores Unix ejecutan permisos como la capacidad de implementar una búsqueda de directorios, por lo que tener permiso de ejecución para un directorio realmente significa poder buscar un nombre de archivo específico. Es posible que no necesite tener permiso para que el directorio busque el nombre del archivo, pero si no tiene permiso de lectura, no podrá ver el contenido del directorio, es decir, buscar el archivo. Esto es útil en algunas situaciones en las que necesita restringir acciones con algunos archivos u ocultarlas al usuario.

Veamos un ejemplo. ¿Qué sucede en Unix si ingreso el comando de apertura ("/ etc / password") ? ¿Qué comprueba el núcleo del sistema en mi nombre cuando le ordeno hacer una llamada al sistema?

Audiencia: ¿Verifica si tiene permiso para ejecutar, etc.?

Profesor: Sí, hasta cierto punto este es el caso. Necesito hacer algo, etc.

Audiencia: ¡ y luego ejecute la barra diagonal especificada!

Profesor: sí, ¿realmente necesito mirar a qué apunta / etc ? Por lo tanto, si no descubro los permisos de root : derechos, esto no funcionará.

Público: entonces necesita leer / etc / contraseña .



Profesor: sí, eso tiene sentido. Aquí hay un pequeño rompecabezas para ti. Suponga que MIT crea un grupo para todas las personas asociadas con el curso 6.858, y otros grupos para todos los TA en MIT, que en la terminología de Unix se designa como gids , pero no se incluyen en el grupo 6.858 TA por algunas razones tontas. ¿Cómo puedo crear un archivo que estará disponible solo para el grupo de TA 6.858?

Supongamos que tengo 6.858 gid y TAs gid, pero solo puedo insertar un gid en el archivo.

Público: no podría hacer esto, porque aquí puede tener TA, no 6.858 TA.

Profesor: sí, eso es verdad. Aunque hay estudiantes en el grupo 6.858 que son TA de otras clases, entonces quizás esto no sea realmente genial. Pero, sin embargo, intentemos de alguna manera hacer las intersecciones de estos grupos. Para hacer esto, podemos usar el mecanismo de permiso.
/foo/bar/grades , foo , gid 6.858 . , , /foo . /bar , gid TAs, . /foo/bar/ , grades . , .



: , , , , 6.858 gid, TA - - 6.858 ?

: , . , , , Unix , , , , , . , MACS — mandatory accesscontrol systems, . , , : , . . , - .

Unix , , , TA - , Unix . , - . - , Unix , , . , , . , , , . , . Unix.

, , , , - , . - , , , .

, , Unix.

, — . OKWS , Unix . Unix , . , «» , .

, : , . , . - , , Unix – , , , , .

– Unix - , .

OKWS , . , , , - , . , , , - . - , .

, . , , .

? ? ? Unix . , , – Unix , ptrace .



. , , , , , . , , web , gid TAs, .

, , . userid . ptrace — uid uid .

ptrace Linux . , , , - , , , . - . , ID.

27:50

:

Curso MIT "Seguridad de sistemas informáticos". 4: « », 2


.

Gracias por quedarte con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendándolo a sus amigos, un descuento del 30% para los usuarios de Habr en un análogo único de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

Dell R730xd 2 veces más barato? ¡Solo tenemos 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV desde $ 249 en los Países Bajos y los Estados Unidos! Lea sobre Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?