[PATCH] Change ZERO_SIZE_PTR to point at unmapped space

[PATCH] Change ZERO_SIZE_PTR to point at unmapped space

[Larry H.]

[PATCH] Change ZERO_SIZE_PTR to point at unmapped space

This patch changes the ZERO_SIZE_PTR address to point at top memory
unmapped space, instead of the original location which could be
mapped from userland to abuse a NULL (or offset-from-null) pointer
dereference scenario.

The ZERO_OR_NULL_PTR macro is changed accordingly. This patch does
not modify its behavior nor has any performance nor functionality
impact.

The original change was written first by the PaX team for their
patch.

Signed-off-by: Larry Highsmith <larry@subreption.com>

Index: linux-2.6/include/linux/slab.h
===================================================================
--- linux-2.6.orig/include/linux/slab.h
+++ linux-2.6/include/linux/slab.h
@@ -73,10 +73,9 @@
  * ZERO_SIZE_PTR can be passed to kfree though in the same way that NULL can.
  * Both make kfree a no-op.
  */
-#define ZERO_SIZE_PTR ((void *)16)
+#define ZERO_SIZE_PTR ((void *)-1024L)
 
-#define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) <= \
-				(unsigned long)ZERO_SIZE_PTR)
+#define ZERO_OR_NULL_PTR(x) (!(x) || (x) == ZERO_SIZE_PTR)
 
 /*
  * struct kmem_cache related prototypes

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] Change ZERO_SIZE_PTR to point at unmapped space

[Linus Torvalds]

On Sat, 30 May 2009, Larry H. wrote:
> 
> The ZERO_OR_NULL_PTR macro is changed accordingly. This patch does
> not modify its behavior nor has any performance nor functionality
> impact.

I'm sure it makes a code generation difference, with (a) big constants and 
(b) no longer possible to merge the conditional into one single one.

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] Change ZERO_SIZE_PTR to point at unmapped space

[Larry H.]

On 15:29 Sat 30 May     , Linus Torvalds wrote:
> 
> 
> On Sat, 30 May 2009, Larry H. wrote:
> > 
> > The ZERO_OR_NULL_PTR macro is changed accordingly. This patch does
> > not modify its behavior nor has any performance nor functionality
> > impact.
> 
> I'm sure it makes a code generation difference, with (a) big constants and 
> (b) no longer possible to merge the conditional into one single one.

Like I said in the reply to Peter, this is 3 extra bytes for amd64 with
gcc 4.3.3. I can't be bothered to check other architectures at the
moment.

	Larry

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] Change ZERO_SIZE_PTR to point at unmapped space

[Linus Torvalds]

On Sat, 30 May 2009, Larry H. wrote:
> 
> Like I said in the reply to Peter, this is 3 extra bytes for amd64 with
> gcc 4.3.3. I can't be bothered to check other architectures at the
> moment.

.. and I can't be bothered with applying this. I'm just not convinced.

It's 3 extra bytes just for the constant. It's also another test, and 
another branch.

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] Change ZERO_SIZE_PTR to point at unmapped space

[Larry H.]

On 19:02 Sat 30 May     , Linus Torvalds wrote:
> 
> 
> On Sat, 30 May 2009, Larry H. wrote:
> > 
> > Like I said in the reply to Peter, this is 3 extra bytes for amd64 with
> > gcc 4.3.3. I can't be bothered to check other architectures at the
> > moment.
> 
> .. and I can't be bothered with applying this. I'm just not convinced.

The changes don't conflict with anything else (including ERR_PTR and
company). When I said bothered, I implied the change was obviously not
going to differ in any significant way for other architectures.

Like I said, small changes like this are done so we don't need to rely
on mmap_min_addr, which is disabled by default (albeit some
distributions enable it, normally set to 65536).

Let me provide you with a realistic scenario:

	1. foo.c network protocol implementation takes a sockopt which
	sets some ACME_OPTLEN value taken from userland.

	2. the length is not validated properly: it can be zero or an
	integer overflow / signedness issue allows it to wrap to zero.

	3. kmalloc(0) ensues, and data is copied to the pointer
	returned. if this is the default ZERO_SIZE_PTR*, a malicious user
	can mmap a page at NULL, and read data leaked from kernel memory
	everytime that setsockopt is issued.
	(*: kmalloc of zero returns ZERO_SIZE_PTR)

If ZERO_SIZE_PTR points to an unmapped top memory address, this will
trigger a distinctive page fault and the user won't be able to abuse
this for elevating privileges or read kernel memory. Variations of the
scenario above have been present in the kernel, some with exploits being
made available publicly. Most recently, a SCTP sockopt issue.

> It's 3 extra bytes just for the constant. It's also another test, and 
> another branch.

What's the total difference, less than 40 bytes? Do the users of this
macro get impacted? No. Who uses the macro? kzfree/kfree/do_kmalloc/etc.
A dozen users, all in SLAB.

The performance impact, if any, is completely negligible. The security
benefits of this utterly simple change well surpass the downsides.

	Larry

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] Change ZERO_SIZE_PTR to point at unmapped space

[Christoph Lameter]

On Sat, 30 May 2009, Larry H. wrote:

> Let me provide you with a realistic scenario:
>
> 	1. foo.c network protocol implementation takes a sockopt which
> 	sets some ACME_OPTLEN value taken from userland.
>
> 	2. the length is not validated properly: it can be zero or an
> 	integer overflow / signedness issue allows it to wrap to zero.
>
> 	3. kmalloc(0) ensues, and data is copied to the pointer
> 	returned. if this is the default ZERO_SIZE_PTR*, a malicious user
> 	can mmap a page at NULL, and read data leaked from kernel memory
> 	everytime that setsockopt is issued.
> 	(*: kmalloc of zero returns ZERO_SIZE_PTR)

Cannot happen. The page at 0L is not mapped. This will cause a fault.

You are assuming the system has already been breached. Then of course all
bets are off.

> The performance impact, if any, is completely negligible. The security
> benefits of this utterly simple change well surpass the downsides.

Dont see any security benefit. If there is a way to breach security
of the kernel via mmap then please tell us and then lets fix
the problem and not engage in dealing with secondary issues.

Semantics of mmap(NULL, ...) is that the kernel selects a valid address
for you. How are you mapping something at 0L?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] Change ZERO_SIZE_PTR to point at unmapped space

[Larry H.]

On 11:37 Tue 02 Jun     , Christoph Lameter wrote:
> On Sat, 30 May 2009, Larry H. wrote:
> 
> > Let me provide you with a realistic scenario:
> >
> > 	1. foo.c network protocol implementation takes a sockopt which
> > 	sets some ACME_OPTLEN value taken from userland.
> >
> > 	2. the length is not validated properly: it can be zero or an
> > 	integer overflow / signedness issue allows it to wrap to zero.
> >
> > 	3. kmalloc(0) ensues, and data is copied to the pointer
> > 	returned. if this is the default ZERO_SIZE_PTR*, a malicious user
> > 	can mmap a page at NULL, and read data leaked from kernel memory
> > 	everytime that setsockopt is issued.
> > 	(*: kmalloc of zero returns ZERO_SIZE_PTR)
> 
> Cannot happen. The page at 0L is not mapped. This will cause a fault.

Why would mmap_min_addr have been created in first place, if NULL can't
be mapped to force the kernel into accessing userland memory? This is
the way a long list of public and private kernel exploits have worked to
elevate privileges, and disable SELinux/LSMs atomically, too.

Take a look at these:
http://www.grsecurity.net/~spender/exploit.tgz (disables LSMs)
http://milw0rm.com/exploits/4172
http://milw0rm.com/exploits/3587

I would like to know what makes you think I can't mmap(0) from within
the same process that triggers your 'not so exploitable NULL page
fault', which instead of generating the oops will lead to 100% reliable,
cross-arch exploitation to get root privileges (again, after disabling
SELinux and anything else that would supposedly prevent this situation).
Or leaked memory, like a kmalloc(0) situation will most likely lead to,
given the current circumstances.

> You are assuming the system has already been breached. Then of course all
> bets are off.

No, your system has been breached and they have access as a
not-yet-privileged user. The bets are off when nothing protects your
kernel from letting them escalate privileges and disable your fancy
SELinux MLS policy, AppArmor, or any other LSM useless in this scenario.

> > The performance impact, if any, is completely negligible. The security
> > benefits of this utterly simple change well surpass the downsides.
> 
> Dont see any security benefit. If there is a way to breach security
> of the kernel via mmap then please tell us and then lets fix
> the problem and not engage in dealing with secondary issues.

Your first concern has been addressed above. Regarding the second, well,
this is called proactive defense. Instead of taking a reactive approach
when your security has been already breached, you try to lock down
potential venues of attack to deter unknown threats.

Instead of the definitive tone and so forth, you could try something more
reasonable like 'I do not understand what this is all about, could you
please explain it?', which might help.

> Semantics of mmap(NULL, ...) is that the kernel selects a valid address
> for you. How are you mapping something at 0L?

http://www.opengroup.org/onlinepubs/000095399/functions/mmap.html

Please proceed to re-read the part about anonymous mappings and
MAP_FIXED|MAP_PRIVATE. And refer to the exploits mentioned in the
previous paragraphs ;)

Once mmap semantics are clear, we can continue discussing any other
possible objections to this patch, if you don't mind.

	Larry

(Please keep pageexec/PaX team in CC)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Christoph Lameter]

On Tue, 2 Jun 2009, Larry H. wrote:

> Why would mmap_min_addr have been created in first place, if NULL can't
> be mapped to force the kernel into accessing userland memory? This is
> the way a long list of public and private kernel exploits have worked to
> elevate privileges, and disable SELinux/LSMs atomically, too.
>
> Take a look at these:
> http://www.grsecurity.net/~spender/exploit.tgz (disables LSMs)
> http://milw0rm.com/exploits/4172
> http://milw0rm.com/exploits/3587
>
> I would like to know what makes you think I can't mmap(0) from within
> the same process that triggers your 'not so exploitable NULL page
> fault', which instead of generating the oops will lead to 100% reliable,
> cross-arch exploitation to get root privileges (again, after disabling
> SELinux and anything else that would supposedly prevent this situation).
> Or leaked memory, like a kmalloc(0) situation will most likely lead to,
> given the current circumstances.

Ok. So what we need to do is stop this toying around with remapping of
page 0. The following patch contains a fix and a test program that
demonstrates the issue.


Subject: [Security] Do not allow remapping of page 0 via MAP_FIXED

If one remaps page 0 then the kernel checks for NULL pointers of various
flavors are bypassed and this may be exploited in various creative ways
to transfer data from kernel space to user space.

Fix this by not allowing the remapping of page 0. Return -EINVAL if
such a mapping is attempted.

Simple test program that shows the problem:

#include <sys/mman.h>

int main(int argc, char *argv)
{
        printf("%ld\n", mmap(0L, 4096, PROT_WRITE, MAP_FIXED|MAP_PRIVATE|MAP_ANONYMOUS, 0,0));
        *((char *)8) = 3;
        printf("Value at address 8 is %d\n", *((char *)8));
        return 0;
}

If the remapping of page 0 succeeds then the value at 8 is 3.
After the patch the program segfaults as it should.

Signed-off-by: Christoph Lameter <cl@linux-foundation.org>

---
 mm/mmap.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

Index: linux-2.6/mm/mmap.c
===================================================================
--- linux-2.6.orig/mm/mmap.c	2009-06-03 09:44:43.000000000 -0500
+++ linux-2.6/mm/mmap.c	2009-06-03 09:45:31.000000000 -0500
@@ -1273,8 +1273,12 @@ arch_get_unmapped_area(struct file *filp
 	if (len > TASK_SIZE)
 		return -ENOMEM;

-	if (flags & MAP_FIXED)
-		return addr;
+	if (flags & MAP_FIXED) {
+		if (addr & PAGE_MASK)
+			return addr;
+		/* Do not allow remapping of the first page */
+		return -EINVAL;
+	}

 	if (addr) {
 		addr = PAGE_ALIGN(addr);
@@ -1349,8 +1353,12 @@ arch_get_unmapped_area_topdown(struct fi
 	if (len > TASK_SIZE)
 		return -ENOMEM;

-	if (flags & MAP_FIXED)
-		return addr;
+	if (flags & MAP_FIXED) {
+		if (addr & PAGE_MASK)
+			return addr;
+		/* Do not allow remapping of the first page */
+		return -EINVAL;
+	}

 	/* requesting a specific address */
 	if (addr) {

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Christoph Lameter wrote:
> 
> Ok. So what we need to do is stop this toying around with remapping of
> page 0. The following patch contains a fix and a test program that
> demonstrates the issue.

No, we _need_ to be able to map to address zero.

It may not be very common, but things like vm86 require it - vm86 mode 
always starts at virtual address zero. 

For similar reasons, some other emulation environments will want it too, 
simply because they want to emulate another environment that has an 
address space starting at 0, and don't want to add a base to all address 
calculations.

There are historically even some crazy optimizing compilers that decided 
that they need to be able to optimize accesses of a pointer across a NULL 
pointer check, so that they can turn code like

	if (!ptr)
		return;
	val = ptr->member;

into doing the load early. In order to support that optimization, they 
have a runtime that always maps some garbage at virtual address zero.

(I don't remember who did this, but my dim memory wants to say it was some 
HP-UX compiler. Scheduling loads early can be a big deal on especially 
in-order machines with nonblocking cache accesses).

The point being that we do need to support mmap at zero. Not necessarily 
universally, but it can't be some fixed "we don't allow that".

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Christoph Lameter]

On Wed, 3 Jun 2009, Linus Torvalds wrote:

> The point being that we do need to support mmap at zero. Not necessarily
> universally, but it can't be some fixed "we don't allow that".

Hmmm... Depend on some capability? CAP_SYS_PTRACE may be something
remotely related?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Christoph Lameter wrote:

> On Wed, 3 Jun 2009, Linus Torvalds wrote:
> 
> > The point being that we do need to support mmap at zero. Not necessarily
> > universally, but it can't be some fixed "we don't allow that".
> 
> Hmmm... Depend on some capability? CAP_SYS_PTRACE may be something
> remotely related?

But as mentioned several times, we do have the system-wide setting in
'mmap_min_addr' (that then can be overridden by CAP_SYS_RAWIO, so in that 
sense a capability already exists).

It defaults to 64kB in at least the x86 defconfig files, but to 0 in the 
Kconfig defaults. Also, for some reason it has a "depends on SECURITY", 
which means that if you just default to the old-style unix security you'll 
lose it.

So there are several ways to disable it by mistake. I don't know what 
distros do.

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Alan Cox]

> It defaults to 64kB in at least the x86 defconfig files, but to 0 in the 
> Kconfig defaults. Also, for some reason it has a "depends on SECURITY", 
> which means that if you just default to the old-style unix security you'll 
> lose it.
> 
> So there are several ways to disable it by mistake. I don't know what 
> distros do.

Fedora at least uses SELinux to manage it. You need some kind of security
policy engine running as a few apps really need to map low space (mostly
for vm86)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Alan Cox wrote:
> 
> Fedora at least uses SELinux to manage it. You need some kind of security
> policy engine running as a few apps really need to map low space (mostly
> for vm86)

Well, vm86 isn't even an issue on x86-64, so it's arguable that at least a 
few cases could very easily just make it more static and obvious.

			Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Eric Paris]

