Change ZERO_SIZE_PTR to point at unmapped space

[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.

Index: 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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

.. 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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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.

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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.

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?

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.

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.

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.

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)

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.

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

Index: linux-2.6/mm/mmap.c
===================================================================
@@ -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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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

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.

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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

Will poke/patch this afternoon.

-Eric

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

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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).

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.

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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

Would anybody paranoid run their system without SELinux?

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 [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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.

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.

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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
<[email protected]>

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

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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

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.

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?

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).

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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.

---
 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
===================================================================
@@ -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
===================================================================
@@ -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
===================================================================
@@ -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
===================================================================
@@ -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
===================================================================
@@ -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
===================================================================
@@ -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
===================================================================
@@ -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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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

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

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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.

---
 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
===================================================================
@@ -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
===================================================================
@@ -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
===================================================================
@@ -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
===================================================================
@@ -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
===================================================================
@@ -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
===================================================================
@@ -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
===================================================================
@@ -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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

??

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

not sure what you mean....

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

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

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.

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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

James Morris
<[email protected]>

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

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.

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

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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'.

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.

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

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
).

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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 only means that you've ignored multi-user boxes.

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

Hi!

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 [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

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.

It does generate longer asm.

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

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.

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>