linux-toradex.git/security, branch v2.6.31.7

ima: replace GFP_KERNEL with GFP_NOFS

2009-12-08T18:21:35+00:00

commit c09c59e6a070d6af05f238f255aea268185273ef upstream.

While running fsstress tests on the NFSv4 mounted ext3 and ext4
filesystem, the following call trace was generated on the nfs
server machine.

Replace GFP_KERNEL with GFP_NOFS in ima_iint_insert() to avoid a
potential deadlock.

     =================================
    [ INFO: inconsistent lock state ]
    2.6.31-31.el6.x86_64 #1
    ---------------------------------
    inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
    kswapd2/75 [HC0[0]:SC0[0]:HE1:SE1] takes:
     (jbd2_handle){+.+.?.}, at: [] jbd2_journal_start+0xfe/0x13f
    {RECLAIM_FS-ON-W} state was registered at:
      [] mark_held_locks+0x65/0x99
      [] lockdep_trace_alloc+0xbd/0xf5
      [] kmem_cache_alloc+0x40/0x185
      [] ima_iint_insert+0x3d/0xf1
      [] ima_inode_alloc+0x25/0x44
      [] inode_init_always+0xec/0x271
      [] alloc_inode+0x51/0xa1
      [] new_inode+0x2e/0x94
      [] ext4_new_inode+0xb8/0xdc9
      [] ext4_create+0xcf/0x175
      [] vfs_create+0x82/0xb8
      [] do_filp_open+0x32c/0x9ee
      [] do_sys_open+0x6c/0x12c
      [] sys_open+0x2e/0x44
      [] system_call_fastpath+0x16/0x1b
      [] 0xffffffffffffffff
    irq event stamp: 90371
    hardirqs last  enabled at (90371): []
    kmem_cache_alloc+0xf0/0x185
    hardirqs last disabled at (90370): []
    kmem_cache_alloc+0x89/0x185
    softirqs last  enabled at (89492): []
    __do_softirq+0x1bf/0x1eb
    softirqs last disabled at (89477): [] call_softirq+0x1c/0x30

    other info that might help us debug this:
    2 locks held by kswapd2/75:
     #0:  (shrinker_rwsem){++++..}, at: [] shrink_slab+0x44/0x177
     #1:  (&type->s_umount_key#25){++++..}, at: []

Reported-by: Muni P. Beerakam 
Reported-by: Amit K. Arora 
Signed-off-by: Mimi Zohar 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

KEYS: get_instantiation_keyring() should inc the keyring refcount in all cases

2009-11-10T00:22:49+00:00

commit 21279cfa107af07ef985539ac0de2152b9cba5f5 upstream.

The destination keyring specified to request_key() and co. is made available to
the process that instantiates the key (the slave process started by
/sbin/request-key typically).  This is passed in the request_key_auth struct as
the dest_keyring member.

keyctl_instantiate_key and keyctl_negate_key() call get_instantiation_keyring()
to get the keyring to attach the newly constructed key to at the end of
instantiation.  This may be given a specific keyring into which a link will be
made later, or it may be asked to find the keyring passed to request_key().  In
the former case, it returns a keyring with the refcount incremented by
lookup_user_key(); in the latter case, it returns the keyring from the
request_key_auth struct - and does _not_ increment the refcount.

The latter case will eventually result in an oops when the keyring prematurely
runs out of references and gets destroyed.  The effect may take some time to
show up as the key is destroyed lazily.

To fix this, the keyring returned by get_instantiation_keyring() must always
have its refcount incremented, no matter where it comes from.

This can be tested by setting /etc/request-key.conf to:

#OP	TYPE	DESCRIPTION	CALLOUT INFO	PROGRAM ARG1 ARG2 ARG3 ...
#======	=======	===============	===============	===============================
create  *	test:*		*		|/bin/false %u %g %d %{user:_display}
negate	*	*		*		/bin/keyctl negate %k 10 @u

and then doing:

	keyctl add user _display aaaaaaaa @u
        while keyctl request2 user test:x test:x @u &&
        keyctl list @u;
        do
                keyctl request2 user test:x test:x @u;
                sleep 31;
                keyctl list @u;
        done

which will oops eventually.  Changing the negate line to have @u rather than
%S at the end is important as that forces the latter case by passing a special
keyring ID rather than an actual keyring ID.

Reported-by: Alexander Zangerl 
Signed-off-by: David Howells 
Tested-by: Alexander Zangerl 
Signed-off-by: Linus Torvalds 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

IMA: update ima_counts_put

2009-09-07T01:54:58+00:00

- As ima_counts_put() may be called after the inode has been freed,
verify that the inode is not NULL, before dereferencing it.

- Maintain the IMA file counters in may_open() properly, decrementing
any counter increments on subsequent errors.

Reported-by: Ciprian Docan 
Reported-by: J.R. Okajima 
Signed-off-by: Mimi Zohar 
Acked-by: Eric Paris

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6

2009-08-27T03:17:07+00:00

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
  IMA: iint put in ima_counts_get and put

IMA: iint put in ima_counts_get and put

2009-08-27T01:01:03+00:00

ima_counts_get() calls ima_iint_find_insert_get() which takes a reference
to the iint in question, but does not put that reference at the end of the
function.  This can lead to a nasty memory leak.  Easy enough to reproduce:

#include 
#include 

int main (void)
{
	int i;
	void *ptr;

	for (i=0; i < 100000; i++) {
		ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE,
			   MAP_SHARED|MAP_ANONYMOUS, -1, 0);
		if (ptr == MAP_FAILED)
			return 2;
		munmap(ptr, 4096);
	}

	return 0;
}

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

ima: hashing large files bug fix

2009-08-24T04:58:29+00:00

Hashing files larger than INT_MAX causes process to loop.
Dependent on redefining kernel_read() offset type to loff_t.

(http://bugzilla.kernel.org/show_bug.cgi?id=13909)

Cc: stable@kernel.org
Signed-off-by: Mimi Zohar 
Signed-off-by: James Morris

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

SELinux: call cap_file_mmap in selinux_file_mmap

2009-08-17T05:08:48+00:00

Currently SELinux does not check CAP_SYS_RAWIO in the file_mmap hook.  This
means there is no DAC check on the ability to mmap low addresses in the
memory space.  This function adds the DAC check for CAP_SYS_RAWIO while
maintaining the selinux check on mmap_zero.  This means that processes
which need to mmap low memory will need CAP_SYS_RAWIO and mmap_zero but will
NOT need the SELinux sys_rawio capability.

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