On Tue, 2008-02-12 at 23:43 +0900, Yuichi Nakamura wrote: > Hi. > > I saw an article on slashdot. > http://it.slashdot.org/article.pl?sid=08/02/10/2011257 > > Local exploit code for Linux kernel exists, > exploit code is also disclosed in http://www.milw0rm.com/exploits/5092. > > In the exploit code, only uid is changed to 0. > So, SELinux is not affected. > > However, SELinux can be disabled by overwriting selinux_enforcing to 0. > The address of selinux_enforcing can be seen in /proc/kallsyms, > and I've set the value on the address to 0. > > I tried that on Fedora 8, > and I could disable SELinux(set selinux as permissive) from xguest_t > domain. > > I want to make it more difficult > for attackers to disable SELinux by kernel exploit. > > I think not exporting selinux_enforcing(and selinux_disable) to > /proc/kallsyms is useful. > And /proc/kallsyms is visible from many processes because it is proc_t, > assigning /proc/kallsyms label such as proc_ksym_t may be also useful. > Are they really useful? > Or any idea?? It would be more useful to just build a kernel with a config that disabled the support for permissive mode and runtime disable altogether; such config options already exist. And you can also omit /proc/kallsyms altogether via kernel config. Labeling /proc/kallsyms with a distinct type is likely feasible, so that could be changed in policy. There is a patch floating around to turn the LSM hook calls into direct SELinux calls so that there is no more security_ops pointer that can be overwritten. But there will still be other critical variables, and SELinux can't protect against kernel vulnerabilities in general. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
