This patch fixes error handling in sel_make_bools(), where currently we'd
get a memory leak via security_get_bools() and try to kfree() the wrong
pointer if called again.
Signed-off-by: James Morris <jmorris@namei.org>
Acked-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 fixes a possible NULL dereference in policydb_destroy, where
p->type_attr_map can be NULL if policydb_destroy is called to clean up a
partially loaded policy upon an error during policy load. Please apply.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: James Morris <jmorris@namei.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch makes the possessor permissions on a key additive with
user/group/other permissions on the same key.
This permits extra rights to be granted to the possessor of a key without
taking away any rights conferred by them owning the key or having common group
membership.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The attached patch splits key permissions checking out of key-ui.h and
moves it into a .c file. It's quite large and called quite a lot, and
it's about to get bigger with the addition of LSM support for keys...
key_any_permission() is also discarded as it's no longer used.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The attached patch adds documentation for the process by which request-key
works, including how it permits helper processes to gain access to the
requestor's keyrings.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Plug request_key_auth memleak. This can be triggered by unprivileged
users, so is local DoS.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The following patch updates the way SELinux classifies and handles IP
based protocols.
Currently, IP sockets are classified by SELinux as being either TCP, UDP
or 'Raw', the latter being a default for IP socket that is not TCP or UDP.
The classification code is out of date and uses only the socket type
parameter to socket(2) to determine the class of IP socket. So, any
socket created with SOCK_STREAM will be classified by SELinux as TCP, and
SOCK_DGRAM as UDP. Also, other socket types such as SOCK_SEQPACKET and
SOCK_DCCP are currently ignored by SELinux, which classifies them as
generic sockets, which means they don't even get basic IP level checking.
This patch changes the SELinux IP socket classification logic, so that
only an IPPROTO_IP protocol value passed to socket(2) classify the socket
as TCP or UDP. The patch also drops the check for SOCK_RAW and converts
it into a default, so that socket types like SOCK_DCCP and SOCK_SEQPACKET
are classified as SECCLASS_RAWIP_SOCKET (instead of generic sockets).
Note that protocol-specific support for SCTP, DCCP etc. is not addressed
here, we're just getting these protocols checked at the IP layer.
This fixes a reported problem where SCTP sockets were being recognized as
generic SELinux sockets yet still being passed in one case to an IP level
check, which then fails for generic sockets.
It will also fix bugs where any SOCK_STREAM socket is classified as TCP or
any SOCK_DGRAM socket is classified as UDP.
This patch also unifies the way IP sockets classes are determined in
selinux_socket_bind(), so we use the already calculated value instead of
trying to recalculate it.
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The attached patch adds extra permission grants to keys for the possessor of a
key in addition to the owner, group and other permissions bits. This makes
SUID binaries easier to support without going as far as labelling keys and key
targets using the LSM facilities.
This patch adds a second "pointer type" to key structures (struct key_ref *)
that can have the bottom bit of the address set to indicate the possession of
a key. This is propagated through searches from the keyring to the discovered
key. It has been made a separate type so that the compiler can spot attempts
to dereference a potentially incorrect pointer.
The "possession" attribute can't be attached to a key structure directly as
it's not an intrinsic property of a key.
Pointers to keys have been replaced with struct key_ref *'s wherever
possession information needs to be passed through.
This does assume that the bottom bit of the pointer will always be zero on
return from kmem_cache_alloc().
The key reference type has been made into a typedef so that at least it can be
located in the sources, even though it's basically a pointer to an undefined
type. I've also renamed the accessor functions to be more useful, and all
reference variables should now end in "_ref".
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
That should be -EINVAL for both.
Signed-off-by: Serge Hallyn <serue@us.ibm.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We don't put braces around single statements, thanks.
Cc: Serge Hallyn <serue@us.ibm.com>
Cc: James Morris <jmorris@namei.org>
Cc: Chris Wright <chrisw@osdl.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
With the use of RCU in files structure, the look-up of files using fds can now
be lock-free. The lookup is protected by rcu_read_lock()/rcu_read_unlock().
This patch changes the readers to use lock-free lookup.
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
Signed-off-by: Ravikiran Thirumalai <kiran_th@gmail.com>
Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
In order for the RCU to work, the file table array, sets and their sizes must
be updated atomically. Instead of ensuring this through too many memory
barriers, we put the arrays and their sizes in a separate structure. This
patch takes the first step of putting the file table elements in a separate
structure fdtable that is embedded withing files_struct. It also changes all
the users to refer to the file table using files_fdtable() macro. Subsequent
applciation of RCU becomes easier after this.
Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com>
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
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>
This patch modifies tmpfs to call the inode_init_security LSM hook to set
up the incore inode security state for new inodes before the inode becomes
accessible via the dcache.
As there is no underlying storage of security xattrs in this case, it is
not necessary for the hook to return the (name, value, len) triple to the
tmpfs code, so this patch also modifies the SELinux hook function to
correctly handle the case where the (name, value, len) pointers are NULL.
The hook call is needed in tmpfs in order to support proper security
labeling of tmpfs inodes (e.g. for udev with tmpfs /dev in Fedora). With
this change in place, we should then be able to remove the
security_inode_post_create/mkdir/... hooks safely.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Hugh Dickins <hugh@veritas.com>
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>
This patch adds endian notations to the SELinux code.
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 improves memory use by SELinux by both reducing the avtab node
size and reducing the number of avtab nodes. The memory savings are
substantial, e.g. on a 64-bit system after boot, James Morris reported the
following data for the targeted and strict policies:
#objs objsize kernmem
Targeted:
Before: 237888 40 9.1MB
After: 19968 24 468KB
Strict:
Before: 571680 40 21.81MB
After: 221052 24 5.06MB
The improvement in memory use comes at a cost in the speed of security
server computations of access vectors, but these computations are only
required on AVC cache misses, and performance measurements by James Morris
using a number of benchmarks have shown that the change does not cause any
significant degradation.
Note that a rebuilt policy via an updated policy toolchain
(libsepol/checkpolicy) is required in order to gain the full benefits of
this patch, although some memory savings benefits are immediately applied
even to older policies (in particular, the reduction in avtab node size).
Sources for the updated toolchain are presently available from the
sourceforge CVS tree (http://sourceforge.net/cvs/?group_id=21266), and
tarballs are available from http://www.flux.utah.edu/~sds.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch goes through the current users of the crypto layer and sets
CRYPTO_TFM_REQ_MAY_SLEEP at crypto_alloc_tfm() where all crypto operations
are performed in process context.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
netlink_broadcast users must initialize NETLINK_CB(skb).dst_groups to the
destination group mask for netlink_recvmsg.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
- Remove bogus code for compiling netlink as module
- Add module refcounting support for modules implementing a netlink
protocol
- Add support for autoloading modules that implement a netlink protocol
as soon as someone opens a socket for that protocol
Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
CONFIG_SECURITY=y and CONFIG_SYSFS=n results in the following compile
error:
<-- snip -->
...
LD vmlinux
security/built-in.o: In function `securityfs_init':
inode.c:(.init.text+0x1c2): undefined reference to `kernel_subsys'
make: *** [vmlinux] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Chris Wright <chrisw@osdl.org>
The attached patch makes sure that a keyring that failed to instantiate
properly is destroyed without oopsing [CAN-2005-2099].
The problem occurs in three stages:
(1) The key allocator initialises the type-specific data to all zeroes. In
the case of a keyring, this will become a link in the keyring name list
when the keyring is instantiated.
(2) If a user (any user) attempts to add a keyring with anything other than
an empty payload, the keyring instantiation function will fail with an
error and won't add the keyring to the name list.
(3) The keyring's destructor then sees that the keyring has a description
(name) and tries to remove the keyring from the name list, which oopses
because the link pointers are both zero.
This bug permits any user to take down a box trivially.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The attached patch prevents an error during the key session joining operation
from hanging future joins in the D state [CAN-2005-2098].
The problem is that the error handling path for the KEYCTL_JOIN_SESSION_KEYRING
operation has one error path that doesn't release the session management
semaphore. Further attempts to get the semaphore will then sleep for ever in
the D state.
This can happen in four situations, all involving an attempt to allocate a new
session keyring:
(1) ENOMEM.
(2) The users key quota being reached.
(3) A keyring name that is an empty string.
(4) A keyring name that is too long.
Any user may attempt this operation, and so any user can cause the problem to
occur.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This fixes five bugs in the key management syscall interface:
(1) add_key() returns 0 rather than EINVAL if the key type is "".
Checking the key type isn't "" should be left to lookup_user_key().
(2) request_key() returns ENOKEY rather than EPERM if the key type begins
with a ".".
lookup_user_key() can't do this because internal key types begin with a
".".
(3) Key revocation always returns 0, even if it fails.
(4) Key read can return EAGAIN rather than EACCES under some circumstances.
A key is permitted to by read by a process if it doesn't grant read
access, but it does grant search access and it is in the process's
keyrings. That search returns EAGAIN if it fails, and this needs
translating to EACCES.
(5) request_key() never adds the new key to the destination keyring if one is
supplied.
The wrong macro was being used to test for an error condition: PTR_ERR()
will always return true, whether or not there's an error; this should've
been IS_ERR().
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Linus Torvalds <torvalds@osdl.org>
This patch fixes the address length checks in the selinux_socket_connect
hook to be no more restrictive than the underlying ipv4 and ipv6 code;
otherwise, this hook can reject valid connect calls. This patch is in
response to a bug report where an application was calling connect on an
INET6 socket with an address that didn't include the optional scope id and
failing due to these checks.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: James Morris <jmorris@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Implement kernel labeling of the MLS (multilevel security) field of
security contexts for files which have no existing MLS field. This is to
enable upgrades of a system from non-MLS to MLS without performing a full
filesystem relabel including all of the mountpoints, which would be quite
painful for users.
With this patch, with MLS enabled, if a file has no MLS field, the kernel
internally adds an MLS field to the in-core inode (but not to the on-disk
file). This MLS field added is the default for the superblock, allowing
per-mountpoint control over the values via fixed policy or mount options.
This patch has been tested by enabling MLS without relabeling its
filesystem, and seems to be working correctly.
Signed-off-by: James Morris <jmorris@redhat.com>
Signed-off-by: Stephen Smalley <sds@epoch.ncsc.mil>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Once again, the simple_attr in libfs was actually sufficient - I'd
thought the __attribute__(format(printk(1,2))) was more mysterious than
it really is.
At last, here is the full patch to make seclvl use securityfs.
Signed-off-by: Serge Hallyn <serue@us.ibm.com>
Signed-off-by: Chris Wright <chrisw@osdl.org>
--
seclvl.c | 228 +++++++++++++++++++--------------------------------------------
1 files changed, 70 insertions(+), 158 deletions(-)
Index: linux-2.6.13-rc1/security/seclvl.c
===================================================================
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>
The attached patch makes the keyring functions calculate the new size of a
keyring's payload based on the size of pointer to the key struct, not the size
of the key struct itself.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Currently selinux_sb_copy_data requires an entire page be allocated to
*orig when the function is called. This "requirement" is based on the fact
that we call copy_page(in_save, nosec_save) and in_save = orig when the
data is not FS_BINARY_MOUNTDATA. This means that if a caller were to call
do_kern_mount with only about 10 bytes of options, they would get passed
here and then we would corrupt PAGE_SIZE - 10 bytes of memory (with all
zeros.)
Currently it appears all in kernel FS's use one page of data so this has
not been a problem. An out of kernel FS did just what is described above
and it would almost always panic shortly after they tried to mount. From
looking else where in the kernel it is obvious that this string of data
must always be null terminated. (See example in do_mount where it always
zeros the last byte.) Thus I suggest we use strcpy in place of copy_page.
In this way we make sure the amount we copy is always less than or equal to
the amount we received and since do_mount is zeroing the last byte this
should be safe for all.
Signed-off-by: Eric Paris <eparis@parisplace.org>
Cc: Stephen Smalley <sds@epoch.ncsc.mil>
Acked-by: James Morris <jmorris@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2.6.12-rc6-mm1 has a few remaining synchronize_kernel()s, some (but not
all) in comments. This patch changes these synchronize_kernel() calls (and
comments) to synchronize_rcu() or synchronize_sched() as follows:
- arch/x86_64/kernel/mce.c mce_read(): change to synchronize_sched() to
handle races with machine-check exceptions (synchronize_rcu() would not cut
it given RCU implementations intended for hardcore realtime use.
- drivers/input/serio/i8042.c i8042_stop(): change to synchronize_sched() to
handle races with i8042_interrupt() interrupt handler. Again,
synchronize_rcu() would not cut it given RCU implementations intended for
hardcore realtime use.
- include/*/kdebug.h comments: change to synchronize_sched() to handle races
with NMIs. As before, synchronize_rcu() would not cut it...
- include/linux/list.h comment: change to synchronize_rcu(), since this
comment is for list_del_rcu().
- security/keys/key.c unregister_key_type(): change to synchronize_rcu(),
since this is interacting with RCU read side.
- security/keys/process_keys.c install_session_keyring(): change to
synchronize_rcu(), since this is interacting with RCU read side.
Signed-off-by: "Paul E. McKenney" <paulmck@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch,based on sample code by Roland McGrath, adds an execheap
permission check that controls the ability to make the heap executable so
that this can be prevented in almost all cases (the X server is presently
an exception, but this will hopefully be resolved in the future) so that
even programs with execmem permission will need to have the anonymous
memory mapped in order to make it executable.
The only reason that we use a permission check for such restriction (vs.
making it unconditional) is that the X module loader presently needs it; it
could possibly be made unconditional in the future when X is changed.
The policy patch for the execheap permission is available at:
http://pearls.tuxedo-es.org/patches/selinux/policy-execheap.patch
Signed-off-by: Lorenzo Hernandez Garcia-Hierro <lorenzo@gnu.org>
Acked-by: James Morris <jmorris@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch adds an execstack permission check that controls the ability to
make the main process stack executable so that attempts to make the stack
executable can still be prevented even if the process is allowed the
existing execmem permission in order to e.g. perform runtime code
generation. Note that this does not yet address thread stacks. Note also
that unlike the execmem check, the execstack check is only applied on
mprotect calls, not mmap calls, as the current security_file_mmap hook is
not passed the necessary information presently.
The original author of the code that makes the distinction of the stack
region, is Ingo Molnar, who wrote it within his patch for
/proc/<pid>/maps markers.
(http://marc.theaimsgroup.com/?l=linux-kernel&m=110719881508591&w=2)
The patches also can be found at:
http://pearls.tuxedo-es.org/patches/selinux/policy-execstack.patchhttp://pearls.tuxedo-es.org/patches/selinux/kernel-execstack.patch
policy-execstack.patch is the patch that needs to be applied to the policy in
order to support the execstack permission and exclude it
from general_domain_access within macros/core_macros.te.
kernel-execstack.patch adds such permission to the SELinux code within
the kernel and adds the proper permission check to the selinux_file_mprotect() hook.
Signed-off-by: Lorenzo Hernandez Garcia-Hierro <lorenzo@gnu.org>
Acked-by: James Morris <jmorris@redhat.com>
Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Export this symbol to GPL modules for eCryptfs: an out-of-tree GPL'ed
filesystem.
Signed off by: Michael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The attached patch makes the following changes:
(1) There's a new special key type called ".request_key_auth".
This is an authorisation key for when one process requests a key and
another process is started to construct it. This type of key cannot be
created by the user; nor can it be requested by kernel services.
Authorisation keys hold two references:
(a) Each refers to a key being constructed. When the key being
constructed is instantiated the authorisation key is revoked,
rendering it of no further use.
(b) The "authorising process". This is either:
(i) the process that called request_key(), or:
(ii) if the process that called request_key() itself had an
authorisation key in its session keyring, then the authorising
process referred to by that authorisation key will also be
referred to by the new authorisation key.
This means that the process that initiated a chain of key requests
will authorise the lot of them, and will, by default, wind up with
the keys obtained from them in its keyrings.
(2) request_key() creates an authorisation key which is then passed to
/sbin/request-key in as part of a new session keyring.
(3) When request_key() is searching for a key to hand back to the caller, if
it comes across an authorisation key in the session keyring of the
calling process, it will also search the keyrings of the process
specified therein and it will use the specified process's credentials
(fsuid, fsgid, groups) to do that rather than the calling process's
credentials.
This allows a process started by /sbin/request-key to find keys belonging
to the authorising process.
(4) A key can be read, even if the process executing KEYCTL_READ doesn't have
direct read or search permission if that key is contained within the
keyrings of a process specified by an authorisation key found within the
calling process's session keyring, and is searchable using the
credentials of the authorising process.
This allows a process started by /sbin/request-key to read keys belonging
to the authorising process.
(5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
KEYCTL_NEGATE will specify a keyring of the authorising process, rather
than the process doing the instantiation.
(6) One of the process keyrings can be nominated as the default to which
request_key() should attach new keys if not otherwise specified. This is
done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
constants. The current setting can also be read using this call.
(7) request_key() is partially interruptible. If it is waiting for another
process to finish constructing a key, it can be interrupted. This permits
a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The attached patch uses RCU to manage the session keyring pointer in struct
signal_struct. This means that searching need not disable interrupts and get
a the sighand spinlock to access this pointer. Furthermore, by judicious use
of rcu_read_(un)lock(), this patch also avoids the need to take and put
refcounts on the session keyring itself, thus saving on even more atomic ops.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The attached patch makes it possible to pass a session keyring through to the
process spawned by call_usermodehelper(). This allows patch 3/3 to pass an
authorisation key through to /sbin/request-key, thus permitting better access
controls when doing just-in-time key creation.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The attached patch changes the key implementation in a number of ways:
(1) It removes the spinlock from the key structure.
(2) The key flags are now accessed using atomic bitops instead of
write-locking the key spinlock and using C bitwise operators.
The three instantiation flags are dealt with with the construction
semaphore held during the request_key/instantiate/negate sequence, thus
rendering the spinlock superfluous.
The key flags are also now bit numbers not bit masks.
(3) The key payload is now accessed using RCU. This permits the recursive
keyring search algorithm to be simplified greatly since no locks need be
taken other than the usual RCU preemption disablement. Searching now does
not require any locks or semaphores to be held; merely that the starting
keyring be pinned.
(4) The keyring payload now includes an RCU head so that it can be disposed
of by call_rcu(). This requires that the payload be copied on unlink to
prevent introducing races in copy-down vs search-up.
(5) The user key payload is now a structure with the data following it. It
includes an RCU head like the keyring payload and for the same reason. It
also contains a data length because the data length in the key may be
changed on another CPU whilst an RCU protected read is in progress on the
payload. This would then see the supposed RCU payload and the on-key data
length getting out of sync.
I'm tempted to drop the key's datalen entirely, except that it's used in
conjunction with quota management and so is a little tricky to get rid
of.
(6) Update the keys documentation.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add a new `suid_dumpable' sysctl:
This value can be used to query and set the core dump mode for setuid
or otherwise protected/tainted binaries. The modes are
0 - (default) - traditional behaviour. Any process which has changed
privilege levels or is execute only will not be dumped
1 - (debug) - all processes dump core when possible. The core dump is
owned by the current user and no security is applied. This is intended
for system debugging situations only. Ptrace is unchecked.
2 - (suidsafe) - any binary which normally would not be dumped is dumped
readable by root only. This allows the end user to remove such a dump but
not access it directly. For security reasons core dumps in this mode will
not overwrite one another or other files. This mode is appropriate when
adminstrators are attempting to debug problems in a normal environment.
(akpm:
> > +EXPORT_SYMBOL(suid_dumpable);
>
> EXPORT_SYMBOL_GPL?
No problem to me.
> > if (current->euid == current->uid && current->egid == current->gid)
> > current->mm->dumpable = 1;
>
> Should this be SUID_DUMP_USER?
Actually the feedback I had from last time was that the SUID_ defines
should go because its clearer to follow the numbers. They can go
everywhere (and there are lots of places where dumpable is tested/used
as a bool in untouched code)
> Maybe this should be renamed to `dump_policy' or something. Doing that
> would help us catch any code which isn't using the #defines, too.
Fair comment. The patch was designed to be easy to maintain for Red Hat
rather than for merging. Changing that field would create a gigantic
diff because it is used all over the place.
)
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Davi Arnaut