The attached patch adds LSM hooks for key management facilities. The notable
changes are:
(1) The key struct now supports a security pointer for the use of security
modules. This will permit key labelling and restrictions on which
programs may access a key.
(2) Security modules get a chance to note (or abort) the allocation of a key.
(3) The key permission checking can now be enhanced by the security modules;
the permissions check consults LSM if all other checks bear out.
(4) The key permissions checking functions now return an error code rather
than a boolean value.
(5) An extra permission has been added to govern the modification of
attributes (UID, GID, permissions).
Note that there isn't an LSM hook specifically for each keyctl() operation,
but rather the permissions hook allows control of individual operations based
on the permission request bits.
Key management access control through LSM is enabled by automatically if both
CONFIG_KEYS and CONFIG_SECURITY are enabled.
This should be applied on top of the patch ensubjected:
[PATCH] Keys: Possessor permissions should be additive
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch allows SELinux to canonicalize the value returned from
getxattr() via the security_inode_getsecurity() hook, which is called after
the fs level getxattr() function.
The purpose of this is to allow the in-core security context for an inode
to override the on-disk value. This could happen in cases such as
upgrading a system to a different labeling form (e.g. standard SELinux to
MLS) without needing to do a full relabel of the filesystem.
In such cases, we want getxattr() to return the canonical security context
that the kernel is using rather than what is stored on disk.
The implementation hooks into the inode_getsecurity(), adding another
parameter to indicate the result of the preceding fs-level getxattr() call,
so that SELinux knows whether to compare a value obtained from disk with
the kernel value.
We also now allow getxattr() to work for mountpoint labeled filesystems
(i.e. mount with option context=foo_t), as we are able to return the
kernel value to the user.
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
- added typedef unsigned int __nocast gfp_t;
- replaced __nocast uses for gfp flags with gfp_t - it gives exactly
the same warnings as far as sparse is concerned, doesn't change
generated code (from gcc point of view we replaced unsigned int with
typedef) and documents what's going on far better.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch removes the inode_post_link and inode_post_rename LSM hooks as
they are unused (and likely useless).
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch removes the inode_post_create/mkdir/mknod/symlink LSM hooks as
they are obsoleted by the new inode_init_security hook that enables atomic
inode security labeling.
If anyone sees any reason to retain these hooks, please speak now. Also,
is anyone using the post_rename/link hooks; if not, those could also be
removed.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The following patch set enables atomic security labeling of newly created
inodes by altering the fs code to invoke a new LSM hook to obtain the security
attribute to apply to a newly created inode and to set up the incore inode
security state during the inode creation transaction. This parallels the
existing processing for setting ACLs on newly created inodes. Otherwise, it
is possible for new inodes to be accessed by another thread via the dcache
prior to complete security setup (presently handled by the
post_create/mkdir/... LSM hooks in the VFS) and a newly created inode may be
left unlabeled on the disk in the event of a crash. SELinux presently works
around the issue by ensuring that the incore inode security label is
initialized to a special SID that is inaccessible to unprivileged processes
(in accordance with policy), thereby preventing inappropriate access but
potentially causing false denials on legitimate accesses. A simple test
program demonstrates such false denials on SELinux, and the patch solves the
problem. Similar such false denials have been encountered in real
applications.
This patch defines a new inode_init_security LSM hook to obtain the security
attribute to apply to a newly created inode and to set up the incore inode
security state for it, and adds a corresponding hook function implementation
to SELinux.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Of this type, mostly:
CHECK net/ipv6/netfilter.c
net/ipv6/netfilter.c:96:12: warning: symbol 'ipv6_netfilter_init' was not declared. Should it be static?
net/ipv6/netfilter.c:101:6: warning: symbol 'ipv6_netfilter_fini' was not declared. Should it be static?
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Here's a small patch against 2.6.13-rc2 that adds securityfs, a virtual
fs that all LSMs can use instead of creating their own. The fs should
be mounted at /sys/kernel/security, and the fs creates that mount point.
This will make the LSB people happy that we aren't creating a new
/my_lsm_fs directory in the root for every different LSM.
It has changed a bit since the last version, thanks to comments from
Mike Waychison.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
