linux-toradex.git/security/Kconfig, branch v2.6.28

securityfs: do not depend on CONFIG_SECURITY

2008-08-28T00:47:42+00:00

Add a new Kconfig option SECURITYFS which will build securityfs support
but does not require CONFIG_SECURITY.  The only current user of
securityfs does not depend on CONFIG_SECURITY and there is no reason the
full LSM needs to be built to build this fs.

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

security: filesystem capabilities no longer experimental

2008-07-24T17:47:22+00:00

Filesystem capabilities have come of age.  Remove the experimental tag for
configuring filesystem capabilities.

Signed-off-by: Andrew G. Morgan 
Acked-by: Serge Hallyn 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

security: remove dummy module fix

2008-07-14T05:03:41+00:00

Fix small oversight in "security: remove dummy module":
CONFIG_SECURITY_FILE_CAPABILITIES doesn't depend on CONFIG_SECURITY

Signed-off-by: Miklos Szeredi 
Signed-off-by: James Morris

security: remove dummy module

2008-07-14T05:03:04+00:00

Remove the dummy module and make the "capability" module the default.

Compile and boot tested.

Signed-off-by: Miklos Szeredi 
Acked-by: Serge Hallyn 
Signed-off-by: James Morris

security: enhance DEFAULT_MMAP_MIN_ADDR description

2008-04-18T10:26:18+00:00

Got burned by setting the proposed default of 65536
across all Debian archs.

Thus proposing to be more specific on which archs you may
set this. Also propose a value for arm and friends that
doesn't break sshd.

Reword to mention working archs ia64 and ppc64 too.

Signed-off-by: maximilian attems 
Cc: Martin Michlmayr 
Cc: Gordon Farquharson 
Acked-by: Eric Paris 
Signed-off-by: James Morris

security: allow Kconfig to set default mmap_min_addr protection

2008-02-06T13:39:46+00:00

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

Discussion:
http://www.mail-archive.com/linux-security-module@vger.kernel.org/msg02543.html

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

Smack: Simplified Mandatory Access Control Kernel

2008-02-05T17:44:20+00:00

Smack is the Simplified Mandatory Access Control Kernel.

Smack implements mandatory access control (MAC) using labels
attached to tasks and data containers, including files, SVIPC,
and other tasks. Smack is a kernel based scheme that requires
an absolute minimum of application support and a very small
amount of configuration data.

Smack uses extended attributes and
provides a set of general mount options, borrowing technics used
elsewhere. Smack uses netlabel for CIPSO labeling. Smack provides
a pseudo-filesystem smackfs that is used for manipulation of
system Smack attributes.

The patch, patches for ls and sshd, a README, a startup script,
and x86 binaries for ls and sshd are also available on

    http://www.schaufler-ca.com

Development has been done using Fedora Core 7 in a virtual machine
environment and on an old Sony laptop.

Smack provides mandatory access controls based on the label attached
to a task and the label attached to the object it is attempting to
access. Smack labels are deliberately short (1-23 characters) text
strings. Single character labels using special characters are reserved
for system use. The only operation applied to Smack labels is equality
comparison. No wildcards or expressions, regular or otherwise, are
used. Smack labels are composed of printable characters and may not
include "/".

A file always gets the Smack label of the task that created it.

Smack defines and uses these labels:

    "*" - pronounced "star"
    "_" - pronounced "floor"
    "^" - pronounced "hat"
    "?" - pronounced "huh"

The access rules enforced by Smack are, in order:

1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^"
   is permitted.
3. A read or execute access requested on an object labeled "_"
   is permitted.
4. Any access requested on an object labeled "*" is permitted.
5. Any access requested by a task on an object with the same
   label is permitted.
6. Any access requested that is explicitly defined in the loaded
   rule set is permitted.
7. Any other access is denied.

Rules may be explicitly defined by writing subject,object,access
triples to /smack/load.

Smack rule sets can be easily defined that describe Bell&LaPadula
sensitivity, Biba integrity, and a variety of interesting
configurations. Smack rule sets can be modified on the fly to
accommodate changes in the operating environment or even the time
of day.

Some practical use cases:

Hierarchical levels. The less common of the two usual uses
for MLS systems is to define hierarchical levels, often
unclassified, confidential, secret, and so on. To set up smack
to support this, these rules could be defined:

   C        Unclass rx
   S        C       rx
   S        Unclass rx
   TS       S       rx
   TS       C       rx
   TS       Unclass rx

A TS process can read S, C, and Unclass data, but cannot write it.
An S process can read C and Unclass. Note that specifying that
TS can read S and S can read C does not imply TS can read C, it
has to be explicitly stated.

Non-hierarchical categories. This is the more common of the
usual uses for an MLS system. Since the default rule is that a
subject cannot access an object with a different label no
access rules are required to implement compartmentalization.

A case that the Bell & LaPadula policy does not allow is demonstrated
with this Smack access rule:

A case that Bell&LaPadula does not allow that Smack does:

    ESPN    ABC   r
    ABC     ESPN  r

On my portable video device I have two applications, one that
shows ABC programming and the other ESPN programming. ESPN wants
to show me sport stories that show up as news, and ABC will
only provide minimal information about a sports story if ESPN
is covering it. Each side can look at the other's info, neither
can change the other. Neither can see what FOX is up to, which
is just as well all things considered.

Another case that I especially like:

    SatData Guard   w
    Guard   Publish w

A program running with the Guard label opens a UDP socket and
accepts messages sent by a program running with a SatData label.
The Guard program inspects the message to ensure it is wholesome
and if it is sends it to a program running with the Publish label.
This program then puts the information passed in an appropriate
place. Note that the Guard program cannot write to a Publish
file system object because file system semanitic require read as
well as write.