On Wed, Jun 3, 2009 at 12:19 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 3 Jun 2009, Alan Cox wrote:
>>
>> Fedora at least uses SELinux to manage it. You need some kind of security
>> policy engine running as a few apps really need to map low space (mostly
>> for vm86)
>
> Well, vm86 isn't even an issue on x86-64, so it's arguable that at least a
> few cases could very easily just make it more static and obvious.

Wine does/did also use a zero page, can't remember what they used it
for off hand but they were mad at me when I added this....

-Eric

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Eric Paris]

On Wed, Jun 3, 2009 at 11:38 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 3 Jun 2009, Christoph Lameter wrote:
>
>> On Wed, 3 Jun 2009, Linus Torvalds wrote:
>>
>> > The point being that we do need to support mmap at zero. Not necessarily
>> > universally, but it can't be some fixed "we don't allow that".
>>
>> Hmmm... Depend on some capability? CAP_SYS_PTRACE may be something
>> remotely related?
>
> But as mentioned several times, we do have the system-wide setting in
> 'mmap_min_addr' (that then can be overridden by CAP_SYS_RAWIO, so in that
> sense a capability already exists).
>
> It defaults to 64kB in at least the x86 defconfig files, but to 0 in the
> Kconfig defaults. Also, for some reason it has a "depends on SECURITY",
> which means that if you just default to the old-style unix security you'll
> lose it.
>
> So there are several ways to disable it by mistake. I don't know what
> distros do.

Fedora has it on.

As I recall the only need for CONFIG_SECURITY is for the ability to
override the check.

I think I could probably pretty cleanly change it to use
CAP_SYS_RAWIO/SELinux permissions if CONFIG_SECURITY and just allow it
for uid=0 in the non-security case?  Deny it for everyone in the
non-security case and make them change the /proc tunable if they need
it?

-Eric

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Eric Paris wrote:
> 
> As I recall the only need for CONFIG_SECURITY is for the ability to
> override the check.

No, if you have SECURITY disabled entirely, the check goes away.

If you have SECURITY on, but then use the simple capability model, the 
check is there.

If you have SECURITY on, and then use SElinux, you can make it be dynamic.

> I think I could probably pretty cleanly change it to use
> CAP_SYS_RAWIO/SELinux permissions if CONFIG_SECURITY and just allow it
> for uid=0 in the non-security case?

We probably should, since the "capability" security version should 
generally essentially emulate the regular non-SECURITY case for root. 

			Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Eric Paris]

On Wed, Jun 3, 2009 at 12:28 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 3 Jun 2009, Eric Paris wrote:
>>
>> As I recall the only need for CONFIG_SECURITY is for the ability to
>> override the check.
>
> No, if you have SECURITY disabled entirely, the check goes away.

I meant 'need' as in the reason I wrapped it in CONFIG_SECURITY, not
that you were wrong when you said it disapeared.

>> I think I could probably pretty cleanly change it to use
>> CAP_SYS_RAWIO/SELinux permissions if CONFIG_SECURITY and just allow it
>> for uid=0 in the non-security case?
>
> We probably should, since the "capability" security version should
> generally essentially emulate the regular non-SECURITY case for root.

Will poke/patch this afternoon.

-Eric

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Eric Paris wrote:
> >
> > We probably should, since the "capability" security version should
> > generally essentially emulate the regular non-SECURITY case for root.
> 
> Will poke/patch this afternoon.

Btw, a perhaps more interesting case would be to _really_ make the 
"!SECURITY" case just be essentially a hardcoding of the capability case.

Right now the Kconfig option is actually actively misleading, because it 
says that "if you don't enable SECURITY, the default security model will 
be used". 

And that's not automatically true, as shown by this example. You can 
easily get out of sync between security/capability.c and the hardcoded 
non-security rules in include/linux/security.h.

Wouldn't it be kind of nice if the "security/capability.c" file would work 
something like 

 - make the meat of it just a header file ("<linux/cap_security.h>")

 - if !SECURITY, the functions become inline functions named 
   "security_xyz()", and the header file gets included from 
   <linux/security.h>

 - if SECURITY, the functions become static functions named "cap_xyz()", 
   and get included from security/capability.c.

IOW, we'd _guarantee_ that the !SECURITY case is exactly the same as the 
SECURITY+default capabilities case, because we'd be sharing the source 
code.

Hmm? Wouldn't that be a nice way to always avoid the potential "oops, 
!SECURITY has different semantics than intended".

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Stephen Smalley]

On Wed, 2009-06-03 at 10:50 -0400, Christoph Lameter wrote:
> On Tue, 2 Jun 2009, Larry H. wrote:
> 
> > Why would mmap_min_addr have been created in first place, if NULL can't
> > be mapped to force the kernel into accessing userland memory? This is
> > the way a long list of public and private kernel exploits have worked to
> > elevate privileges, and disable SELinux/LSMs atomically, too.
> >
> > Take a look at these:
> > http://www.grsecurity.net/~spender/exploit.tgz (disables LSMs)
> > http://milw0rm.com/exploits/4172
> > http://milw0rm.com/exploits/3587
> >
> > I would like to know what makes you think I can't mmap(0) from within
> > the same process that triggers your 'not so exploitable NULL page
> > fault', which instead of generating the oops will lead to 100% reliable,
> > cross-arch exploitation to get root privileges (again, after disabling
> > SELinux and anything else that would supposedly prevent this situation).
> > Or leaked memory, like a kmalloc(0) situation will most likely lead to,
> > given the current circumstances.
> 
> Ok. So what we need to do is stop this toying around with remapping of
> page 0. The following patch contains a fix and a test program that
> demonstrates the issue.
> 
> 
> Subject: [Security] Do not allow remapping of page 0 via MAP_FIXED
> 
> If one remaps page 0 then the kernel checks for NULL pointers of various
> flavors are bypassed and this may be exploited in various creative ways
> to transfer data from kernel space to user space.
> 
> Fix this by not allowing the remapping of page 0. Return -EINVAL if
> such a mapping is attempted.

