Disabling SELinux by kernel vulnerability

Disabling SELinux by kernel vulnerability

[Yuichi Nakamura]

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??

--
Yuichi Nakamura

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Disabling SELinux by kernel vulnerability

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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??
> 
> --
> Yuichi Nakamura
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
So this exploit, don't you neet to write to /proc?  xguest_t should not
be allowed to do this?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkextEAACgkQrlYvE4MpobNWWgCg6acsickGQTXcl0xj3YyBYoRn
NGUAnR45m3M0yM15igKtZzh6ORQ9CYTQ
=64qb
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Disabling SELinux by kernel vulnerability

[Todd Miller]

Daniel J Walsh wrote:
> So this exploit, don't you neet to write to /proc?  xguest_t should
> not be allowed to do this?

No, you don't need to be able to write to /proc to exploit the bug.
Having read access /proc/kallsyms just makes things a little easier
for the attacker.  Removing the address of selinux_enforcing from
kallsyms doesn't stop the attack, it just makes the attacker work
a little harder.

Note that the modified exploit that uses kallsyms to find the address
of vmsplice and then opens /dev/kmem read/write to do its work would
be stopped by SELinux.

 - todd


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Disabling SELinux by kernel vulnerability

[Yuichi Nakamura]

On Tue, 12 Feb 2008 10:45:41 -0500
"Todd Miller" wrote:

> Daniel J Walsh wrote:
> > So this exploit, don't you neet to write to /proc?  xguest_t should
> > not be allowed to do this?
> 
> No, you don't need to be able to write to /proc to exploit the bug.
> Having read access /proc/kallsyms just makes things a little easier
> for the attacker.  Removing the address of selinux_enforcing from
> kallsyms doesn't stop the attack, it just makes the attacker work
> a little harder.
Yes, we do not need write access to /proc/kallsyms.

> Note that the modified exploit that uses kallsyms to find the address
> of vmsplice and then opens /dev/kmem read/write to do its work would
> be stopped by SELinux.
Default xguest_t does not allow execution of program on /home
so, exploit program can not be executed.
I tried exploit with boolean allow_xguest_exec_content on.

However, in this case, 
it is easy to guess address of selinux_enforcing,
because the address of selinux_enforcing is the same in another machine,
as long as the same kernel binary is used.


> 
>  - todd

Regards,
Yuichi Nakamura

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Disabling SELinux by kernel vulnerability

[Stephen Smalley]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Disabling SELinux by kernel vulnerability

[Waide, Ronan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
> On Behalf Of Stephen Smalley
> It would be more useful to just build a kernel with a config that
> disabled the support for permissive mode and runtime disable
> altogether;

Is this the current recommended way of preventing SELinux from being switched off? There's a FAQ somewhere that used suggest disabling a particular macro in the policy build (which I can't recall off the top of my head) but by the time I got around to trying it out it on a test system the technique no longer worked.

Cheers,
Waider.
- --
Ronan Waide / waider@amazon.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFHst0lBK4+zUKLsUkRAh5iAJ0YsGzYawUdra5uqxPQD5nJTzQU+wCfWU5D
dRfh+aboTpBtCW4q8+6TlT0=
=hU46
-----END PGP SIGNATURE-----


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Disabling SELinux by kernel vulnerability

[Stephen Smalley]

On Wed, 2008-02-13 at 12:06 +0000, Waide, Ronan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
> > On Behalf Of Stephen Smalley
> > It would be more useful to just build a kernel with a config that
> > disabled the support for permissive mode and runtime disable
> > altogether;
> 
> Is this the current recommended way of preventing SELinux from being
> switched off? There's a FAQ somewhere that used suggest disabling a
> particular macro in the policy build (which I can't recall off the top
> of my head) but by the time I got around to trying it out it on a test
> system the technique no longer worked.

The policy-based approach only controls the ability to change enforcing
mode or reload policy via the corresponding kernel interfaces.  I think
the secure_mode_policyload boolean exists in current policy to let you
disable the ability to change enforcing mode or reload policy.  But that
doesn't help with exploitation of a kernel flaw that permits writing to
kernel memory, which is what we are talking about here.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Disabling SELinux by kernel vulnerability

[Yuichi Nakamura]

On Tue, 12 Feb 2008 13:45:12 -0500
Stephen Smalley  wrote:
> 
> 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.
Many people do not want to recompile kernel,
so this looks more useful.

But I am not sure whether this is really useful or not.
In my environment(Fedora 8), 
the address of selinux_enforcing is the same in every boot.
So I guess the address of selinux_enforcing is the same in the same kernel binary.
The same kernel binary is used in Fedora, 
so attacker see the address of selinux_enforcing in his own Fedora,
and he can use the address in other Fedora machines.
If this is correct, it makes no sense to give different label for /proc/kallsyms.

> 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.
Yes, basically it is correct.
But making attack harder is good thing.

> 
> -- 
> Stephen Smalley
> National Security Agency
> 
> 

Regards,
Yuichi Nakamura

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Disabling SELinux by kernel vulnerability

[Stephen Smalley]

On Wed, 2008-02-13 at 22:47 +0900, Yuichi Nakamura wrote:
> 
> On Tue, 12 Feb 2008 13:45:12 -0500
> Stephen Smalley  wrote:
> > 
> > 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.
> Many people do not want to recompile kernel,
> so this looks more useful.
> 
> But I am not sure whether this is really useful or not.
> In my environment(Fedora 8), 
> the address of selinux_enforcing is the same in every boot.
> So I guess the address of selinux_enforcing is the same in the same kernel binary.
> The same kernel binary is used in Fedora, 
> so attacker see the address of selinux_enforcing in his own Fedora,
> and he can use the address in other Fedora machines.
> If this is correct, it makes no sense to give different label for /proc/kallsyms.

Correct - you'd need to either eliminate selinux_enforcing (and certain
other variables) altogether, or you'd need to somehow make them
read-only after initial setting.

If going the separate label route, rather than introducing a separate
type for /proc/kallsyms, you could possibly just re-use the type
of /boot/System.map*.

> > 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.
> Yes, basically it is correct.
> But making attack harder is good thing.
> 
> > 
> > -- 
> > Stephen Smalley
> > National Security Agency
> > 
> > 
> 
> Regards,
> Yuichi Nakamura
> 
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.