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.

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.