You can already prevent unauthorized processes from mapping low memory
via the existing mmap_min_addr setting, configurable via
SECURITY_DEFAULT_MMAP_MIN_ADDR or /proc/sys/vm/mmap_min_addr.  Then
cap_file_mmap() or selinux_file_mmap() will apply a check when a process
attempts to map memory below that address.

-- 
Stephen Smalley
National Security Agency

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Christoph Lameter]

On Wed, 3 Jun 2009, Stephen Smalley wrote:

> > If one remaps page 0 then the kernel checks for NULL pointers of various
> > flavors are bypassed and this may be exploited in various creative ways
> > to transfer data from kernel space to user space.
> >
> > Fix this by not allowing the remapping of page 0. Return -EINVAL if
> > such a mapping is attempted.
>
> You can already prevent unauthorized processes from mapping low memory
> via the existing mmap_min_addr setting, configurable via
> SECURITY_DEFAULT_MMAP_MIN_ADDR or /proc/sys/vm/mmap_min_addr.  Then
> cap_file_mmap() or selinux_file_mmap() will apply a check when a process
> attempts to map memory below that address.

mmap_min_addr depends on CONFIG_SECURITY which establishes various
strangely complex "security models".

The system needs to be secure by default.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Christoph Lameter wrote:
> 
> mmap_min_addr depends on CONFIG_SECURITY which establishes various
> strangely complex "security models".
> 
> The system needs to be secure by default.

It _is_ secure by default. You have to do some pretty non-default things 
to get away from it.

But I do agree that it might be good to move the thing into the generic 
path. I just don't think your arguments are very good. It's not about 
defaults, it's about the fact that this isn't worth being hidden by that 
security layer.

			Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Larry H.]

On 11:41 Wed 03 Jun     , Christoph Lameter wrote:
> On Wed, 3 Jun 2009, Stephen Smalley wrote:
> 
> > > If one remaps page 0 then the kernel checks for NULL pointers of various
> > > flavors are bypassed and this may be exploited in various creative ways
> > > to transfer data from kernel space to user space.
> > >
> > > Fix this by not allowing the remapping of page 0. Return -EINVAL if
> > > such a mapping is attempted.

Christopher, crippling the system is truly not the way to fix this.
There are many legitimate users of private|fixed mappings at 0. In
addition, if you want to go ahead and break POSIX, at least make sure
your patch closes the loophole.

Given these circumstances, are you proposing this over my patch?

Linus already pointed out the main (functional) problem about it. It
seems you are also confusing the issue, albeit already realized it can
be a venue of attack, which is good.

For instance, there are many scenarios in which a fixed mapping can be
used in a non-zero address to abuse kernel flaws... your patch is
useless against those.

Please let me remind you that my original intent was to prevent
kmalloc(0) from leading to potential NULL or offset-from-NULL access
issues, and not deterring NULL pointer deferences in kernel-land which
is a whole different thing (see PaX UDEREF for clues on this).

> >
> > You can already prevent unauthorized processes from mapping low memory
> > via the existing mmap_min_addr setting, configurable via
> > SECURITY_DEFAULT_MMAP_MIN_ADDR or /proc/sys/vm/mmap_min_addr.  Then
> > cap_file_mmap() or selinux_file_mmap() will apply a check when a process
> > attempts to map memory below that address.

If SELinux isn't present, that's not useful. If mmap_min_addr is
enabled, that still won't solve what my original, utterly simple patch
fixes.

The patch provides a no-impact, clean solution to prevent kmalloc(0)
situations from becoming a security hazard. Nothing else.

If you want to solve NULL/ptr deference abuse from userland, you better
start thinking about separating kernel virtual address space from
userland's, with the performance impact that implies. Few architectures
provide this capability without performance hit, and x86 ain't one of
them.

> mmap_min_addr depends on CONFIG_SECURITY which establishes various
> strangely complex "security models".
> 
> The system needs to be secure by default.

Correct, so what was wrong with my patch again? That the original two
line change was written by the PaX team?

Come on chap, It's not like you will lose your bragging rights among
your peers for admitting that I was right. Just this one time. I won't
tell anybody. Promise.

	Larry

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Rik van Riel]

Larry H. wrote:

> Christopher, crippling the system is truly not the way to fix this.
> There are many legitimate users of private|fixed mappings at 0. In
> addition, if you want to go ahead and break POSIX, at least make sure
> your patch closes the loophole.

I suspect there aren't many at all, and restricting them through
SELinux may be enough to mitigate the risk.

> If SELinux isn't present, that's not useful. If mmap_min_addr is
> enabled, that still won't solve what my original, utterly simple patch
> fixes.

Would anybody paranoid run their system without SELinux?

> The patch provides a no-impact, clean solution to prevent kmalloc(0)
> situations from becoming a security hazard. Nothing else.

True, the changes in your patch only affect a few code paths.

-- 
All rights reversed.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Rik van Riel wrote:
> 
> Would anybody paranoid run their system without SELinux?

You make two very fundamental mistakes.

The first is to assume that this is about "paranoid" people. Security is 
_not_ about people who care deeply about security. It's about everybody. 
Look at viruses and DDoS attacks - the "paranoid" people absolutely depend 
on the _non_paranoid people being secure too!

The other mistake is to think that SELinux is sane, or should be the 
default. It's a f*cking complex disaster, and makes performance plummet on 
some things. I turn it off, and I know lots of other sane people do too. 
So the !SElinux case really does need to work.

				Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Eric Paris]

On Wed, Jun 3, 2009 at 12:47 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:

> The other mistake is to think that SELinux is sane, or should be the
> default. It's a f*cking complex disaster, and makes performance plummet on
> some things.

While I think you couldn't be more wrong I'm not going to argue that topic....

I am at least interested in hearing about the 'performance plummet.'
I don't see any performance reports on my todo list but I am
interested in banging on any that people report.  Last performance
thing I heard anything about was Ingo doing some profiling of of a
network stack benchmark in which SELinux was eating a percent or two
his time.  I cut the SELinux performance penalty by about 50% on my
systems in that benchmark.  If others have complaints let me or the
selinux list know....

-Eric

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Eric Paris wrote:
> 
> I am at least interested in hearing about the 'performance plummet.'

It's perhaps not so much SElinux itself, but the AUDIT support (which it 
requires) that is really _very_ noticeable on microbenchmarks.

Last time I ran lmbench on a Fedora kernel it was horrible. Turning off 
AUDIT (which also turns off SElinux) fixes it.

It may be crazy distro auditing rules or whatever, but that doesn't change 
the basic issue. 

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Eric Paris]

On Wed, Jun 3, 2009 at 1:28 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 3 Jun 2009, Eric Paris wrote:
>>
>> I am at least interested in hearing about the 'performance plummet.'
>
> It's perhaps not so much SElinux itself, but the AUDIT support (which it
> requires) that is really _very_ noticeable on microbenchmarks.
>
> Last time I ran lmbench on a Fedora kernel it was horrible. Turning off
> AUDIT (which also turns off SElinux) fixes it.
>
> It may be crazy distro auditing rules or whatever, but that doesn't change
> the basic issue.

Probably AUDITSYSCALL, not AUDIT.  SELinux only needs AUDIT.  I'll
poke that too someday, thanks.

-Eric

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Larry H.]

On 09:47 Wed 03 Jun     , Linus Torvalds wrote:
> 
> 
> On Wed, 3 Jun 2009, Rik van Riel wrote:
> > 
> > Would anybody paranoid run their system without SELinux?
> 
> You make two very fundamental mistakes.
> 
> The first is to assume that this is about "paranoid" people. Security is 
> _not_ about people who care deeply about security. It's about everybody. 
> Look at viruses and DDoS attacks - the "paranoid" people absolutely depend 
> on the _non_paranoid people being secure too!
> 
> The other mistake is to think that SELinux is sane, or should be the 
> default. It's a f*cking complex disaster, and makes performance plummet on 
> some things. I turn it off, and I know lots of other sane people do too. 
> So the !SElinux case really does need to work.

I'm finally glad we start finding points where we both agree. riel is
talking from the perspective of someone who deals with RHEL/Fedora... so
I could see his inclination towards SELinux over any other
possibilities.

But people without SELinux must be definitely taken care of, and kept
safe whenever possible, if technical circumstances allow this to happen.

	Larry

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Larry H.]

On 12:36 Wed 03 Jun     , Rik van Riel wrote:
> Larry H. wrote:
>
>> Christopher, crippling the system is truly not the way to fix this.
>> There are many legitimate users of private|fixed mappings at 0. In
>> addition, if you want to go ahead and break POSIX, at least make sure
>> your patch closes the loophole.
>
> I suspect there aren't many at all, and restricting them through
> SELinux may be enough to mitigate the risk.

It's still perfectly valid POSIX, but I'm definitely keen on using this
patch together with a convenient mmap_min_addr value. I'm just trying to
show how both things are orthogonal to each other, without additional
cost for us (as in people doing kernel/drivers development) and users.

>> If SELinux isn't present, that's not useful. If mmap_min_addr is
>> enabled, that still won't solve what my original, utterly simple patch
>> fixes.
>
> Would anybody paranoid run their system without SELinux?

Does everyone who is conscious about security must use SELinux? Is
SELinux the only acceptable solution? What about people who decide to
use AppArmor, or LIDS, or grsecurity?

That's not a valid point. People should stay safe without SELinux
whenever it is feasible, IMHO. I think everyone here will agree that
SELinux has a track of being disabled by users after installation
because they don't want to invest the necessary time on understanding
and learning the policy language or management tools.

>> The patch provides a no-impact, clean solution to prevent kmalloc(0)
>> situations from becoming a security hazard. Nothing else.
>
> True, the changes in your patch only affect a few code paths.

Only SLAB code itself is affected, users of kmalloc won't see a
functional difference. They just won't be as easily abused if a zero
length ends up passed to kmalloc and the pointer is used for something
later. There's an issue here that I must note: a wraparound can happen
and make the pointer land back somewhere near NULL.

It could be changed to point at the start of the fixmap.

It might be wise to see if expanding the fixmap on runtime can deter
this, although I had trouble using it within vm guests. This can be done
using reservetop boot option.

	Larry

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[James Morris]

On Wed, 3 Jun 2009, Larry H. wrote:

> whenever it is feasible, IMHO. I think everyone here will agree that
> SELinux has a track of being disabled by users after installation
> because they don't want to invest the necessary time on understanding
> and learning the policy language or management tools.

The Fedora smolt stats show an overwhelming majority of people leave it 
running.  Many don't know it's there at all and never have problems.  
It's known to have saved many everyday systems from breaches.

