linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
@ 2007-12-19  9:38 David Chinner
  2007-12-19 10:15 ` Alexey Dobriyan
  2007-12-20  0:07 ` James Morris
  0 siblings, 2 replies; 9+ messages in thread
From: David Chinner @ 2007-12-19  9:38 UTC (permalink / raw)
  To: lkml

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?

---
 include/linux/mm.h       |   16 ----------------
 include/linux/security.h |   26 +++++++++++++++++++++++++-
 mm/mmap.c                |    1 +
 mm/nommu.c               |    1 +
 4 files changed, 27 insertions(+), 17 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 1b7b95c..520238c 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;
@@ -514,21 +513,6 @@ static inline void set_page_links(struct page *page, enum zone_type zone,
 }
 
 /*
- * If a hint addr is less than mmap_min_addr change hint to be as
- * low as possible but still greater than mmap_min_addr
- */
-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;
-}
-
-/*
  * Some inline functions in vmstat.h depend on page_zone()
  */
 #include <linux/vmstat.h>
diff --git a/include/linux/security.h b/include/linux/security.h
index ac05083..e9ba391 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -2568,6 +2568,19 @@ void security_key_free(struct key *key);
 int security_key_permission(key_ref_t key_ref,
 			    struct task_struct *context, key_perm_t perm);
 
