SELinux bloqueó proactivamente el bug /proc del kernel Linux

El otro día publicamos en una-al-día una nota, en la que reflejábamos la gravedad de un problema recientemente diagnosticado en ciertas versiones del núcleo Linux.

El problema, existente en la rama 2.6 y cocnretamente en las versiones inferiores a la 2.6.17.4, permitía, mediante un sencillo exploit publicado on the wild, a modo de 0day, escalar privilegios en máquinas Linux.

Pues bien. No todos los kernels teóricamente vulnerables terminaron siéndolo. Sirva el ejemplo de seguridad proactiva de Security Enhanced Linux, SELinux, sobre el que habla James Morris en su blog. Referencias adicionales sobre este tema pueden ser consultadas, por ejemplo, en el ISC de SANS, que confirma la inexpugnabilidad de SELinux:

SELinux blocks CVE-2006-3626 (local privilege escalation)

Joshua Brindle has analyzed the recent /proc local privilege escalation vulnerability, CVE-2006-3626, and posted that SELinux targeted policy prevents exploitation.

It’d be an interesting and useful exercise to go back through historical vulnerabilities and determine how many of them would be mitigated by SELinux and similar technologies (Exec-shield, PIE etc.).

Mark Cox wrote an interesting paper, Risk Report: A year of Red Hat Enterprise Linux 4, which mentions that SELinux blocked the Lupper worm (also noting that that the policy version shipped by default would not have blocked a modified version of the worm).

La culpa de esta proactividad la tiene SELinux targeted policy, única en su especie. Este modo de ejecución permite al administrador confinar ciertos procesos críticos bajo el gobierno directo de esta targeted policy, mientras que el resto de procesos quedan bajo la tutela de la seguridad genérica de un sistema GNU/Linux, en el dominio unconfined_t.

Los demonios supervisados por esta política son, habitualmente, dhcpd, httpd (apache.te), named, nscd, ntpd, portmap, snmpd, squid, y syslogd. Toda la información sobre demonios protegidos está en /etc/selinux/targeted/src/policy/domains/program.

selinux

Observad la diferencia entre un Setenforce puesto a 0, y a 1:

Setenforce 0

[jbrindle rhel4-dev ~]$ id
uid=501(jbrindle) gid=502(jbrindle) groups=502(jbrindle)
context=user_u:system_r:unconfined_t
[jbrindle rhel4-dev ~]$ ./h00lyshit /bin/ash.static

preparing
trying to exploit /bin/ash.static

sh-3.00# id
uid=0(root) gid=502(jbrindle) groups=502(jbrindle)
context=user_u:system_r:unconfined_t

(may take a few times to get since it’s a race, clear your cache between
tries)

Setenforce 1

[jbrindle rhel4-dev ~]$ ./h00lyshit /bin/ash.static

preparing
trying to exploit /bin/ash.static

failed: Permission denied

All related denials:

audit(1152957171.464:5): avc: denied { setattr } for pid=6291
comm=»h00lyshit» name=»environ» dev=proc ino=412286986
scontext=user_u:system_r:unconfined_t
tcontext=user_u:system_r:unconfined_t tclass=file
audit(1152957171.465:6): avc: denied { execute } for pid=6292
comm=»h00lyshit» name=»environ» dev=proc ino=412286986
scontext=user_u:system_r:unconfined_t
tcontext=user_u:system_r:unconfined_t tclass=file
audit(1152957171.467:7): avc: denied { execute_no_trans } for
pid=6292 comm=»h00lyshit» name=»environ» dev=proc ino=412286986
scontext=user_u:system_r:unconfined_t
tcontext=user_u:system_r:unconfined_t tclass=file

Así se comporta un sistema operativo seguro ante un incidente desconocido. ¿Te gusta el concepto? ¿Quieres algo así para tu casa, tu oficina o para tu red corporativa?

Descárgatelo. Es gratis.

5 comentarios sobre “SELinux bloqueó proactivamente el bug /proc del kernel Linux

  1. Es por razones como éstas por las que no comprendo muy bien como Windows está certificado EAL-4 y otros sistemas operativos más seguros y mejor diseñados no, o están certificados en un nivel inferior.

    Los mecanismos de seguridad mandatoria son, a día de hoy, más que una realidad en los sistemas UNIX (Trusted Solaris, FreeBSD, Linux, OpenBSD), pero ciencia ficción en la «segura» plataforma de Microsoft.

  2. Ah, pues es muy sencillo hombre. Me cito a mí mismo ;)

    Es importante notar aquí que CC utiliza una graduación de requisitos llamada Evaluation Assurance Levels, normalmente conocidas como EALs, las cuales están numeradas del 1 al 7, siendo creciente el número de controles y requisitos a cumplir.

    Los niveles altos de EAL NO IMPLICAN necesariamente que el producto sea más seguro (por eso el título tiene la palabra “seguros” entrecomillada), sino que los niveles de seguridad que un desarrollador o usuario proclama tener en su producto han sido analizados de un modo más exhaustivo.

    La clave de EAL está en que se certifica lo que el fabricante asegura cumplir, no un estándar que mida a todos por el mismo rasero. Consecuencia de esto, al menos para mí, la certificación EAL no vale para comparar sistemas, y muchísimo menos, para comparar su seguridad.

Comentarios cerrados.