That's not to say that a significant number of people don't disable it, 
similarly to the way people disable iptables, use weak passwords, drive 
without seat belts, and cycle without helmets.  We do need to try and keep 
the default as safe as possible.


- James
-- 
James Morris
<jmorris@namei.org>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Alan Cox]

> Ok. So what we need to do is stop this toying around with remapping of
> page 0. The following patch contains a fix and a test program that
> demonstrates the issue.

NAK - you've now broken half a dozen apps.

One way you could approach this would be to write a security module for
non SELINUX users - one that did one thing alone - decide whether the app
being run was permitted to map the low 64K perhaps by checking the
security label on the file.

Alan

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Alan Cox wrote:
>
> One way you could approach this would be to write a security module for
> non SELINUX users - one that did one thing alone - decide whether the app
> being run was permitted to map the low 64K perhaps by checking the
> security label on the file.

Unnecessary. I really think that 99% of all people are perfectly fine with 
just the "mmap_min_addr" rule, and no more.

The rest could just use SElinux or set it to zero. It's not like allowing 
mmap's at NULL is a huge problem. Sure, it allows a certain kind of attack 
vector, but it's by no means an easy or common one - you need to already 
have gotten fairly good local access to take advantage of it.

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Larry H.]

On 10:35 Wed 03 Jun     , Linus Torvalds wrote:
> 
> 
> On Wed, 3 Jun 2009, Alan Cox wrote:
> >
> > One way you could approach this would be to write a security module for
> > non SELINUX users - one that did one thing alone - decide whether the app
> > being run was permitted to map the low 64K perhaps by checking the
> > security label on the file.
> 
> Unnecessary. I really think that 99% of all people are perfectly fine with 
> just the "mmap_min_addr" rule, and no more.
> 
> The rest could just use SElinux or set it to zero. It's not like allowing 
> mmap's at NULL is a huge problem. Sure, it allows a certain kind of attack 
> vector, but it's by no means an easy or common one - you need to already 
> have gotten fairly good local access to take advantage of it.

Are you saying that a kernel exploit can't be leveraged by means of
runtime code injection for example? By exploiting a completely
unprivileged daemon remotely? It's not 1990 anymore. People compromise
your system from memory, disk doesn't get to see the ladies poledancing
your kernel $pc.

Not easy? You should definitely ask the people who wrote those exploits what
kind of difficulty they encountered writing them. It goes like this:

	1) Have kernel flaw which leads to function ptr call from NULL
	or offset from NULL. Or can overwrite one. Or corrupt a kernel
	object. Not challenging.

	2) In your userland process, map NULL. Insert fake structures
	with proper pointers to your shellcode of choice. Not
	challenging.

	3) Run the exploit.

Not common? Compile a list of past reported NULL ptr deference oopses
from the Red Hat bugzilla, kernel bugzilla or the LKML. Check how many
of those could be triggered via normal syscall/unprivileged code paths.

You didn't answer my follow-up to your initial mail arguing the patch
was of no use, where I described a realistic scenario. Does that mean
you agree with it? If not, I would like to hear your opinion.

	Larry

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Larry H. wrote:
> 
> Are you saying that a kernel exploit can't be leveraged by means of
> runtime code injection for example?

No. I'm sayng that sane people don't get hung up about every little 
possibility.

Why are security people always so damn black-and-white? In most other 
areas, such people are called "crazy" or "stupid", but the security people 
seem to call them "normal".

The fact, the NULL pointer attack is neither easy nor common. It's 
perfectly reasonable to say "we'll allow mmap at virtual address zero".

Disallowing NULL pointer mmap's is one small tool in your toolchest, and 
not at all all-consumingly important or fundamental. It's just one more 
detail.

Get over it. Don't expect everybody to be as extremist as you apparently 
are.

			Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Larry H.]

On 11:12 Wed 03 Jun     , Linus Torvalds wrote:
> 
> 
> On Wed, 3 Jun 2009, Larry H. wrote:
> > 
> > Are you saying that a kernel exploit can't be leveraged by means of
> > runtime code injection for example?
> 
> No. I'm sayng that sane people don't get hung up about every little 
> possibility.

Nothing of what has been mentioned is a little possibility. Far from it.

> Why are security people always so damn black-and-white? In most other 
> areas, such people are called "crazy" or "stupid", but the security people 
> seem to call them "normal".

Security people? I honestly share some of the opinions on the industry
that you might have, and I'm likely taking a gamble stating this
publicly.  You are right, there are bleeding imbeciles there. I'm not
part of that 'security people', and will never consider me one. My
interest on security, long time ago, started at the defensive side. I've
been doing kernel development for almost 5 years focusing on
developing _solutions_, not problems. Understanding the offensive side
in depth is a necessity if you want to be realistic on the defensive
one.

If I can help you understand it, and other kernel developers, to come to
a point where realistic, effective security improvements are deployed in
the kernel, we will have accomplished the one and only goal I had when I
started talking to riel or proposing patches.

> 
> The fact, the NULL pointer attack is neither easy nor common. It's 
> perfectly reasonable to say "we'll allow mmap at virtual address zero".

And how could you calibrate if this attack venue isn't easy to take
advantage of? Or not commonly abused? What empirical results led you to this
conclusion?

> Disallowing NULL pointer mmap's is one small tool in your toolchest, and 
> not at all all-consumingly important or fundamental. It's just one more 
> detail.

Definitely, another layer, part of a complex set of measures to deter
different kinds of flaws from all feasible sides. Fundamental to avoid
the situation it is designed to prevent. In the same way as changing
some pointers in the kernel for preventing unwise values to be used when
returning from 'unusual' code paths (kmalloc(0) for example).

> Get over it. Don't expect everybody to be as extremist as you apparently 
> are.

Extremism is the new buzzword. What's next? I'm not the one following up
with dogmatic responses lacking any reasoning. I've supported my claims
every time I expressed them so far. And when I was mistaken or agreed
with a different opinion, I made it clear as well.

Sorry, Linus, but you are taking a long shot calling people names.

	Larry

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Larry H. wrote:
> > 
> > The fact, the NULL pointer attack is neither easy nor common. It's 
> > perfectly reasonable to say "we'll allow mmap at virtual address zero".
> 
> And how could you calibrate if this attack venue isn't easy to take
> advantage of? Or not commonly abused? What empirical results led you to this
> conclusion?

It's not a primary attack vector. You need to have already broken local 
security to get there - you need to be able to execute code.

That means that you've already by-passed all the main security. It's thus 
by definition less common than attack vectors like buffer overflows that 
give you that capability in the first place.

			Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Linus Torvalds wrote:
> 
> That means that you've already by-passed all the main security. It's thus 
> by definition less common than attack vectors like buffer overflows that 
> give you that capability in the first place.

Btw, you obviously need to then _also_ pair it with some as-yet-unknown 
case of kernel bug to get to that NULL pointer (or zero-sized-alloc 
pointer) problem. 

You _also_ seem to be totally ignoring the fact that we already _do_ 
protect against NULL pointers by default.

So I really don't see why you're making a big deal of this. It's as if you 
were talking about us not randomizing the address space - sure, you can 
turn it off, but so what? We do it by default.

So it boils down to:

 - NULL pointers already cannot be in mmap memory (unless a distro has 
   done something wrong - outside of the kernel)

 - What's your beef? Let it go, man.

			Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Christoph Lameter]

We could just move the check for mmap_min_addr out from
CONFIG_SECURITY?


Use mmap_min_addr indepedently of security models

This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY.
It also sets a default mmap_min_addr of 4096.

mmapping of addresses below 4096 will only be possible for processes
with CAP_SYS_RAWIO.


Signed-off-by: Christoph Lameter <cl@linux-foundation.org>

---
 include/linux/mm.h    |    2 --
 kernel/sysctl.c       |    2 --
 mm/Kconfig            |   19 +++++++++++++++++++
 mm/mmap.c             |    6 ++++++
 security/Kconfig      |   20 --------------------
 security/capability.c |    2 --
 security/security.c   |    3 ---
 7 files changed, 25 insertions(+), 29 deletions(-)

