Since it was decided that low memory protection from userspace couldn't
be turned on by default add a Kconfig option to allow users/distros to
set a default at compile time.  This value is still tunable after boot
in /proc/sys/vm/mmap_min_addr

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

---

 security/Kconfig    |   18 ++++++++++++++++++
 security/security.c |    4 +++-
 2 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index 8086e61..10c9e40 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -103,6 +103,24 @@ 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 users with lots of address space a value of 65536 is
+	  reasonable and should cause no problems.  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
 
 endmenu
diff --git a/security/security.c b/security/security.c
index 0e1f1f1..c784726 100644
--- a/security/security.c
+++ b/security/security.c
@@ -23,7 +23,9 @@ extern struct security_operations dummy_security_ops;
 extern void security_fixup_ops(struct security_operations *ops);
 
 struct security_operations *security_ops;	/* Initialized to NULL */
-unsigned long mmap_min_addr;		/* 0 means no protection */
+
+/* amount of vm to protect from userspace access */
+unsigned long mmap_min_addr = ...
[ message continues ]

--

[ message continues ]

I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is
base 10 as well so I figured consistency was a good thing.  Do you have
strong feelings?  I guess so since you posted about it.

-Eric

--

[ message continues ]

--

[ message continues ]

Hi Jan,


yes but if you cat  /proc/sys/vm/mmap_min_addr, it returns in base 10.
While most of us have no problem doing an instant conversion, many
people will find it painful to convert the output of cat before copying
it into their .config.

I'm generally for hex, but here I'd prefer to stay with the in-place
format which is already decimal. And as you said, people can still
write the hex value into /proc/sys if they want to.

Regards,
Willy

--

[ message continues ]

Again, this is sysctl, not sysfs.  two very different things...
--

[ message continues ]

Argh... :)  Just shows that /proc is the wrong place for system variables.

Well, module_params(integer) are autobase, and that's all I needed so 
far :-D
--

[ message continues ]

So in the end we are all happy with the original patch I sent?

-Eric

--

[ message continues ]

No objections at least :)
--

[ message continues ]

I agree too. BTW, I've intentionally not merged it into 2.4, I
prefer that admins deliberately set the sysctl on their servers
than using a kernel in which they forgot it was enabled. But I
agree that for wider use, the kernel option will help a lot.

Regards,
Willy

--

[ message continues ]

Hm, no, that is not sysfs doing this, and sysfs is not autobase in all
places.  That is sysctl (/proc/sys/), not sysfs.

thanks,

greg k-h
--

[ message continues ]