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

SELinux: do not compute transition labels on mountpoint labeled filesystems

2011-02-17T22:47:26+00:00

commit 415103f9932d45f7927f4b17e3a9a13834cdb9a1 upstream.

selinux_inode_init_security computes transitions sids even for filesystems
that use mount point labeling.  It shouldn't do that.  It should just use
the mount point label always and no matter what.

This causes 2 problems.  1) it makes file creation slower than it needs to be
since we calculate the transition sid and 2) it allows files to be created
with a different label than the mount point!

# id -Z
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
# sesearch --type --class file --source sysadm_t --target tmp_t
Found 1 semantic te rules:
   type_transition sysadm_t tmp_t : file user_tmp_t;

# mount -o loop,context="system_u:object_r:tmp_t:s0"  /tmp/fs /mnt/tmp

# ls -lZ /mnt/tmp
drwx------. root root system_u:object_r:tmp_t:s0       lost+found
# touch /mnt/tmp/file1
# ls -lZ /mnt/tmp
-rw-r--r--. root root staff_u:object_r:user_tmp_t:s0   file1
drwx------. root root system_u:object_r:tmp_t:s0       lost+found

Whoops, we have a mount point labeled filesystem tmp_t with a user_tmp_t
labeled file!

Signed-off-by: Eric Paris 
Reviewed-by: Reviewed-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

SELinux: define permissions for DCB netlink messages

2011-02-17T22:47:26+00:00

commit 350e4f31e0eaf56dfc3b328d24a11bdf42a41fb8 upstream.

Commit 2f90b865 added two new netlink message types to the netlink route
socket.  SELinux has hooks to define if netlink messages are allowed to
be sent or received, but it did not know about these two new message
types.  By default we allow such actions so noone likely noticed.  This
patch adds the proper definitions and thus proper permissions
enforcement.

Signed-off-by: Eric Paris 
Cc: James Morris 
Signed-off-by: Greg Kroah-Hartman

KEYS: Don't call up_write() if __key_link_begin() returns an error

2011-02-17T22:47:26+00:00

commit 3fc5e98d8cf85e0d77fc597b49e9268dff67400e upstream.

In construct_alloc_key(), up_write() is called in the error path if
__key_link_begin() fails, but this is incorrect as __key_link_begin() only
returns with the nominated keyring locked if it returns successfully.

Without this patch, you might see the following in dmesg:

	=====================================
	[ BUG: bad unlock balance detected! ]
	-------------------------------------
	mount.cifs/5769 is trying to release lock (&key->sem) at:
	[] request_key_and_link+0x263/0x3fc
	but there are no more locks to release!

	other info that might help us debug this:
	3 locks held by mount.cifs/5769:
	 #0:  (&type->s_umount_key#41/1){+.+.+.}, at: [] sget+0x278/0x3e7
	 #1:  (&ret_buf->session_mutex){+.+.+.}, at: [] cifs_get_smb_ses+0x35a/0x443 [cifs]
	 #2:  (root_key_user.cons_lock){+.+.+.}, at: [] request_key_and_link+0x10a/0x3fc

	stack backtrace:
	Pid: 5769, comm: mount.cifs Not tainted 2.6.37-rc6+ #1
	Call Trace:
	 [] ? request_key_and_link+0x263/0x3fc
	 [] print_unlock_inbalance_bug+0xca/0xd5
	 [] lock_release_non_nested+0xc1/0x263
	 [] ? request_key_and_link+0x263/0x3fc
	 [] ? request_key_and_link+0x263/0x3fc
	 [] lock_release+0x17d/0x1a4
	 [] up_write+0x23/0x3b
	 [] request_key_and_link+0x263/0x3fc
	 [] ? cifs_get_spnego_key+0x61/0x21f [cifs]
	 [] request_key+0x41/0x74
	 [] cifs_get_spnego_key+0x200/0x21f [cifs]
	 [] CIFS_SessSetup+0x55d/0x1273 [cifs]
	 [] cifs_setup_session+0x90/0x1ae [cifs]
	 [] cifs_get_smb_ses+0x37f/0x443 [cifs]
	 [] cifs_mount+0x1aa1/0x23f3 [cifs]
	 [] ? alloc_debug_processing+0xdb/0x120
	 [] ? cifs_get_spnego_key+0x1ef/0x21f [cifs]
	 [] cifs_do_mount+0x165/0x2b3 [cifs]
	 [] vfs_kern_mount+0xaf/0x1dc
	 [] do_kern_mount+0x4d/0xef
	 [] do_mount+0x6f4/0x733
	 [] sys_mount+0x88/0xc2
	 [] system_call_fastpath+0x16/0x1b

Reported-by: Jeff Layton 
Signed-off-by: David Howells 
Reviewed-and-Tested-by: Jeff Layton 
Signed-off-by: Linus Torvalds 
Cc: James Morris 
Signed-off-by: Greg Kroah-Hartman

ima: fix add LSM rule bug

2011-01-07T21:58:48+00:00

commit 867c20265459d30a01b021a9c1e81fb4c5832aa9 upstream.

If security_filter_rule_init() doesn't return a rule, then not everything
is as fine as the return code implies.

This bug only occurs when the LSM (eg. SELinux) is disabled at runtime.