Index: linux-2.6/include/linux/mm.h
===================================================================
--- linux-2.6.orig/include/linux/mm.h	2009-06-03 13:48:01.000000000 -0500
+++ linux-2.6/include/linux/mm.h	2009-06-03 13:48:10.000000000 -0500
@@ -580,12 +580,10 @@ static inline void set_page_links(struct
  */
 static inline unsigned long round_hint_to_min(unsigned long hint)
 {
-#ifdef CONFIG_SECURITY
 	hint &= PAGE_MASK;
 	if (((void *)hint != NULL) &&
 	    (hint < mmap_min_addr))
 		return PAGE_ALIGN(mmap_min_addr);
-#endif
 	return hint;
 }

Index: linux-2.6/kernel/sysctl.c
===================================================================
--- linux-2.6.orig/kernel/sysctl.c	2009-06-03 13:48:01.000000000 -0500
+++ linux-2.6/kernel/sysctl.c	2009-06-03 13:48:10.000000000 -0500
@@ -1225,7 +1225,6 @@ static struct ctl_table vm_table[] = {
 		.strategy	= &sysctl_jiffies,
 	},
 #endif
-#ifdef CONFIG_SECURITY
 	{
 		.ctl_name	= CTL_UNNUMBERED,
 		.procname	= "mmap_min_addr",
@@ -1234,7 +1233,6 @@ static struct ctl_table vm_table[] = {
 		.mode		= 0644,
 		.proc_handler	= &proc_doulongvec_minmax,
 	},
-#endif
 #ifdef CONFIG_NUMA
 	{
 		.ctl_name	= CTL_UNNUMBERED,
Index: linux-2.6/mm/mmap.c
===================================================================
--- linux-2.6.orig/mm/mmap.c	2009-06-03 13:48:01.000000000 -0500
+++ linux-2.6/mm/mmap.c	2009-06-03 13:48:10.000000000 -0500
@@ -87,6 +87,9 @@ int sysctl_overcommit_ratio = 50;	/* def
 int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT;
 struct percpu_counter vm_committed_as;

+/* amount of vm to protect from userspace access */
+unsigned long mmap_min_addr = CONFIG_DEFAULT_MMAP_MIN_ADDR;
+
 /*
  * Check that a process has enough memory to allocate a new virtual
  * mapping. 0 means there is enough memory for the allocation to
@@ -1043,6 +1046,9 @@ unsigned long do_mmap_pgoff(struct file
 		}
 	}

+	if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))
+		return -EACCES;
+
 	error = security_file_mmap(file, reqprot, prot, flags, addr, 0);
 	if (error)
 		return error;
Index: linux-2.6/security/security.c
===================================================================
--- linux-2.6.orig/security/security.c	2009-06-03 13:48:01.000000000 -0500
+++ linux-2.6/security/security.c	2009-06-03 13:48:10.000000000 -0500
@@ -26,9 +26,6 @@ extern void security_fixup_ops(struct se

 struct security_operations *security_ops;	/* Initialized to NULL */

-/* amount of vm to protect from userspace access */
-unsigned long mmap_min_addr = CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR;
-
 static inline int verify(struct security_operations *ops)
 {
 	/* verify the security_operations structure exists */
Index: linux-2.6/mm/Kconfig
===================================================================
--- linux-2.6.orig/mm/Kconfig	2009-06-03 13:48:01.000000000 -0500
+++ linux-2.6/mm/Kconfig	2009-06-03 13:48:10.000000000 -0500
@@ -226,6 +226,25 @@ config HAVE_MLOCKED_PAGE_BIT
 config MMU_NOTIFIER
 	bool

+config DEFAULT_MMAP_MIN_ADDR
+        int "Low address space to protect from user allocation"
+        default 4096
+        help
+	  This is the portion of low virtual memory which should be protected
+	  from userspace allocation.  Keeping a user from writing to low pages
+	  can help reduce the impact of kernel NULL pointer bugs.
+
+	  For most ia64, ppc64 and x86 users with lots of address space
+	  a value of 65536 is reasonable and should cause no problems.
+	  On arm and other archs it should not be higher than 32768.
+	  Programs which use vm86 functionality would either need additional
+	  permissions from either the LSM or the capabilities module or have
+	  this protection disabled.
+
+	  This value can be changed after boot using the
+	  /proc/sys/vm/mmap_min_addr tunable.
+
+
 config NOMMU_INITIAL_TRIM_EXCESS
 	int "Turn on mmap() excess space trimming before booting"
 	depends on !MMU
Index: linux-2.6/security/Kconfig
===================================================================
--- linux-2.6.orig/security/Kconfig	2009-06-03 13:48:01.000000000 -0500
+++ linux-2.6/security/Kconfig	2009-06-03 13:48:10.000000000 -0500
@@ -113,26 +113,6 @@ config SECURITY_ROOTPLUG

 	  If you are unsure how to answer this question, answer N.

-config SECURITY_DEFAULT_MMAP_MIN_ADDR
-        int "Low address space to protect from user allocation"
-        depends on SECURITY
-        default 0
-        help
-	  This is the portion of low virtual memory which should be protected
-	  from userspace allocation.  Keeping a user from writing to low pages
-	  can help reduce the impact of kernel NULL pointer bugs.
-
-	  For most ia64, ppc64 and x86 users with lots of address space
-	  a value of 65536 is reasonable and should cause no problems.
-	  On arm and other archs it should not be higher than 32768.
-	  Programs which use vm86 functionality would either need additional
-	  permissions from either the LSM or the capabilities module or have
-	  this protection disabled.
-
-	  This value can be changed after boot using the
-	  /proc/sys/vm/mmap_min_addr tunable.
-
-
 source security/selinux/Kconfig
 source security/smack/Kconfig
 source security/tomoyo/Kconfig
Index: linux-2.6/security/capability.c
===================================================================
--- linux-2.6.orig/security/capability.c	2009-06-03 13:48:01.000000000 -0500
+++ linux-2.6/security/capability.c	2009-06-03 13:48:10.000000000 -0500
@@ -334,8 +334,6 @@ static int cap_file_mmap(struct file *fi
 			 unsigned long prot, unsigned long flags,
 			 unsigned long addr, unsigned long addr_only)
 {
-	if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))
-		return -EACCES;
 	return 0;
 }

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Rik van Riel]

Christoph Lameter wrote:
> We could just move the check for mmap_min_addr out from
> CONFIG_SECURITY?
> 
> 
> Use mmap_min_addr indepedently of security models
> 
> This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY.
> It also sets a default mmap_min_addr of 4096.
> 
> mmapping of addresses below 4096 will only be possible for processes
> with CAP_SYS_RAWIO.
> 
> 
> Signed-off-by: Christoph Lameter <cl@linux-foundation.org>

Acked-by: Rik van Riel <riel@redhat.com>

-- 
All rights reversed.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Eric Paris]

On Wed, Jun 3, 2009 at 2:59 PM, Christoph Lameter
<cl@linux-foundation.org> wrote:
> We could just move the check for mmap_min_addr out from
> CONFIG_SECURITY?
>
>
> Use mmap_min_addr indepedently of security models
>
> This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY.
> It also sets a default mmap_min_addr of 4096.
>
> mmapping of addresses below 4096 will only be possible for processes
> with CAP_SYS_RAWIO.
>
>
> Signed-off-by: Christoph Lameter <cl@linux-foundation.org>

NAK  with SELinux on you now need both the SELinux mmap_zero
permission and the CAP_SYS_RAWIO permission.  Previously you only
needed one or the other, depending on which was the predominant
LSM.....

Even if you want to argue that I have to take CAP_SYS_RAWIO in the
SELinux case what about all the other places?  do_mremap?  do_brk?
expand_downwards?

-Eric


> ===================================================================
> --- linux-2.6.orig/mm/mmap.c    2009-06-03 13:48:01.000000000 -0500
> +++ linux-2.6/mm/mmap.c 2009-06-03 13:48:10.000000000 -0500
> @@ -87,6 +87,9 @@ int sysctl_overcommit_ratio = 50;     /* def
>  int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT;
>  struct percpu_counter vm_committed_as;
>
> +/* amount of vm to protect from userspace access */
> +unsigned long mmap_min_addr = CONFIG_DEFAULT_MMAP_MIN_ADDR;
> +
>  /*
>  * Check that a process has enough memory to allocate a new virtual
>  * mapping. 0 means there is enough memory for the allocation to
> @@ -1043,6 +1046,9 @@ unsigned long do_mmap_pgoff(struct file
>                }
>        }
>
> +       if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))
> +               return -EACCES;
> +
>        error = security_file_mmap(file, reqprot, prot, flags, addr, 0);
>        if (error)
>                return error;

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Christoph Lameter]

On Wed, 3 Jun 2009, Eric Paris wrote:

> NAK  with SELinux on you now need both the SELinux mmap_zero
> permission and the CAP_SYS_RAWIO permission.  Previously you only
> needed one or the other, depending on which was the predominant
> LSM.....

CAP_SYS_RAWIO is checked so you only need to check for mmap_zero in
SELinux.

> Even if you want to argue that I have to take CAP_SYS_RAWIO in the
> SELinux case what about all the other places?  do_mremap?  do_brk?
> expand_downwards?

brk(0) would free up all the code? The others could be added.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Eric Paris]

On Wed, Jun 3, 2009 at 3:42 PM, Christoph Lameter
<cl@linux-foundation.org> wrote:
> On Wed, 3 Jun 2009, Eric Paris wrote:
>
>> NAK  with SELinux on you now need both the SELinux mmap_zero
>> permission and the CAP_SYS_RAWIO permission.  Previously you only
>> needed one or the other, depending on which was the predominant
>> LSM.....
>
> CAP_SYS_RAWIO is checked so you only need to check for mmap_zero in
> SELinux.

You misunderstand.  As it stands today if you use SELinux you need
only the selinux mmap_zero permission.  If you use capabilities you
need CAP_SYS_RAWIO.

With your patch SELinux policy would now have to grant CAP_SYS_RAWIO
everywhere it grants mmap_zero.  This not not acceptable.  Take notice
that with SELinux enabled cap_file_mmap is never called.....


>> Even if you want to argue that I have to take CAP_SYS_RAWIO in the
>> SELinux case what about all the other places?  do_mremap?  do_brk?
>> expand_downwards?
>
> brk(0) would free up all the code? The others could be added.

The 'right'est fix is as Alan suggested, duplicate the code

from security/capability.c::cap_file_mmap()
to include/linux/security.h::securitry_file_mmap()

-Eric

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Christoph Lameter]

On Wed, 3 Jun 2009, Eric Paris wrote:

> The 'right'est fix is as Alan suggested, duplicate the code
>
> from security/capability.c::cap_file_mmap()
> to include/linux/security.h::securitry_file_mmap()

Thats easy to do but isnt it a bit weird now to configure mmap_min_addr?
A security model may give it a different interpretation?
What about round_hint_to_min()?


Use mmap_min_addr indepedently of security models

This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY.
It also sets a default mmap_min_addr of 4096.

mmapping of addresses below 4096 will only be possible for processes
with CAP_SYS_RAWIO.


Signed-off-by: Christoph Lameter <cl@linux-foundation.org>

---
 include/linux/mm.h       |    2 --
 include/linux/security.h |    2 ++
 kernel/sysctl.c          |    2 --
 mm/Kconfig               |   19 +++++++++++++++++++
 mm/mmap.c                |    3 +++
 security/Kconfig         |   20 --------------------
 security/security.c      |    3 ---
 7 files changed, 24 insertions(+), 27 deletions(-)

Index: linux-2.6/include/linux/mm.h
===================================================================
--- linux-2.6.orig/include/linux/mm.h	2009-06-03 15:00:54.000000000 -0500
+++ linux-2.6/include/linux/mm.h	2009-06-03 15:00:56.000000000 -0500
@@ -580,12 +580,10 @@ static inline void set_page_links(struct
  */
 static inline unsigned long round_hint_to_min(unsigned long hint)
 {
-#ifdef CONFIG_SECURITY
 	hint &= PAGE_MASK;
 	if (((void *)hint != NULL) &&
 	    (hint < mmap_min_addr))
 		return PAGE_ALIGN(mmap_min_addr);
-#endif
 	return hint;
 }

Index: linux-2.6/kernel/sysctl.c
===================================================================
--- linux-2.6.orig/kernel/sysctl.c	2009-06-03 15:00:54.000000000 -0500
+++ linux-2.6/kernel/sysctl.c	2009-06-03 15:00:56.000000000 -0500
@@ -1225,7 +1225,6 @@ static struct ctl_table vm_table[] = {
 		.strategy	= &sysctl_jiffies,
 	},
 #endif
