Este documento presenta una discusión sobre el hardening del kernel de Linux. Explica que el kernel de Linux no tiene protecciones contra muchos tipos de ataques y deja que los usuarios hagan lo que quieran en la memoria. Luego discute la necesidad de protegerse contra vulnerabilidades como desbordamientos de búfer y carreras de archivos temporales mediante el uso de controles de acceso más estrictos como DAC vs MAC, protección de memoria como ASLR y DEP, y enfoques como GRSecurity & PAX y SELinux.

1. Linux Kernel Hardening
Alvaro Soto ( @alsotoes )
http://headup.ws - alsotoes@gmail.com
Friday, February 15, 13

2. Alvaro que?
• Developer
• Infraestructura // Arquitecturas OpenSource
• Hardening & Tuning geek... freak
• Linux (Gentoo Lover)
• Kernel Vanilla Sources
Friday, February 15, 13

3. Por que hardening al
Kernel ?
• Por triste que suene... el Kernel de Linux no posee
herramientas contra muchos tipos de ataques.
• En cuanto a la memoria, por defecto deja hacer lo
que se antoje.
• Y en controles de acceso DAC estrictamente no
cuenta como esquema de seguridad... avanzado
Friday, February 15, 13

4. Estatus de
vulnerabilidades
Integer Overflows
Buffer Overflows
Race/tmpfiles
Race/non-tmpfiles
Bad malformed data handling
Lack of environment checks
Generic bugs and bad design
Kernel/Generic
Kernel/Buffer Overflow
0 12.50 25.00 37.50 50.00
USN Analysis
Friday, February 15, 13

5. Entonces:
¿ Es seguro el Kernel de Linux ?
¿ Que tan seguro es ?
Friday, February 15, 13

6. Entonces:
¿ Se puede asegurar ?
¿ Que tanto ?
Friday, February 15, 13

7. Estatus de
vulnerabilidades
Integer Overflows
Buffer Overflows
Race/tmpfiles
Race/non-tmpfiles
Bad malformed data handling
Lack of environment checks
Generic bugs and bad design
Kernel/Generic
Kernel/Buffer Overflow
0 12.50 25.00 37.50 50.00
USN Analysis
Friday, February 15, 13

8. Contra que necesitamos
protección?
?
Friday, February 15, 13

9. Contra que necesitamos
protección?
Friday, February 15, 13

10. Contra que necesitamos
protección?
Friday, February 15, 13

11. Contra que necesitamos
protección?
• Controles de acceso
• DAC v/s MAC..... no mas chmod 777 a todo lo que se pueda.
• El usuario root es omnipotente.
• Memoria.
• Modificación del address space.
• Ejecución de codigo arbitrario.
• Filesystem.
• Races (tmp races).
• chroot
Friday, February 15, 13

12. Condideraciones
“básicas”
• De bajo a alto nivel.
• Configurar cada rincón del sistema.
• Estándares y politicas de seguridad.
• Instalar parches de seguridad continuamente.
• Auditar cada acción del sistema.
Friday, February 15, 13

13. RTFM
Friday, February 15, 13

14. DAC v/s MAC
Friday, February 15, 13

15. DAC v/s MAC
• Usuarios no pueden cambiar sus politicas de
seguridad.
• Se puede separar el espacio de trabajo de los
usuarios con distintos contextos.
• Politicas muy bien definidas:
• Usuarios, archivos, directorios
• Memory, Sockets, tcp/udp ports... etc., etc.
Friday, February 15, 13

16. Memory Protection
• DEP (Data execution prevention).
• Se divide la memoria en ejecutable y lectura.
• ASLR (Address space layout randomization).
• Tareas del kernel.
• Posición de las librerias.
• Tareas del usuario (userland stack).
• UNA VIOLACION DE ALGUNA DE ESTAS POLITICAS PRODUCE QUE EL KERNEL
MATE EL PROCESO, CAMBIANDO UN POSIBLE ACCESO POR UN DOS.
Friday, February 15, 13

17. GRSecurity & PAX
V/S
SELinux
Friday, February 15, 13

18. GRSecurity & PAX
• Control de acceso Mandatorio por medio de RBAC definidas en ACL.
• Generación automatica de reglas.
• Proteccion del filesystem con bloqueos de:
• chroot
• mount
• mknod
Friday, February 15, 13

19. SELinux
• Un ejemplo de Mandatory Access Control para Linux.
• Etiquetar todo a lo que necesita aplicar una politica.
• user:role:type:level(opcional)
• Comandos con argumentos extendidos ----->>>> -Z
• ls -Z
• id -Z
• ps -Z
• netstat -Z
Friday, February 15, 13

20. Preguntas ????
Friday, February 15, 13

21. GRACIAS !!!!!
Friday, February 15, 13