linux-kernel - Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 20 Dec 2007 11:07:01 +1100 (EST)
From:	James Morris <jmorris@...ei.org>
To:	David Chinner <dgc@....com>
cc:	lkml <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org,
	Eric Paris <eparis@...hat.com>
Subject: Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace
 poisoning

On Wed, 19 Dec 2007, David Chinner wrote:

> Folks,
> 
> I just updated a git tree and started getting errors on a
> "copy_keys" macro warning.
> 
> The code I've been working on uses a ->copy_keys() method for
> copying the keys in a btree block from one place to another. I've
> been working on this code for a while
> (http://oss.sgi.com/archives/xfs/2007-11/msg00046.html) and keep the
> tree I'm working in reletively up to date (lags linus by a couple of
> weeks at most). The update I did this afternoon gave a conflict
> warning with the macro in include/linux/key.h.
> 
> Given that I'm not directly including key.h anywhere in the XFS
> code, I'm getting the namespace polluted indirectly from some other
> include that is necessary.
> 
> As it turns out, this commit from 13 days ago:
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7cd94146cd504016315608e297219f9fb7b1413b
> 
> included security.h in mm.h and that is how I'm seeing the namespace
> poisoning coming from key.h when !CONFIG_KEY.
> 
> Including security.h in mm.h means much wider includes for pretty
> much the entire kernel, and it opens up namespace issues like this
> that never previously existed.
> 
> The patch below (only tested for !CONFIG_KEYS && !CONFIG_SECURITY)
> moves security.h into the mmap.c and nommu.c files that need it so
> it doesn't end up with kernel wide scope.
> 
> Comments?

The idea with this placement was to keep memory management code with other 
similar code, rather than pushing it into security.h, where it does not 
functionally belong.

Something to not also is that you can't "depend" on security.h not being 
included all over the place, as LSM does touch a lot of the kernel.  
Unecessarily including it is bad, of course.

I'm not sure I understand your namespace pollution issue, either.

In any case, I think the right solution is not to include security.h at 
all in mm.h, as it is only being done to get a declaration for 
mmap_min_addr.

How about this, instead ?

Signed-off-by: James Morris <jmorris@...ei.org>
---

 mm.h |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 1b7b95c..02fbac7 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -12,7 +12,6 @@
 #include <linux/prio_tree.h>
 #include <linux/debug_locks.h>
 #include <linux/mm_types.h>
-#include <linux/security.h>
 
 struct mempolicy;
 struct anon_vma;
@@ -34,6 +33,10 @@ extern int sysctl_legacy_va_layout;
 #define sysctl_legacy_va_layout 0
 #endif
 
+#ifdef CONFIG_SECURITY
+extern unsigned long mmap_min_addr;
+#endif
+
 #include <asm/page.h>
 #include <asm/pgtable.h>
 #include <asm/processor.h>


-- 
James Morris
<jmorris@...ei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/