-#ifdef CONFIG_SECURITY
 	{
 		.ctl_name	= CTL_UNNUMBERED,
 		.procname	= "mmap_min_addr",
@@ -1234,7 +1233,6 @@ static struct ctl_table vm_table[] = {
 		.mode		= 0644,
 		.proc_handler	= &proc_doulongvec_minmax,
 	},
-#endif
 #ifdef CONFIG_NUMA
 	{
 		.ctl_name	= CTL_UNNUMBERED,
Index: linux-2.6/mm/mmap.c
===================================================================
--- linux-2.6.orig/mm/mmap.c	2009-06-03 15:00:54.000000000 -0500
+++ linux-2.6/mm/mmap.c	2009-06-03 15:01:18.000000000 -0500
@@ -87,6 +87,9 @@ int sysctl_overcommit_ratio = 50;	/* def
 int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT;
 struct percpu_counter vm_committed_as;

+/* amount of vm to protect from userspace access */
+unsigned long mmap_min_addr = CONFIG_DEFAULT_MMAP_MIN_ADDR;
+
 /*
  * Check that a process has enough memory to allocate a new virtual
  * mapping. 0 means there is enough memory for the allocation to
Index: linux-2.6/security/security.c
===================================================================
--- linux-2.6.orig/security/security.c	2009-06-03 15:00:54.000000000 -0500
+++ linux-2.6/security/security.c	2009-06-03 15:00:56.000000000 -0500
@@ -26,9 +26,6 @@ extern void security_fixup_ops(struct se

 struct security_operations *security_ops;	/* Initialized to NULL */

-/* amount of vm to protect from userspace access */
-unsigned long mmap_min_addr = CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR;
-
 static inline int verify(struct security_operations *ops)
 {
 	/* verify the security_operations structure exists */
Index: linux-2.6/mm/Kconfig
===================================================================
--- linux-2.6.orig/mm/Kconfig	2009-06-03 15:00:54.000000000 -0500
+++ linux-2.6/mm/Kconfig	2009-06-03 15:00:56.000000000 -0500
@@ -226,6 +226,25 @@ config HAVE_MLOCKED_PAGE_BIT
 config MMU_NOTIFIER
 	bool

+config DEFAULT_MMAP_MIN_ADDR
+        int "Low address space to protect from user allocation"
+        default 4096
+        help
+	  This is the portion of low virtual memory which should be protected
+	  from userspace allocation.  Keeping a user from writing to low pages
+	  can help reduce the impact of kernel NULL pointer bugs.
+
+	  For most ia64, ppc64 and x86 users with lots of address space
+	  a value of 65536 is reasonable and should cause no problems.
+	  On arm and other archs it should not be higher than 32768.
+	  Programs which use vm86 functionality would either need additional
+	  permissions from either the LSM or the capabilities module or have
+	  this protection disabled.
+
+	  This value can be changed after boot using the
+	  /proc/sys/vm/mmap_min_addr tunable.
+
+
 config NOMMU_INITIAL_TRIM_EXCESS
 	int "Turn on mmap() excess space trimming before booting"
 	depends on !MMU
Index: linux-2.6/security/Kconfig
===================================================================
--- linux-2.6.orig/security/Kconfig	2009-06-03 15:00:54.000000000 -0500
+++ linux-2.6/security/Kconfig	2009-06-03 15:00:56.000000000 -0500
@@ -113,26 +113,6 @@ config SECURITY_ROOTPLUG

 	  If you are unsure how to answer this question, answer N.

-config SECURITY_DEFAULT_MMAP_MIN_ADDR
-        int "Low address space to protect from user allocation"
-        depends on SECURITY
-        default 0
-        help
-	  This is the portion of low virtual memory which should be protected
-	  from userspace allocation.  Keeping a user from writing to low pages
-	  can help reduce the impact of kernel NULL pointer bugs.
-
-	  For most ia64, ppc64 and x86 users with lots of address space
-	  a value of 65536 is reasonable and should cause no problems.
-	  On arm and other archs it should not be higher than 32768.
-	  Programs which use vm86 functionality would either need additional
-	  permissions from either the LSM or the capabilities module or have
-	  this protection disabled.
-
-	  This value can be changed after boot using the
-	  /proc/sys/vm/mmap_min_addr tunable.
-
-
 source security/selinux/Kconfig
 source security/smack/Kconfig
 source security/tomoyo/Kconfig
Index: linux-2.6/include/linux/security.h
===================================================================
--- linux-2.6.orig/include/linux/security.h	2009-06-03 15:01:28.000000000 -0500
+++ linux-2.6/include/linux/security.h	2009-06-03 15:01:42.000000000 -0500
@@ -2197,6 +2197,8 @@ static inline int security_file_mmap(str
 				     unsigned long addr,
 				     unsigned long addr_only)
 {
+	if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))
+		return -EACCES;
 	return 0;
 }

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Eric Paris]

On Wed, Jun 3, 2009 at 4:04 PM, Christoph Lameter
<cl@linux-foundation.org> wrote:
> On Wed, 3 Jun 2009, Eric Paris wrote:
>
>> The 'right'est fix is as Alan suggested, duplicate the code
>>
>> from security/capability.c::cap_file_mmap()
>> to include/linux/security.h::securitry_file_mmap()
>
> Thats easy to do but isnt it a bit weird now to configure mmap_min_addr?

??

> A security model may give it a different interpretation?

Not sure what you mean.  Yes, each security model is allowed to decide
what permissions are needed to pass a given security check.  SELinux
decided that CAP_SYS_RAWIO was not needed, but the selinux permission
mmap_zero was.  Had there been a more specific capability to use
SELinux might have been happy using a capability...

> What about round_hint_to_min()?

not sure what you mean....

>
> Use mmap_min_addr indepedently of security models
>
> This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY.
> It also sets a default mmap_min_addr of 4096.
>
> mmapping of addresses below 4096 will only be possible for processes
> with CAP_SYS_RAWIO.

<pedantic nit> "or the appropriate permission for the given LSM </pedantic nit>

> Signed-off-by: Christoph Lameter <cl@linux-foundation.org>

Clearly lots more cleanup can be done between CONFIG_SECURITY and
!CONFIG_SECURITY like Linus suggested, but

Acked-by: Eric Paris <eparis@redhat.com>