Adding an empty LSM rule causes ima_match_rules() to always succeed,
ignoring any remaining rules.

 default IMA TCB policy:
  # PROC_SUPER_MAGIC
  dont_measure fsmagic=0x9fa0
  # SYSFS_MAGIC
  dont_measure fsmagic=0x62656572
  # DEBUGFS_MAGIC
  dont_measure fsmagic=0x64626720
  # TMPFS_MAGIC
  dont_measure fsmagic=0x01021994
  # SECURITYFS_MAGIC
  dont_measure fsmagic=0x73636673

  < LSM specific rule >
  dont_measure obj_type=var_log_t

  measure func=BPRM_CHECK
  measure func=FILE_MMAP mask=MAY_EXEC
  measure func=FILE_CHECK mask=MAY_READ uid=0

Thus without the patch, with the boot parameters 'tcb selinux=0', adding
the above 'dont_measure obj_type=var_log_t' rule to the default IMA TCB
measurement policy, would result in nothing being measured.  The patch
prevents the default TCB policy from being replaced.

Signed-off-by: Mimi Zohar 
Cc: James Morris 
Acked-by: Serge Hallyn 
Cc: David Safford 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

TOMOYO: Don't abuse sys_getpid(), sys_getppid()

2010-09-27T00:53:18+00:00

System call entry functions sys_*() are never to be called from
general kernel code.  The fact that they aren't declared in header
files should have been a clue.  These functions also don't exist on
Alpha since it has sys_getxpid() instead.

Signed-off-by: Ben Hutchings 
Acked-by: Tetsuo Handa 
Signed-off-by: James Morris

KEYS: Fix bug in keyctl_session_to_parent() if parent has no session keyring

2010-09-10T14:30:00+00:00

Fix a bug in keyctl_session_to_parent() whereby it tries to check the ownership
of the parent process's session keyring whether or not the parent has a session
keyring [CVE-2010-2960].

This results in the following oops:

  BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
  IP: [] keyctl_session_to_parent+0x251/0x443
  ...
  Call Trace:
   [] ? keyctl_session_to_parent+0x67/0x443
   [] ? __do_fault+0x24b/0x3d0
   [] sys_keyctl+0xb4/0xb8
   [] system_call_fastpath+0x16/0x1b

if the parent process has no session keyring.

If the system is using pam_keyinit then it mostly protected against this as all
processes derived from a login will have inherited the session keyring created
by pam_keyinit during the log in procedure.

To test this, pam_keyinit calls need to be commented out in /etc/pam.d/.

Reported-by: Tavis Ormandy 
Signed-off-by: David Howells 
Acked-by: Tavis Ormandy 
Signed-off-by: Linus Torvalds

KEYS: Fix RCU no-lock warning in keyctl_session_to_parent()

2010-09-10T14:30:00+00:00

There's an protected access to the parent process's credentials in the middle
of keyctl_session_to_parent().  This results in the following RCU warning:

  ===================================================
  [ INFO: suspicious rcu_dereference_check() usage. ]
  ---------------------------------------------------
  security/keys/keyctl.c:1291 invoked rcu_dereference_check() without protection!

  other info that might help us debug this:

  rcu_scheduler_active = 1, debug_locks = 0
  1 lock held by keyctl-session-/2137:
   #0:  (tasklist_lock){.+.+..}, at: [] keyctl_session_to_parent+0x60/0x236

  stack backtrace:
  Pid: 2137, comm: keyctl-session- Not tainted 2.6.36-rc2-cachefs+ #1
  Call Trace:
   [] lockdep_rcu_dereference+0xaa/0xb3
   [] keyctl_session_to_parent+0xed/0x236
   [] sys_keyctl+0xb4/0xb6
   [] system_call_fastpath+0x16/0x1b

The code should take the RCU read lock to make sure the parents credentials
don't go away, even though it's holding a spinlock and has IRQ disabled.

Signed-off-by: David Howells 
Signed-off-by: Linus Torvalds

ima: always maintain counters

2010-09-07T23:51:41+00:00

commit 8262bb85da allocated the inode integrity struct (iint) before any
inodes were created. Only after IMA was initialized in late_initcall were
the counters updated. This patch updates the counters, whether or not IMA
has been initialized, to resolve 'imbalance' messages.

This patch fixes the bug as reported in bugzilla: 15673.  When the i915
is builtin, the ring_buffer is initialized before IMA, causing the
imbalance message on suspend.

Reported-by: Thomas Meyer 
Signed-off-by: Mimi Zohar 
Tested-by: Thomas Meyer 
Tested-by: David Safford
Cc: Stable Kernel 
Signed-off-by: James Morris

AppArmor: Fix locking from removal of profile namespace

2010-09-07T23:19:34+00:00

The locking for profile namespace removal is wrong, when removing a
profile namespace, it needs to be removed from its parent's list.
Lock the parent of namespace list instead of the namespace being removed.

Signed-off-by: John Johansen 
Signed-off-by: James Morris

AppArmor: Fix splitting an fqname into separate namespace and profile names

2010-09-07T23:19:31+00:00

As per Dan Carpenter 
  If we have a ns name without a following profile then in the original
  code it did "*ns_name = &name[1];".  "name" is NULL so "*ns_name" is
  0x1.  That isn't useful and could cause an oops when this function is
  called from aa_remove_profiles().

Beyond this the assignment of the namespace name was wrong in the case
where the profile name was provided as it was being set to &name[1]
after name  = skip_spaces(split + 1);

Move the ns_name assignment before updating name for the split and
also add skip_spaces, making the interface more robust.

Signed-off-by: John Johansen 
Signed-off-by: James Morris