Re: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
On Tue, 2007-12-18 at 19:28 -0800, Crispin Cowan wrote: Stephen Smalley wrote: It is if I have to maintain a special pieces of code for each possible LSM. One piece for SELinux, one piece for AppArmour, one piece for Smack, one piece for Casey's security system. That sounds like a pain. All your code has to do is invoke a function provided by libselinux. If at some later time a liblsm is introduced that provides a common front-end to a libselinux, libsmack, ..., then you can use that. But it doesn't exist today. But it all just becomes a simple function call regardless. libapparmor exists. It only had one API, and now it has 2, but just 2 versions on the same concept (change_hat and change_profile). This is the API for change_hat http://man-wiki.net/index.php/2:change_hat What does the corresponding API in SELinux look like? The SELinux API for changing context is described in: http://linux.die.net/man/3/setcon However, setting the current context (SELinux) or profile (AppArmor) for a userspace task doesn't really provide the functionality required here for cachefiles, nor does it solve the (different, yet related) nfsd problem. cachefiles is a kernel module that needs to assume a different set of credentials for its internal accesses to the cache files it manages when a userspace process tries to access a file that has been cached, as the userspace process in whose context it is operating may (and should) lack direct permission to those cache files. The userspace API being talked about is simply how one configures the credentials to be used by cachefiles kernel module for its internal accesses, and is done up front when cachefiles is configured to create a cache. The internal switching of the active set of credentials is done via a kernel-internal API (or just by switching the pointer to the credential structure previously set up) when the cachefiles kernel module wants to access a cache file. Further, when this internal switching occurs, we have to be careful that there are no user-visible side effects on the current task - no change in how others may operate on that task e.g. signal permission checks or on how the task appears to others e.g. via /proc. Neither change_hat nor setcon helps with that problem. For AppArmor, I suspect that you just want the cachefiles kernel module to act as unconfined for its internal accesses, nothing more. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Allow Kconfig to set default mmap_min_addr protection
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 [EMAIL PROTECTED]
---
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 = CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR;
static inline int verify(struct security_operations *ops)
{
-
To unsubscribe from this list: send the line unsubscribe
linux-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Allow Kconfig to set default mmap_min_addr protection
On Dec 19 2007 16:59, Eric Paris wrote: +config SECURITY_DEFAULT_MMAP_MIN_ADDR +int Low address space to protect from user allocation Hm, should not this be 'hex'? +depends on SECURITY +default 0 +help - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning
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 intsome_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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