> ---
>  include/linux/mm.h       |    2 --
>  include/linux/security.h |    2 ++
>  kernel/sysctl.c          |    2 --
>  mm/Kconfig               |   19 +++++++++++++++++++
>  mm/mmap.c                |    3 +++
>  security/Kconfig         |   20 --------------------
>  security/security.c      |    3 ---
>  7 files changed, 24 insertions(+), 27 deletions(-)
>
> Index: linux-2.6/include/linux/mm.h
> ===================================================================
> --- linux-2.6.orig/include/linux/mm.h   2009-06-03 15:00:54.000000000 -0500
> +++ linux-2.6/include/linux/mm.h        2009-06-03 15:00:56.000000000 -0500
> @@ -580,12 +580,10 @@ static inline void set_page_links(struct
>  */
>  static inline unsigned long round_hint_to_min(unsigned long hint)
>  {
> -#ifdef CONFIG_SECURITY
>        hint &= PAGE_MASK;
>        if (((void *)hint != NULL) &&
>            (hint < mmap_min_addr))
>                return PAGE_ALIGN(mmap_min_addr);
> -#endif
>        return hint;
>  }
>
> Index: linux-2.6/kernel/sysctl.c
> ===================================================================
> --- linux-2.6.orig/kernel/sysctl.c      2009-06-03 15:00:54.000000000 -0500
> +++ linux-2.6/kernel/sysctl.c   2009-06-03 15:00:56.000000000 -0500
> @@ -1225,7 +1225,6 @@ static struct ctl_table vm_table[] = {
>                .strategy       = &sysctl_jiffies,
>        },
>  #endif
> -#ifdef CONFIG_SECURITY
>        {
>                .ctl_name       = CTL_UNNUMBERED,
>                .procname       = "mmap_min_addr",
> @@ -1234,7 +1233,6 @@ static struct ctl_table vm_table[] = {
>                .mode           = 0644,
>                .proc_handler   = &proc_doulongvec_minmax,
>        },
> -#endif
>  #ifdef CONFIG_NUMA
>        {
>                .ctl_name       = CTL_UNNUMBERED,
> Index: linux-2.6/mm/mmap.c
> ===================================================================
> --- linux-2.6.orig/mm/mmap.c    2009-06-03 15:00:54.000000000 -0500
> +++ linux-2.6/mm/mmap.c 2009-06-03 15:01:18.000000000 -0500
> @@ -87,6 +87,9 @@ int sysctl_overcommit_ratio = 50;     /* def
>  int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT;
>  struct percpu_counter vm_committed_as;
>
> +/* amount of vm to protect from userspace access */
> +unsigned long mmap_min_addr = CONFIG_DEFAULT_MMAP_MIN_ADDR;
> +
>  /*
>  * Check that a process has enough memory to allocate a new virtual
>  * mapping. 0 means there is enough memory for the allocation to
> Index: linux-2.6/security/security.c
> ===================================================================
> --- linux-2.6.orig/security/security.c  2009-06-03 15:00:54.000000000 -0500
> +++ linux-2.6/security/security.c       2009-06-03 15:00:56.000000000 -0500
> @@ -26,9 +26,6 @@ extern void security_fixup_ops(struct se
>
>  struct security_operations *security_ops;      /* Initialized to NULL */
>
> -/* amount of vm to protect from userspace access */
> -unsigned long mmap_min_addr = CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR;
> -
>  static inline int verify(struct security_operations *ops)
>  {
>        /* verify the security_operations structure exists */
> Index: linux-2.6/mm/Kconfig
> ===================================================================
> --- linux-2.6.orig/mm/Kconfig   2009-06-03 15:00:54.000000000 -0500
> +++ linux-2.6/mm/Kconfig        2009-06-03 15:00:56.000000000 -0500
> @@ -226,6 +226,25 @@ config HAVE_MLOCKED_PAGE_BIT
>  config MMU_NOTIFIER
>        bool
>
> +config DEFAULT_MMAP_MIN_ADDR
> +        int "Low address space to protect from user allocation"
> +        default 4096
> +        help
> +         This is the portion of low virtual memory which should be protected
> +         from userspace allocation.  Keeping a user from writing to low pages
> +         can help reduce the impact of kernel NULL pointer bugs.
> +
> +         For most ia64, ppc64 and x86 users with lots of address space
> +         a value of 65536 is reasonable and should cause no problems.
> +         On arm and other archs it should not be higher than 32768.
> +         Programs which use vm86 functionality would either need additional
> +         permissions from either the LSM or the capabilities module or have
> +         this protection disabled.
> +
> +         This value can be changed after boot using the
> +         /proc/sys/vm/mmap_min_addr tunable.
> +
> +
>  config NOMMU_INITIAL_TRIM_EXCESS
>        int "Turn on mmap() excess space trimming before booting"
>        depends on !MMU
> Index: linux-2.6/security/Kconfig
> ===================================================================
> --- linux-2.6.orig/security/Kconfig     2009-06-03 15:00:54.000000000 -0500
> +++ linux-2.6/security/Kconfig  2009-06-03 15:00:56.000000000 -0500
> @@ -113,26 +113,6 @@ config SECURITY_ROOTPLUG
>
>          If you are unsure how to answer this question, answer N.
>
> -config SECURITY_DEFAULT_MMAP_MIN_ADDR
> -        int "Low address space to protect from user allocation"
> -        depends on SECURITY
> -        default 0
> -        help
> -         This is the portion of low virtual memory which should be protected
> -         from userspace allocation.  Keeping a user from writing to low pages
> -         can help reduce the impact of kernel NULL pointer bugs.
> -
> -         For most ia64, ppc64 and x86 users with lots of address space
> -         a value of 65536 is reasonable and should cause no problems.
> -         On arm and other archs it should not be higher than 32768.
> -         Programs which use vm86 functionality would either need additional
> -         permissions from either the LSM or the capabilities module or have
> -         this protection disabled.
> -
> -         This value can be changed after boot using the
> -         /proc/sys/vm/mmap_min_addr tunable.
> -
> -
>  source security/selinux/Kconfig
>  source security/smack/Kconfig
>  source security/tomoyo/Kconfig
> Index: linux-2.6/include/linux/security.h
> ===================================================================
> --- linux-2.6.orig/include/linux/security.h     2009-06-03 15:01:28.000000000 -0500
> +++ linux-2.6/include/linux/security.h  2009-06-03 15:01:42.000000000 -0500
> @@ -2197,6 +2197,8 @@ static inline int security_file_mmap(str
>                                     unsigned long addr,
>                                     unsigned long addr_only)
>  {
> +       if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))
> +               return -EACCES;
>        return 0;
>  }
>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Christoph Lameter]

On Wed, 3 Jun 2009, Eric Paris wrote:

> > Thats easy to do but isnt it a bit weird now to configure mmap_min_addr?
>
> ??

The use of mmap_min_addr depends on the security configuration chose. The
security model may not check at all. But we can still configure the thing.

> > What about round_hint_to_min()?
>
> not sure what you mean....

We removed the CONFIG_SECURITY around code in there in the patch.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Christoph Lameter wrote:
> 
> Use mmap_min_addr indepedently of security models

Looks ok by me. As mentioned, it would be nice if the coherency with the 
'capabilities' security module was something inherent to the code, but 
this looks like a sane minimal patch.

			Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[James Morris]

On Wed, 3 Jun 2009, Christoph Lameter wrote:

> Use mmap_min_addr indepedently of security models
> 
> This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY.
> It also sets a default mmap_min_addr of 4096.
> 
> mmapping of addresses below 4096 will only be possible for processes
> with CAP_SYS_RAWIO.
> 
> 
> Signed-off-by: Christoph Lameter <cl@linux-foundation.org>


Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next

> 
> ---
>  include/linux/mm.h       |    2 --
>  include/linux/security.h |    2 ++
>  kernel/sysctl.c          |    2 --
>  mm/Kconfig               |   19 +++++++++++++++++++
>  mm/mmap.c                |    3 +++
>  security/Kconfig         |   20 --------------------
>  security/security.c      |    3 ---
>  7 files changed, 24 insertions(+), 27 deletions(-)
> 
> Index: linux-2.6/include/linux/mm.h
> ===================================================================
> --- linux-2.6.orig/include/linux/mm.h	2009-06-03 15:00:54.000000000 -0500
> +++ linux-2.6/include/linux/mm.h	2009-06-03 15:00:56.000000000 -0500
> @@ -580,12 +580,10 @@ static inline void set_page_links(struct
>   */
>  static inline unsigned long round_hint_to_min(unsigned long hint)
>  {
> -#ifdef CONFIG_SECURITY
>  	hint &= PAGE_MASK;
>  	if (((void *)hint != NULL) &&
>  	    (hint < mmap_min_addr))
>  		return PAGE_ALIGN(mmap_min_addr);
> -#endif
>  	return hint;
>  }
> 
> Index: linux-2.6/kernel/sysctl.c
> ===================================================================
> --- linux-2.6.orig/kernel/sysctl.c	2009-06-03 15:00:54.000000000 -0500
> +++ linux-2.6/kernel/sysctl.c	2009-06-03 15:00:56.000000000 -0500
> @@ -1225,7 +1225,6 @@ static struct ctl_table vm_table[] = {
>  		.strategy	= &sysctl_jiffies,
>  	},
>  #endif
> -#ifdef CONFIG_SECURITY
>  	{
>  		.ctl_name	= CTL_UNNUMBERED,
>  		.procname	= "mmap_min_addr",
> @@ -1234,7 +1233,6 @@ static struct ctl_table vm_table[] = {
>  		.mode		= 0644,
>  		.proc_handler	= &proc_doulongvec_minmax,
>  	},
> -#endif
>  #ifdef CONFIG_NUMA
>  	{
>  		.ctl_name	= CTL_UNNUMBERED,
> Index: linux-2.6/mm/mmap.c
> ===================================================================
> --- linux-2.6.orig/mm/mmap.c	2009-06-03 15:00:54.000000000 -0500
> +++ linux-2.6/mm/mmap.c	2009-06-03 15:01:18.000000000 -0500
> @@ -87,6 +87,9 @@ int sysctl_overcommit_ratio = 50;	/* def
>  int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT;
>  struct percpu_counter vm_committed_as;
> 
> +/* amount of vm to protect from userspace access */
> +unsigned long mmap_min_addr = CONFIG_DEFAULT_MMAP_MIN_ADDR;
> +
>  /*
>   * Check that a process has enough memory to allocate a new virtual
>   * mapping. 0 means there is enough memory for the allocation to
> Index: linux-2.6/security/security.c
> ===================================================================
> --- linux-2.6.orig/security/security.c	2009-06-03 15:00:54.000000000 -0500
> +++ linux-2.6/security/security.c	2009-06-03 15:00:56.000000000 -0500
> @@ -26,9 +26,6 @@ extern void security_fixup_ops(struct se
> 
>  struct security_operations *security_ops;	/* Initialized to NULL */
> 
> -/* amount of vm to protect from userspace access */
> -unsigned long mmap_min_addr = CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR;
> -
>  static inline int verify(struct security_operations *ops)
>  {
>  	/* verify the security_operations structure exists */
> Index: linux-2.6/mm/Kconfig
> ===================================================================
> --- linux-2.6.orig/mm/Kconfig	2009-06-03 15:00:54.000000000 -0500
> +++ linux-2.6/mm/Kconfig	2009-06-03 15:00:56.000000000 -0500
> @@ -226,6 +226,25 @@ config HAVE_MLOCKED_PAGE_BIT
>  config MMU_NOTIFIER
>  	bool
> 
> +config DEFAULT_MMAP_MIN_ADDR
> +        int "Low address space to protect from user allocation"
> +        default 4096
> +        help
> +	  This is the portion of low virtual memory which should be protected
> +	  from userspace allocation.  Keeping a user from writing to low pages
> +	  can help reduce the impact of kernel NULL pointer bugs.
> +
> +	  For most ia64, ppc64 and x86 users with lots of address space
> +	  a value of 65536 is reasonable and should cause no problems.
> +	  On arm and other archs it should not be higher than 32768.
> +	  Programs which use vm86 functionality would either need additional
> +	  permissions from either the LSM or the capabilities module or have
> +	  this protection disabled.
> +
> +	  This value can be changed after boot using the
> +	  /proc/sys/vm/mmap_min_addr tunable.
> +
> +
>  config NOMMU_INITIAL_TRIM_EXCESS
>  	int "Turn on mmap() excess space trimming before booting"
>  	depends on !MMU
> Index: linux-2.6/security/Kconfig
> ===================================================================
> --- linux-2.6.orig/security/Kconfig	2009-06-03 15:00:54.000000000 -0500
> +++ linux-2.6/security/Kconfig	2009-06-03 15:00:56.000000000 -0500
> @@ -113,26 +113,6 @@ config SECURITY_ROOTPLUG
> 
>  	  If you are unsure how to answer this question, answer N.
> 
> -config SECURITY_DEFAULT_MMAP_MIN_ADDR
> -        int "Low address space to protect from user allocation"
> -        depends on SECURITY
> -        default 0
> -        help
> -	  This is the portion of low virtual memory which should be protected
> -	  from userspace allocation.  Keeping a user from writing to low pages
> -	  can help reduce the impact of kernel NULL pointer bugs.
> -
> -	  For most ia64, ppc64 and x86 users with lots of address space
> -	  a value of 65536 is reasonable and should cause no problems.
> -	  On arm and other archs it should not be higher than 32768.
> -	  Programs which use vm86 functionality would either need additional
> -	  permissions from either the LSM or the capabilities module or have
> -	  this protection disabled.
> -
> -	  This value can be changed after boot using the
> -	  /proc/sys/vm/mmap_min_addr tunable.
> -
> -
>  source security/selinux/Kconfig
>  source security/smack/Kconfig
>  source security/tomoyo/Kconfig
> Index: linux-2.6/include/linux/security.h
> ===================================================================
> --- linux-2.6.orig/include/linux/security.h	2009-06-03 15:01:28.000000000 -0500
> +++ linux-2.6/include/linux/security.h	2009-06-03 15:01:42.000000000 -0500
> @@ -2197,6 +2197,8 @@ static inline int security_file_mmap(str
>  				     unsigned long addr,
>  				     unsigned long addr_only)
>  {
> +	if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))
> +		return -EACCES;
>  	return 0;
>  }
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 

-- 
James Morris
<jmorris@namei.org>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Alan Cox]

On Wed, 3 Jun 2009 14:59:51 -0400 (EDT)
Christoph Lameter <cl@linux-foundation.org> wrote:

> We could just move the check for mmap_min_addr out from
> CONFIG_SECURITY?
> 
> 
> Use mmap_min_addr indepedently of security models
> 
> This patch removes the dependency of mmap_min_addr on CONFIG_SECURITY.
> It also sets a default mmap_min_addr of 4096.
> 
> mmapping of addresses below 4096 will only be possible for processes
> with CAP_SYS_RAWIO.

This appears to break the security models as they can no longer replace
the CAP_SYS_RAWIO check with something based on the security model.

> @@ -1043,6 +1046,9 @@ unsigned long do_mmap_pgoff(struct file
>  		}
>  	}
> 
> +	if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))
> +		return -EACCES;
> +

You can't move this bit here

>  	error = security_file_mmap(file, reqprot, prot, flags, addr, 0);

You need it in the default (no security) version of security_file_mmap()
in security.h not hard coded into do_mmap_pgoff, and leave the one in
cap_* alone.