+/*
+ * If a hint addr is less than mmap_min_addr change hint to be as
+ * low as possible but still greater than mmap_min_addr
+ */
+static inline unsigned long round_hint_to_min(unsigned long hint)
+{
+	hint &= PAGE_MASK;
+	if (((void *)hint != NULL) &&
+	    (hint < mmap_min_addr))
+		return PAGE_ALIGN(mmap_min_addr);
+	return hint;
+}
+
 #else
 
 static inline int security_key_alloc(struct key *key,
@@ -2588,7 +2601,18 @@ static inline int security_key_permission(key_ref_t key_ref,
 	return 0;
 }
 
-#endif
+static inline unsigned long round_hint_to_min(unsigned long hint)
+{
+	return hint;
+}
+
+#endif /* CONFIG_SECURITY */
+
+#else /* !CONFIG_KEYS */
+static inline unsigned long round_hint_to_min(unsigned long hint)
+{
+	return hint;
+}
 #endif /* CONFIG_KEYS */
 
 #endif /* ! __LINUX_SECURITY_H */
diff --git a/mm/mmap.c b/mm/mmap.c
index 15678aa..0d666de 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -26,6 +26,7 @@
 #include <linux/mount.h>
 #include <linux/mempolicy.h>
 #include <linux/rmap.h>
+#include <linux/security.h>
 
 #include <asm/uaccess.h>
 #include <asm/cacheflush.h>
diff --git a/mm/nommu.c b/mm/nommu.c
index b989cb9..99702d1 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -28,6 +28,7 @@
 #include <linux/personality.h>
 #include <linux/security.h>
 #include <linux/syscalls.h>
+#include <linux/security.h>
 
 #include <asm/uaccess.h>
 #include <asm/tlb.h>

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
  2007-12-19  9:38 [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning David Chinner
@ 2007-12-19 10:15 ` Alexey Dobriyan
  2007-12-20  0:07 ` James Morris
  1 sibling, 0 replies; 9+ messages in thread
From: Alexey Dobriyan @ 2007-12-19 10:15 UTC (permalink / raw)
  To: David Chinner; +Cc: lkml

On 12/19/07, David Chinner <dgc@sgi.com> wrote:

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.

ACK, removing sched.h from mm.h was quite painful and security.h
added it back unconditionally. As result, standalone mm.h inclusion goes
from ~9K to ~16K of code after preprocessing which is quite unpleasant.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
  2007-12-19  9:38 [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning David Chinner
  2007-12-19 10:15 ` Alexey Dobriyan
@ 2007-12-20  0:07 ` James Morris
  2007-12-20  1:44   ` David Chinner
  2007-12-20 18:08   ` Eric Paris
  1 sibling, 2 replies; 9+ messages in thread
From: James Morris @ 2007-12-20  0:07 UTC (permalink / raw)
  To: David Chinner; +Cc: lkml, linux-security-module, Eric Paris

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@namei.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@namei.org>

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
  2007-12-20  0:07 ` James Morris
@ 2007-12-20  1:44   ` David Chinner
  2007-12-20  4:11     ` James Morris
  2008-01-02 15:41     ` David Howells
  2007-12-20 18:08   ` Eric Paris
  1 sibling, 2 replies; 9+ messages in thread
From: David Chinner @ 2007-12-20  1:44 UTC (permalink / raw)
  To: James Morris; +Cc: David Chinner, lkml, linux-security-module, Eric Paris

On Thu, Dec 20, 2007 at 11:07:01AM +1100, James Morris wrote:
> 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.

Which is what including it in mm.h does. It also pull sin a lot of
other headers files as has already been noted.

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

doing this globally:

#ifdef CONFIG_SOMETHING
extern int	some_common_name(int a, int b, int c);
#else
#define some_common_name(a,b,c)	0
#endif

means that no-one can use some_common_name *anywhere* in the kernel.
In this case, i have a completely *private* use of some_common_name
and now I can't use that because the wonderful define above that
now has effectively global scope because it gets included from key.h
via security.h via mm.h.

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

Fine by me.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
  2007-12-20  1:44   ` David Chinner
@ 2007-12-20  4:11     ` James Morris
  2007-12-25 22:05       ` Andrew Morton
  2008-01-02 15:41     ` David Howells
  1 sibling, 1 reply; 9+ messages in thread
From: James Morris @ 2007-12-20  4:11 UTC (permalink / raw)
  To: David Chinner; +Cc: lkml, linux-security-module, Eric Paris, dhowells

On Thu, 20 Dec 2007, David Chinner wrote:

> > I'm not sure I understand your namespace pollution issue, either.
> 
> doing this globally:
> 
> #ifdef CONFIG_SOMETHING
> extern int	some_common_name(int a, int b, int c);
> #else
> #define some_common_name(a,b,c)	0
> #endif

I suspect it may be useful ensure all global identifiers for the key 
subsystem are prefixed with key_, as 'copy_keys' does seem a little 
generic.

> > +#ifdef CONFIG_SECURITY
> > +extern unsigned long mmap_min_addr;
> > +#endif
> > +
> >  #include <asm/page.h>
> >  #include <asm/pgtable.h>
> >  #include <asm/processor.h>
> 
> Fine by me.

I'll queue it for -mm & 2.6.25.


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
  2007-12-20  0:07 ` James Morris
  2007-12-20  1:44   ` David Chinner
@ 2007-12-20 18:08   ` Eric Paris
  1 sibling, 0 replies; 9+ messages in thread
From: Eric Paris @ 2007-12-20 18:08 UTC (permalink / raw)
  To: James Morris; +Cc: David Chinner, lkml, linux-security-module


On Thu, 2007-12-20 at 11:07 +1100, James Morris wrote:
> 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@namei.org>
Acked-by: Eric Paris <eparis@redhat.com>
> ---
> 
>  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>
> 
> 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
  2007-12-20  4:11     ` James Morris
@ 2007-12-25 22:05       ` Andrew Morton
  2007-12-26  4:15         ` James Morris
  0 siblings, 1 reply; 9+ messages in thread
From: Andrew Morton @ 2007-12-25 22:05 UTC (permalink / raw)
  To: James Morris
  Cc: David Chinner, lkml, linux-security-module, Eric Paris, dhowells

On Thu, 20 Dec 2007 15:11:40 +1100 (EST) James Morris <jmorris@namei.org> wrote:

> > > +#ifdef CONFIG_SECURITY
> > > +extern unsigned long mmap_min_addr;
> > > +#endif
> > > +
> > >  #include <asm/page.h>
> > >  #include <asm/pgtable.h>
> > >  #include <asm/processor.h>
> > 
> > Fine by me.
> 
> I'll queue it for -mm & 2.6.25.

I don't think we need the ifdef.  If someone incorrectly refers to this
then they'll get a link-time error rather than a compile-time error (bad). 
But we lose an ifdef (good).


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
  2007-12-25 22:05       ` Andrew Morton
@ 2007-12-26  4:15         ` James Morris
  0 siblings, 0 replies; 9+ messages in thread
From: James Morris @ 2007-12-26  4:15 UTC (permalink / raw)
  To: Andrew Morton
  Cc: David Chinner, lkml, linux-security-module, Eric Paris, dhowells

On Tue, 25 Dec 2007, Andrew Morton wrote:

> On Thu, 20 Dec 2007 15:11:40 +1100 (EST) James Morris <jmorris@namei.org> wrote:
> 
> > > > +#ifdef CONFIG_SECURITY
> > > > +extern unsigned long mmap_min_addr;
> > > > +#endif
> > > > +
> > > >  #include <asm/page.h>
> > > >  #include <asm/pgtable.h>
> > > >  #include <asm/processor.h>
> > > 
> > > Fine by me.
> > 
> > I'll queue it for -mm & 2.6.25.
> 
> I don't think we need the ifdef.  If someone incorrectly refers to this
> then they'll get a link-time error rather than a compile-time error (bad). 
> But we lose an ifdef (good).

Done, & rebased the git branch.


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
  2007-12-20  1:44   ` David Chinner
  2007-12-20  4:11     ` James Morris
@ 2008-01-02 15:41     ` David Howells
  1 sibling, 0 replies; 9+ messages in thread
From: David Howells @ 2008-01-02 15:41 UTC (permalink / raw)
  To: James Morris
  Cc: dhowells, David Chinner, lkml, linux-security-module, Eric Paris

James Morris <jmorris@namei.org> wrote:

> I suspect it may be useful ensure all global identifiers for the key 
> subsystem are prefixed with key_, as 'copy_keys' does seem a little 
> generic.

Many of the fork helpers are called copy_xxx().

David

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2008-01-02 15:41 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-19  9:38 [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning David Chinner
2007-12-19 10:15 ` Alexey Dobriyan
2007-12-20  0:07 ` James Morris
2007-12-20  1:44   ` David Chinner
2007-12-20  4:11     ` James Morris
2007-12-25 22:05       ` Andrew Morton
2007-12-26  4:15         ` James Morris
2008-01-02 15:41     ` David Howells
2007-12-20 18:08   ` Eric Paris

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).