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

mmap_min_addr check CAP_SYS_RAWIO only for write

2010-05-26T21:29:21+00:00

commit 4ae69e6b718589abe97c9625ccbb1e0bc95a8c0e upstream.

Redirecting directly to lsm, here's the patch discussed on lkml:
http://lkml.org/lkml/2010/4/22/219

The mmap_min_addr value is useful information for an admin to see without
being root ("is my system vulnerable to kernel NULL pointer attacks?") and
its setting is trivially easy for an attacker to determine by calling
mmap() in PAGE_SIZE increments starting at 0, so trying to keep it private
has no value.

Only require CAP_SYS_RAWIO if changing the value, not reading it.

Comment from Serge :

  Me, I like to write my passwords with light blue pen on dark blue
  paper, pasted on my window - if you're going to get my password, you're
  gonna get a headache.

Signed-off-by: Kees Cook 
Acked-by: Serge Hallyn 
Signed-off-by: James Morris 
(cherry picked from commit 822cceec7248013821d655545ea45d1c6a9d15b3)
Signed-off-by: Greg Kroah-Hartman

security: testing the wrong variable in create_by_name()

2010-05-12T21:57:14+00:00

commit b338cc8207eae46640a8d534738fda7b5e48511d upstream.

There is a typo here.  We should be testing "*dentry" instead of
"dentry".  If "*dentry" is an ERR_PTR, it gets dereferenced in either
mkdir() or create() which would cause an OOPs.

Signed-off-by: Dan Carpenter 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

keys: the request_key() syscall should link an existing key to the dest keyring

2010-05-12T21:57:01+00:00

commit 03449cd9eaa4fa3a7faa4a59474bafe2e90bd143 upstream.

The request_key() system call and request_key_and_link() should make a
link from an existing key to the destination keyring (if supplied), not
just from a new key to the destination keyring.

This can be tested by:

	ring=`keyctl newring fred @s`
	keyctl request2 user debug:a a
	keyctl request user debug:a $ring
	keyctl list $ring

If it says:

	keyring is empty

then it didn't work.  If it shows something like:

	1 key in keyring:
	1070462727: --alswrv     0     0 user: debug:a

then it did.

request_key() system call is meant to recursively search all your keyrings for
the key you desire, and, optionally, if it doesn't exist, call out to userspace
to create one for you.

If request_key() finds or creates a key, it should, optionally, create a link
to that key from the destination keyring specified.

Therefore, if, after a successful call to request_key() with a desination
keyring specified, you see the destination keyring empty, the code didn't work
correctly.

If you see the found key in the keyring, then it did - which is what the patch
is required for.

Signed-off-by: David Howells 
Cc: James Morris 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

sysctl: require CAP_SYS_RAWIO to set mmap_min_addr

2010-04-01T22:58:16+00:00

commit 0e1a6ef2dea88101b056b6d9984f3325c5efced3 upstream.

Currently the mmap_min_addr value can only be bypassed during mmap when
the task has CAP_SYS_RAWIO.  However, the mmap_min_addr sysctl value itself
can be adjusted to 0 if euid == 0, allowing a bypass without CAP_SYS_RAWIO.
This patch adds a check for the capability before allowing mmap_min_addr to
be changed.

Signed-off-by: Kees Cook 
Acked-by: Serge Hallyn 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

netlabel: fix export of SELinux categories > 127

2010-03-15T15:49:34+00:00

commit c36f74e67fa12202dbcb4ad92c5ac844f9d36b98 upstream.

This fixes corrupted CIPSO packets when SELinux categories greater than 127
are used.  The bug occured on the second (and later) loops through the
while; the inner for loop through the ebitmap->maps array used the same
index as the NetLabel catmap->bitmap array, even though the NetLabel bitmap
is twice as long as the SELinux bitmap.

Signed-off-by: Joshua Roys 
Acked-by: Paul Moore 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

SECURITY: selinux, fix update_rlimit_cpu parameter

2010-02-09T12:50:53+00:00

commit 17740d89785aeb4143770923d67c293849414710 upstream.

Don't pass current RLIMIT_RTTIME to update_rlimit_cpu() in
selinux_bprm_committing_creds, since update_rlimit_cpu expects
RLIMIT_CPU limit.

Use proper rlim[RLIMIT_CPU].rlim_cur instead to fix that.

Signed-off-by: Jiri Slaby 
Acked-by: James Morris 
Cc: Stephen Smalley 
Cc: Eric Paris 
Cc: David Howells 
Signed-off-by: Greg Kroah-Hartman

Keys: KEYCTL_SESSION_TO_PARENT needs TIF_NOTIFY_RESUME architecture support

2010-01-06T23:04:46+00:00

commit a00ae4d21b2fa9379914f270ffffd8d3bec55430 upstream.

As of commit ee18d64c1f632043a02e6f5ba5e045bb26a5465f ("KEYS: Add a keyctl to
install a process's session keyring on its parent [try #6]"), CONFIG_KEYS=y
fails to build on architectures that haven't implemented TIF_NOTIFY_RESUME yet:

security/keys/keyctl.c: In function 'keyctl_session_to_parent':
security/keys/keyctl.c:1312: error: 'TIF_NOTIFY_RESUME' undeclared (first use in this function)
security/keys/keyctl.c:1312: error: (Each undeclared identifier is reported only once
security/keys/keyctl.c:1312: error: for each function it appears in.)

Make KEYCTL_SESSION_TO_PARENT depend on TIF_NOTIFY_RESUME until
m68k, and xtensa have implemented it.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: James Morris 
Acked-by: Mike Frysinger 
Signed-off-by: Greg Kroah-Hartman

NOMMU: Optimise away the {dac_,}mmap_min_addr tests

2010-01-06T23:04:30+00:00

commit 6e1415467614e854fee660ff6648bd10fa976e95 upstream.

In NOMMU mode clamp dac_mmap_min_addr to zero to cause the tests on it to be
skipped by the compiler.  We do this as the minimum mmap address doesn't make
any sense in NOMMU mode.

mmap_min_addr and round_hint_to_min() can be discarded entirely in NOMMU mode.

Signed-off-by: David Howells 
Acked-by: Eric Paris 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

ima: replace GFP_KERNEL with GFP_NOFS

2009-11-18T21:42:01+00:00

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 
Cc: stable@kernel.org
Signed-off-by: Mimi Zohar 
Signed-off-by: James Morris

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

2009-10-15T22:19:58+00:00

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