So NAK - not to the idea but to the fact the patch is buggy.

Alan

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Christoph Lameter]

On Wed, 3 Jun 2009, Alan Cox wrote:

> This appears to break the security models as they can no longer replace
> the CAP_SYS_RAWIO check with something based on the security model.

Right it would be fixed like CAP_SYS_NICE.

>
> > @@ -1043,6 +1046,9 @@ unsigned long do_mmap_pgoff(struct file
> >  		}
> >  	}
> >
> > +	if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO))
> > +		return -EACCES;
> > +
>
> You can't move this bit here

The same code is executed in security_file_mmap right now which is the
next function called at this spot.

> >  	error = security_file_mmap(file, reqprot, prot, flags, addr, 0);
>
> You need it in the default (no security) version of security_file_mmap()
> in security.h not hard coded into do_mmap_pgoff, and leave the one in
> cap_* alone.

But that would still leave it up to the security "models" to check
for basic security issues.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Alan Cox]

> > You need it in the default (no security) version of security_file_mmap()
> > in security.h not hard coded into do_mmap_pgoff, and leave the one in
> > cap_* alone.
> 
> But that would still leave it up to the security "models" to check
> for basic security issues.

Correct. You have no knowledge of the policy at the higher level. In the
SELinux case security labels are used to identify code which is permitted
to map low pages. That means the root/RAW_IO security sledgehammer can be
replaced with a more secure labelling system.

Other policy systems might do it on namespaces (perhaps /bin
and /usr/bin mapping zero OK, /home not etc)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Linus Torvalds]

On Wed, 3 Jun 2009, Christoph Lameter wrote:
>
> We could just move the check for mmap_min_addr out from
> CONFIG_SECURITY?

No.

The thing is, the security model wants to modify the rules on what's 
"secure" and what isn't. And your patch just hard-coded that 
capable(CAP_SYS_RAWIO) decision - but that's not what something like 
SElinux actually uses to decide whether it's ok or not.

So if you do it in generic code, you'd have to make it much more complex. 
One option would be to change the rule for what "security_file_mmap()" 
means, and make the return value says "yes, no, override". Where 
"override" would be "allow it for this process even if it's below the 
minimum mmap limit.

But the better option really is to just copy the cap_file_mmap() rule to 
the !SECURITY rule, and make !SECURITY really mean the same as "always do 
default security", the way it's documented.

			Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Christoph Lameter]

On Wed, 3 Jun 2009, Linus Torvalds wrote:

> But the better option really is to just copy the cap_file_mmap() rule to
> the !SECURITY rule, and make !SECURITY really mean the same as "always do
> default security", the way it's documented.

Na, I really like the ability to just avoid having to deal with this
"security" stuff (CONFIG_SECURITY). And core security checks sidelined in
some security model config thingy? I'd prefer to see these checks right
there in core code while working on them.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[pageexec]

On 3 Jun 2009 at 11:50, Linus Torvalds wrote:

> 
> 
> On Wed, 3 Jun 2009, Linus Torvalds wrote:
> > 
> > That means that you've already by-passed all the main security. It's thus 
> > by definition less common than attack vectors like buffer overflows that 
> > give you that capability in the first place.
> 
> Btw, you obviously need to then _also_ pair it with some as-yet-unknown 
> case of kernel bug to get to that NULL pointer (or zero-sized-alloc 
> pointer) problem. 

are you saying it's hard to find 'as-yet-unknown' null-deref bugs? what about
'already-known-but-not-yet-fixed-in-distro-kernel' ones? especially when the
disclosure process was, let's say, less than 'full'.

> You _also_ seem to be totally ignoring the fact that we already _do_ 
> protect against NULL pointers by default.

this whole discussion about NULL derefs is quite missing the point by the way.
the proper bug class is about unintended userland ptr derefs by the kernel,
of which NULL derefs are a small subset only. and you can't protect against
it by default or otherwise by banning userland from using its address space ;).

fixing ZERO_SIZE_PTR is about not making the mess of mixing userland/kernel
addresses worse, that's all. small piece of the parcel but then it's obviously
correct too.

> So I really don't see why you're making a big deal of this. It's as if you 
> were talking about us not randomizing the address space - sure, you can 
> turn it off, but so what? We do it by default.

and the amount of it is easily bruteforceable not to mention lack of
protection against said bruteforce. don't rest on your laurels yet ;).

> So it boils down to:
> 
>  - NULL pointers already cannot be in mmap memory

not all NULL deref bugs are literally around address 0, there's often an
offset involved, sometimes even under the attacker's control (a famous
userland example is discussed in 
   http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf
).

> (unless a distro has 
>    done something wrong - outside of the kernel)

do you have data about which distros and kernels enable this? and how
they handle v86 and stuff? suid root equivalent or something better?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[pageexec]

On 3 Jun 2009 at 11:45, Linus Torvalds wrote:

> 
> 
> On Wed, 3 Jun 2009, Larry H. wrote:
> > > 
> > > The fact, the NULL pointer attack is neither easy nor common. It's 
> > > perfectly reasonable to say "we'll allow mmap at virtual address zero".
> > 
> > And how could you calibrate if this attack venue isn't easy to take
> > advantage of? Or not commonly abused? What empirical results led you to this
> > conclusion?
> 
> It's not a primary attack vector. You need to have already broken local 
> security to get there - you need to be able to execute code.

during last summer's flame war^W^Wdiscussion about how you guys were covering
up security fixes you brought an example of smart university students breaking
communal boxes left and right. are you now saying that it was actually a strawman
argument as you consider that situation already broken? you can't have it both
ways ;).

> That means that you've already by-passed all the main security. It's thus 
> by definition less common than attack vectors like buffer overflows that 
> give you that capability in the first place.

that only means that you've ignored multi-user boxes.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

[Pavel Machek]

Hi!

> Ok. So what we need to do is stop this toying around with remapping of
> page 0. The following patch contains a fix and a test program that
> demonstrates the issue.
> 
> 
> Subject: [Security] Do not allow remapping of page 0 via MAP_FIXED
> 
> If one remaps page 0 then the kernel checks for NULL pointers of various
> flavors are bypassed and this may be exploited in various creative ways
> to transfer data from kernel space to user space.

Yes, mmap() at page zero 0 makes exploits harder; and yes disabling it
may be useful (but we tried that before, see Alan's comment). But that
does not it mean it deserves _security_ label. Call it robustness or
something....
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] Change ZERO_SIZE_PTR to point at unmapped space

[Peter Zijlstra]

On Sat, 2009-05-30 at 12:28 -0700, Larry H. wrote:
> [PATCH] Change ZERO_SIZE_PTR to point at unmapped space
> 
> This patch changes the ZERO_SIZE_PTR address to point at top memory
> unmapped space, instead of the original location which could be
> mapped from userland to abuse a NULL (or offset-from-null) pointer
> dereference scenario.

Same goes for the regular NULL pointer, we have bits to disallow
userspace mapping the NULL page, so I'm not exactly seeing what this
patch buys us.

> The ZERO_OR_NULL_PTR macro is changed accordingly. This patch does
> not modify its behavior nor has any performance nor functionality
> impact.

It does generate longer asm.

> The original change was written first by the PaX team for their
> patch.
> 
> Signed-off-by: Larry Highsmith <larry@subreption.com>
> 
> Index: linux-2.6/include/linux/slab.h
> ===================================================================
> --- linux-2.6.orig/include/linux/slab.h
> +++ linux-2.6/include/linux/slab.h
> @@ -73,10 +73,9 @@
>   * ZERO_SIZE_PTR can be passed to kfree though in the same way that NULL can.
>   * Both make kfree a no-op.
>   */
> -#define ZERO_SIZE_PTR ((void *)16)
> +#define ZERO_SIZE_PTR ((void *)-1024L)
>  
> -#define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) <= \
> -				(unsigned long)ZERO_SIZE_PTR)
> +#define ZERO_OR_NULL_PTR(x) (!(x) || (x) == ZERO_SIZE_PTR)
>  
>  /*
>   * struct kmem_cache related prototypes
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] Change ZERO_SIZE_PTR to point at unmapped space

[Larry H.]

On 00:32 Sun 31 May     , Peter Zijlstra wrote:
> On Sat, 2009-05-30 at 12:28 -0700, Larry H. wrote:
> > [PATCH] Change ZERO_SIZE_PTR to point at unmapped space
> > 
> > This patch changes the ZERO_SIZE_PTR address to point at top memory
> > unmapped space, instead of the original location which could be
> > mapped from userland to abuse a NULL (or offset-from-null) pointer
> > dereference scenario.
> 
> Same goes for the regular NULL pointer, we have bits to disallow
> userspace mapping the NULL page, so I'm not exactly seeing what this
> patch buys us.

mmap_min_addr has a history of being easy to bypass. Let me get this
straight: you are arguing this doesn't bring anything new because an
additional mmap() based check exists, whose purpose is blocking NULL
from being mapped in userland. But the purpose of this patch, is making
sure that any user of ZERO_SIZE_PTR doesn't set some pointer to a
NULL+16 location, but a top memory unmapped address instead. In other
words, this is orthogonal to mmap_min_addr, preventing the situation
that mmap_min_addr is _supposed_ to block, from happening.

Both can coexist, one ensuring pointers don't get set to an userland
reachable/mmap-able region, and the other prevents such a region from
being mapped from userland.

The next patch changes LIST_POISON(1|2) to point at sane addresses as
well. Explaining why this is necessary to you will require you to
understand the security risks of unlinking doubly linked lists, etc. If
you aren't familiar with those concepts, I encourage you to look for
some literature on the matter ("Once upon a free()" is a good start, an
article published in Phrack magazine). Furthermore those changes will
only be effective when list debugging is enabled, therefore it's not
even used by the entire user base.

> > The ZERO_OR_NULL_PTR macro is changed accordingly. This patch does
> > not modify its behavior nor has any performance nor functionality
> > impact.
> 
> It does generate longer asm.

3 more bytes in amd64 (gcc 4.3.3):

 198:   48 83 ff 10             cmp    $0x10,%rdi
 19c:   74 1c                   je     1ba <kzfree+0x33>
 19e:   48 85 ff                test   %rdi,%rdi
 1a1:   74 17                   je     1ba <kzfree+0x33>
 --
 198:   48 81 ff 00 fc ff ff    cmp    $0xfffffffffffffc00,%rdi
 19f:   74 1c                   je     1bd <kzfree+0x36>
 1a1:   48 85 ff                test   %rdi,%rdi
 1a4:   74 17                   je     1bd <kzfree+0x36>

How many users of this macro exist? A dozen or so? Looks like the
security benefits of this patch outweight those 3 extra bytes.

	Larry

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>