The four cases (categories, levels, mutual read, guardbox) here
are all quite real, and problems I've been asked to solve over
the years. The first two are easy to do with traditonal MLS systems
while the last two you can't without invoking privilege, at least
for a while.

Signed-off-by: Casey Schaufler 
Cc: Joshua Brindle 
Cc: Paul Moore 
Cc: Stephen Smalley 
Cc: Chris Wright 
Cc: James Morris 
Cc: "Ahmed S. Darwish" 
Cc: Andrew G. Morgan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

security: compile capabilities by default

2008-01-29T21:18:21+00:00

Capabilities have long been the default when CONFIG_SECURITY=n,
and its help text suggests turning it on when CONFIG_SECURITY=y.
But it is set to default n.

Default it to y instead.

Signed-off-by: Serge Hallyn 
Acked-by: Matt LaPlante 
Signed-off-by: James Morris

Implement file posix capabilities

2007-10-17T15:43:07+00:00

Implement file posix capabilities.  This allows programs to be given a
subset of root's powers regardless of who runs them, without having to use
setuid and giving the binary all of root's powers.

This version works with Kaigai Kohei's userspace tools, found at
http://www.kaigai.gr.jp/index.php.  For more information on how to use this
patch, Chris Friedhoff has posted a nice page at
http://www.friedhoff.org/fscaps.html.

Changelog:
	Nov 27:
	Incorporate fixes from Andrew Morton
	(security-introduce-file-caps-tweaks and
	security-introduce-file-caps-warning-fix)
	Fix Kconfig dependency.
	Fix change signaling behavior when file caps are not compiled in.

	Nov 13:
	Integrate comments from Alexey: Remove CONFIG_ ifdef from
	capability.h, and use %zd for printing a size_t.

	Nov 13:
	Fix endianness warnings by sparse as suggested by Alexey
	Dobriyan.

	Nov 09:
	Address warnings of unused variables at cap_bprm_set_security
	when file capabilities are disabled, and simultaneously clean
	up the code a little, by pulling the new code into a helper
	function.

	Nov 08:
	For pointers to required userspace tools and how to use
	them, see http://www.friedhoff.org/fscaps.html.

	Nov 07:
	Fix the calculation of the highest bit checked in
	check_cap_sanity().

	Nov 07:
	Allow file caps to be enabled without CONFIG_SECURITY, since
	capabilities are the default.
	Hook cap_task_setscheduler when !CONFIG_SECURITY.
	Move capable(TASK_KILL) to end of cap_task_kill to reduce
	audit messages.

	Nov 05:
	Add secondary calls in selinux/hooks.c to task_setioprio and
	task_setscheduler so that selinux and capabilities with file
	cap support can be stacked.

	Sep 05:
	As Seth Arnold points out, uid checks are out of place
	for capability code.

	Sep 01:
	Define task_setscheduler, task_setioprio, cap_task_kill, and
	task_setnice to make sure a user cannot affect a process in which
	they called a program with some fscaps.

	One remaining question is the note under task_setscheduler: are we
	ok with CAP_SYS_NICE being sufficient to confine a process to a
	cpuset?

	It is a semantic change, as without fsccaps, attach_task doesn't
	allow CAP_SYS_NICE to override the uid equivalence check.  But since
	it uses security_task_setscheduler, which elsewhere is used where
	CAP_SYS_NICE can be used to override the uid equivalence check,
	fixing it might be tough.

	     task_setscheduler
		 note: this also controls cpuset:attach_task.  Are we ok with
		     CAP_SYS_NICE being used to confine to a cpuset?
	     task_setioprio
	     task_setnice
		 sys_setpriority uses this (through set_one_prio) for another
		 process.  Need same checks as setrlimit

	Aug 21:
	Updated secureexec implementation to reflect the fact that
	euid and uid might be the same and nonzero, but the process
	might still have elevated caps.

	Aug 15:
	Handle endianness of xattrs.
	Enforce capability version match between kernel and disk.
	Enforce that no bits beyond the known max capability are
	set, else return -EPERM.
	With this extra processing, it may be worth reconsidering
	doing all the work at bprm_set_security rather than
	d_instantiate.

	Aug 10:
	Always call getxattr at bprm_set_security, rather than
	caching it at d_instantiate.

[morgan@kernel.org: file-caps clean up for linux/capability.h]
[bunk@kernel.org: unexport cap_inode_killpriv]
Signed-off-by: Serge E. Hallyn 
Cc: Stephen Smalley 
Cc: James Morris 
Cc: Chris Wright 
Cc: Andrew Morgan 
Signed-off-by: Andrew Morgan 
Signed-off-by: Adrian Bunk 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

security: Convert LSM into a static interface

2007-10-17T15:43:07+00:00

Convert LSM into a static interface, as the ability to unload a security
module is not required by in-tree users and potentially complicates the
overall security architecture.

Needlessly exported LSM symbols have been unexported, to help reduce API
abuse.

Parameters for the capability and root_plug modules are now specified
at boot.

The SECURITY_FRAMEWORK_VERSION macro has also been removed.

In a nutshell, there is no safe way to unload an LSM.  The modular interface
is thus unecessary and broken infrastructure.  It is used only by out-of-tree
modules, which are often binary-only, illegal, abusive of the API and
dangerous, e.g.  silently re-vectoring SELinux.

[akpm@linux-foundation.org: cleanups]
[akpm@linux-foundation.org: USB Kconfig fix]
[randy.dunlap@oracle.com: fix LSM kernel-doc]
Signed-off-by: James Morris 
Acked-by: Chris Wright 
Cc: Stephen Smalley 
Cc: "Serge E. Hallyn" 
Acked-by: Arjan van de Ven 
Signed-off-by: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds