litmus-rt.git/security/Kconfig, branch linux-tip

Restrict unprivileged access to kernel syslog

2010-11-12T15:55:32+00:00

The kernel syslog contains debugging information that is often useful
during exploitation of other vulnerabilities, such as kernel heap
addresses.  Rather than futilely attempt to sanitize hundreds (or
thousands) of printk statements and simultaneously cripple useful
debugging functionality, it is far simpler to create an option that
prevents unprivileged users from reading the syslog.

This patch, loosely based on grsecurity's GRKERNSEC_DMESG, creates the
dmesg_restrict sysctl.  When set to "0", the default, no restrictions are
enforced.  When set to "1", only users with CAP_SYS_ADMIN can read the
kernel syslog via dmesg(8) or other mechanisms.

[akpm@linux-foundation.org: explain the config option in kernel.txt]
Signed-off-by: Dan Rosenberg 
Acked-by: Ingo Molnar 
Acked-by: Eugene Teo 
Acked-by: Kees Cook 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

AppArmor: Enable configuring and building of the AppArmor security module

2010-08-02T05:38:34+00:00

Kconfig and Makefiles to enable configuration and building of AppArmor.

Signed-off-by: John Johansen 
Signed-off-by: James Morris

remove CONFIG_SECURITY_FILE_CAPABILITIES compile option

2009-11-24T04:06:47+00:00

As far as I know, all distros currently ship kernels with default
CONFIG_SECURITY_FILE_CAPABILITIES=y.  Since having the option on
leaves a 'no_file_caps' option to boot without file capabilities,
the main reason to keep the option is that turning it off saves
you (on my s390x partition) 5k.  In particular, vmlinux sizes
came to:

without patch fscaps=n:		 	53598392
without patch fscaps=y:		 	53603406
with this patch applied:		53603342

with the security-next tree.

Against this we must weigh the fact that there is no simple way for
userspace to figure out whether file capabilities are supported,
while things like per-process securebits, capability bounding
sets, and adding bits to pI if CAP_SETPCAP is in pE are not supported
with SECURITY_FILE_CAPABILITIES=n, leaving a bit of a problem for
applications wanting to know whether they can use them and/or why
something failed.

It also adds another subtly different set of semantics which we must
maintain at the risk of severe security regressions.

So this patch removes the SECURITY_FILE_CAPABILITIES compile
option.  It drops the kernel size by about 50k over the stock
SECURITY_FILE_CAPABILITIES=y kernel, by removing the
cap_limit_ptraced_target() function.

Changelog:
	Nov 20: remove cap_limit_ptraced_target() as it's logic
		was ifndef'ed.

Signed-off-by: Serge E. Hallyn 
Acked-by: Andrew G. Morgan" 
Signed-off-by: James Morris

Config option to set a default LSM

2009-11-08T21:40:07+00:00

The LSM currently requires setting a kernel parameter at boot to select
a specific LSM.  This adds a config option that allows specifying a default
LSM that is used unless overridden with the security= kernel parameter.
If the the config option is not set the current behavior of first LSM
to register is used.

Signed-off-by: John Johansen 
Acked-by: Serge Hallyn 
Signed-off-by: James Morris

security: remove root_plug

2009-10-20T05:26:16+00:00

    Remove the root_plug example LSM code.  It's unmaintained and
    increasingly broken in various ways.

    Made at the 2009 Kernel Summit in Tokyo!

    Acked-by: Greg Kroah-Hartman 
    Signed-off-by: James Morris

Merge commit 'v2.6.31-rc8' into x86/txt

2009-09-02T06:17:56+00:00

Conflicts:
	arch/x86/kernel/reboot.c
	security/Kconfig

Merge reason: resolve the conflicts, bump up from rc3 to rc8.

Signed-off-by: Ingo Molnar

x86, intel_txt: clean up the impact on generic code, unbreak non-x86

2009-09-02T01:25:07+00:00

Move tboot.h from asm to linux to fix the build errors of intel_txt
patch on non-X86 platforms. Remove the tboot code from generic code
init/main.c and kernel/cpu.c.

Signed-off-by: Shane Wang 
Signed-off-by: H. Peter Anvin

security: Fix prompt for LSM_MMAP_MIN_ADDR

2009-08-18T22:42:56+00:00

Fix prompt for LSM_MMAP_MIN_ADDR.

(Verbs are cool!)

Signed-off-by: Andreas Schwab 
Acked-by: Eric Paris 
Signed-off-by: James Morris

security: Make LSM_MMAP_MIN_ADDR default match its help text.

2009-08-18T22:38:29+00:00

Commit 788084aba2ab7348257597496befcbccabdc98a3 added the LSM_MMAP_MIN_ADDR
option, whose help text states "For most ia64, ppc64 and x86 users with lots
of address space a value of 65536 is reasonable and should cause no problems."
Which implies that it's default setting was typoed.

Signed-off-by: Dave Jones 
Acked-by: Eric Paris 
Signed-off-by: James Morris

Security/SELinux: seperate lsm specific mmap_min_addr

2009-08-17T05:09:11+00:00

Currently SELinux enforcement of controls on the ability to map low memory
is determined by the mmap_min_addr tunable.  This patch causes SELinux to
ignore the tunable and instead use a seperate Kconfig option specific to how
much space the LSM should protect.

The tunable will now only control the need for CAP_SYS_RAWIO and SELinux
permissions will always protect the amount of low memory designated by
CONFIG_LSM_MMAP_MIN_ADDR.

This allows users who need to disable the mmap_min_addr controls (usual reason
being they run WINE as a non-root user) to do so and still have SELinux
controls preventing confined domains (like a web server) from being able to
map some area of low memory.

Signed-off-by: Eric Paris 
Signed-off-by: James Morris