Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
---
include/linux/security.h |2 +-
security/keys/proc.c |4 ++--
security/selinux/selinuxfs.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index
On Jan 2 2008 12:09, Eric Paris wrote:
So in the end we are all happy with the original patch I sent?
No objections at least :)
-
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
On Dec 26 2007 16:29, Andrew Morgan wrote:
I'm assuming it's unintended - or rather it's harmless but has no use -
but will let Andrew respond since he may have some cool idea i haven't
thought of.
This is not intended behavior. It should be fixed (aka such support
removed). Capabilities
On Dec 21 2007 15:31, Eric Paris wrote:
On Thu, 2007-12-20 at 00:29 +0100, Jan Engelhardt wrote:
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'?
I guess it could
On Dec 21 2007 22:16, Willy Tarreau wrote:
Hi Jan,
+config SECURITY_DEFAULT_MMAP_MIN_ADDR
+int Low address space to protect from user allocation
Hm, should not this be 'hex'?
I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is
base 10 as well
sysfs is
On Dec 21 2007 14:35, Greg KH wrote:
I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is
base 10 as well
sysfs is autobase, i.e. echo 0xb000 /sys/foo will Do The Right Thing.
yes but if you cat /proc/sys/vm/mmap_min_addr, it returns in base 10.
sysfs should
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
On Nov 1 2007 12:51, Peter Dolding wrote:
This is above me doing code. No matter how many fixes I do to the
core that will not fix dysfunction in the LSM section. Strict
policies on fixing the main security model will be required.
If there is no one wanting to fix the existing code, then the
On Nov 1 2007 17:54, Ahmed S. Darwish wrote:
+
+static inline int isblank(char c)
+{
+ return (c == ' ' || c == '\t');
+}
Use isspace().
+ for (i = 0; i count data[i]; i ++)
...
+ subjectstr[(*label_len) ++] = data[i];
i++ w/o space
-
To unsubscribe from this
On Oct 25 2007 19:56, Greg KH wrote:
What kind of code is not accepted into the mainline kernel tree for good
reasons? What are these reasons? What specific code are you talking
about?
I'm trying to compile a list of all known external modules and drivers
and work to get them included in the
On Oct 29 2007 20:46, Lee Revell wrote:
On 10/29/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
quad_dsp - http://jengelh.hopto.org/p/quad_dsp/
Provides a /dev/dsp style node for legacy applications that support
neither ALSA nor the AOSS wrapper nor more-than-2-channel sound.
(I think
On Oct 28 2007 20:42, Tilman Schmidt wrote:
Am 27.10.2007 20:22 schrieb Pavel Machek:
Hi!
but require unreasonable interface changes. As people who care
about security (y'all who are only from the LKML are excused) it
is our obligation to look beyond the preconceived notions of what
is and
On Oct 25 2007 19:56, Greg KH wrote:
I'm trying to compile a list of all known external modules and drivers
and work to get them included in the main kernel tree to help prevent
these kinds of things. If you know of any that are not on the list at:
As I read through LWN today, I noted the following comment,
http://lwn.net/Articles/255832/ :
Personally, I think it's absolutely essential to be able to
build a kernel with dynamic LSM. Whether we like it or not,
people do want to add in runtime loadable security
On Oct 24 2007 19:11, Simon Arlott wrote:
* (I've got a list of access rules which are scanned in order until one of
them matches, and an array of one bit for every port for per-port default
allow/deny - although the latter could be removed.
http://svn.lp0.eu/simon/portac/trunk/)
Besides the
On Oct 24 2007 18:02, David P. Quigley wrote:
But an LSM needs to _explicitly_ call the next LSM's function. No
one (just a minimal grep in linux-2.6/security/) besides SELinux
does that today. So while you could load AppArmor ontop of
MultiAdm, it would never be invoked. This is what is
On Sep 30 2007 01:16, Andrew Morton wrote:
Documentation/Smack.txt | 104 +
security/Kconfig |1
security/Makefile |2
security/smack/Kconfig| 10
security/smack/Makefile |9
security/smack/smack.h| 207 ++
On Aug 22 2007 11:47, Casey Schaufler wrote:
As we have to maintain selinux, anyway, I don't see why simplification
layer is a problem.
It's an issue if you want to do simple things, have the resources to
do simple things, but go over budget because the simple things are
built on top of
On Aug 11 2007 16:22, Casey Schaufler wrote:
@@ -0,0 +1,8 @@
+#
+# Makefile for the SMACK LSM
+#
+
+obj-$(CONFIG_SECURITY_SMACK) := smack.o
+
+smack-y := smack_lsm.o smack_access.o smackfs.o
smack-objs :=
Added.
I should have added replace it.
+/*
+ * ' \n\0'
On Aug 11 2007 10:57, Casey Schaufler wrote:
* - pronounced star
wall
_ - pronounced floor
floor
^ - pronounced hat
roof
? - pronounced huh
it's dark in here :)
+config SECURITY_SMACK
+ bool Simplified Mandatory Access Control Kernel Support
+ depends on NETLABEL
20 matches
Mail list logo
