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_addrSigned-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_ROOTPLUGIf 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/Kconfigendmenu
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 = CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADD...
--
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
--
--
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
--
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--
sysfs should probably be tuned to output it in a preferred base.
--
Again, this is sysctl, not sysfs. two very different things...
--
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
--
So in the end we are all happy with the original patch I sent?
-Eric
--
No objections at least :)
--
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--
| Heiko Carstens | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Eric W. Biederman | [PATCH 0/10] sysfs network namespace support |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
