Algunas preguntas básicas sobre la seguridad del kernel de Linux [cerrado]


8

No sé mucho sobre el kernel de Linux, y tengo algunas preguntas.

  1. ¿Cuál es el propósito principal de separar la memoria del núcleo de la memoria del espacio del usuario? ¿Para asegurarse de que una aplicación de usuario no pueda hacer nada malo al núcleo?

  2. ¿De cuántas maneras hay una aplicación de nivel de usuario para transferir el control al kernel? Lo que se me ocurre incluyen (1) invocar una llamada al sistema, (2) asignar memoria al kernel (pero creo que mmap () también es una llamada al sistema) y (3) cargar un módulo del kernel (pero supongo que lsmod también invoca alguna llamada al sistema). ¿Estoy en lo correcto? ¿Hay alguna otra forma que me perdí?

  3. ¿Cuántas formas de atacar el núcleo? ¿Puedo tener algunos detalles breves sobre ellos?

  4. Si obtengo el privilegio de root, ¿significa que controlo completamente el kernel? A saber, ¿puedo hacer lo que quiera con el kernel y el hardware? ¿O todavía tengo un poder limitado en el núcleo?

Realmente agradecería que alguien pueda ayudarme a encontrar la respuesta a estas preguntas.


1
Aquí hay algunas buenas preguntas, pero ¿podría dividirlas en preguntas más específicas con un tema principal por pregunta?
Caleb

Respuestas:


5

Trataré de responder preguntas lo más brevemente posible. Las preguntas que hace generalmente se abordan en los cursos introductorios de sistemas operativos en las universidades, pero supongo que no ha tomado dicho curso.

  1. El aislamiento de la memoria para los procesos de espacio de usuario es muy deseable, no solo para proteger el núcleo de programas maliciosos de espacio de usuario, sino también para proteger los programas de espacio de usuario entre sí. Esto generalmente se conoce como memoria virtual . También facilita la implementación de la paginación, lo que también es deseable por otras razones (fragmentación más simple, enlaces / cargadores más simples, etc.).

  2. Interrupciones (no todas tienen el control de una aplicación de nivel de usuario). Renunciar al procesador también elimina el "control" del proceso (por ejemplo, waitetc., que también son llamadas al sistema). El kernel podría decidir no programar una aplicación.

  3. Esa es una pregunta muy amplia. El kernel con llamadas al sistema mal implementadas es vulnerable. La capacidad de escribir en la memoria física sería otra forma. Existen otras vulnerabilidades que pueden surgir de instrucciones mal implementadas (por ejemplo, vulnerabilidad sysret en procesadores Intel).

  4. Los privilegios de root no son lo mismo que los privilegios de kernel. Una aplicación que se ejecuta como usuario root todavía usa memoria virtual, todavía tiene que hacer llamadas al sistema, todavía tiene que obedecer las otras reglas que cualquier aplicación de nivel de usuario debe cumplir.

Si desea que le proporcione más detalles sobre algunas de las respuestas, hágamelo saber.

Si alguien puede mejorar algunas de las respuestas, no dude en señalarlo.


Gracias por su respuesta. Usted dijo "Interrupciones (no todas tienen el control de una aplicación de nivel de usuario)", lo que significa que solo las interrupciones de software tienen el control del nivel de usuario, mientras que las interrupciones de hardware no lo están. ¿Es correcto?
hebothu

Creo que el espacio de usuario tiene que pedirle al kernelspace que le permita manejar algunas de las interrupciones. Entonces, el kernel básicamente todavía tiene el control de las interrupciones. En particular, el núcleo aún maneja las interrupciones y las pasa al espacio de usuario si una aplicación de espacio de usuario se preocupa por recibirla. Busque Linux UIO.
mtahmed
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.