linux-toradex.git/security/apparmor, branch v3.0.79

fix apparmor dereferencing potentially freed dentry, sanitize __d_path() API

2011-12-21T20:57:36+00:00

commit 02125a826459a6ad142f8d91c5b6357562f96615 upstream.

__d_path() API is asking for trouble and in case of apparmor d_namespace_path()
getting just that.  The root cause is that when __d_path() misses the root
it had been told to look for, it stores the location of the most remote ancestor
in *root.  Without grabbing references.  Sure, at the moment of call it had
been pinned down by what we have in *path.  And if we raced with umount -l, we
could have very well stopped at vfsmount/dentry that got freed as soon as
prepend_path() dropped vfsmount_lock.

It is safe to compare these pointers with pre-existing (and known to be still
alive) vfsmount and dentry, as long as all we are asking is "is it the same
address?".  Dereferencing is not safe and apparmor ended up stepping into
that.  d_namespace_path() really wants to examine the place where we stopped,
even if it's not connected to our namespace.  As the result, it looked
at ->d_sb->s_magic of a dentry that might've been already freed by that point.
All other callers had been careful enough to avoid that, but it's really
a bad interface - it invites that kind of trouble.

The fix is fairly straightforward, even though it's bigger than I'd like:
	* prepend_path() root argument becomes const.
	* __d_path() is never called with NULL/NULL root.  It was a kludge
to start with.  Instead, we have an explicit function - d_absolute_root().
Same as __d_path(), except that it doesn't get root passed and stops where
it stops.  apparmor and tomoyo are using it.
	* __d_path() returns NULL on path outside of root.  The main
caller is show_mountinfo() and that's precisely what we pass root for - to
skip those outside chroot jail.  Those who don't want that can (and do)
use d_path().
	* __d_path() root argument becomes const.  Everyone agrees, I hope.
	* apparmor does *NOT* try to use __d_path() or any of its variants
when it sees that path->mnt is an internal vfsmount.  In that case it's
definitely not mounted anywhere and dentry_path() is exactly what we want
there.  Handling of sysctl()-triggered weirdness is moved to that place.
	* if apparmor is asked to do pathname relative to chroot jail
and __d_path() tells it we it's not in that jail, the sucker just calls
d_absolute_path() instead.  That's the other remaining caller of __d_path(),
BTW.
        * seq_path_root() does _NOT_ return -ENAMETOOLONG (it's stupid anyway -
the normal seq_file logics will take care of growing the buffer and redoing
the call of ->show() just fine).  However, if it gets path not reachable
from root, it returns SEQ_SKIP.  The only caller adjusted (i.e. stopped
ignoring the return value as it used to do).

Reviewed-by: John Johansen 
ACKed-by: John Johansen 
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman

AppArmor: Fix masking of capabilities in complain mode

2011-08-05T04:58:42+00:00

commit 25e75dff519bcce2cb35023105e7df51d7b9e691 upstream.

AppArmor is masking the capabilities returned by capget against the
capabilities mask in the profile.  This is wrong, in complain mode the
profile has effectively all capabilities, as the profile restrictions are
not being enforced, merely tested against to determine if an access is
known by the profile.

This can result in the wrong behavior of security conscience applications
like sshd which examine their capability set, and change their behavior
accordingly.  In this case because of the masked capability set being
returned sshd fails due to DAC checks, even when the profile is in complain
mode.

Kernels affected: 2.6.36 - 3.0.

Signed-off-by: John Johansen 
Signed-off-by: Greg Kroah-Hartman

AppArmor: Fix reference to rcu protected pointer outside of rcu_read_lock

2011-08-05T04:58:41+00:00

commit 04fdc099f9c80c7775dbac388fc97e156d4d47e7 upstream.

The pointer returned from tracehook_tracer_task() is only valid inside
the rcu_read_lock.  However the tracer pointer obtained is being passed
to aa_may_ptrace outside of the rcu_read_lock critical section.

Mover the aa_may_ptrace test into the rcu_read_lock critical section, to
fix this.

Kernels affected: 2.6.36 - 3.0

Reported-by: Oleg Nesterov 
Signed-off-by: John Johansen 
Signed-off-by: Greg Kroah-Hartman

AppArmor: Fix sleep in invalid context from task_setrlimit

2011-06-09T01:46:53+00:00

Affected kernels 2.6.36 - 3.0

AppArmor may do a GFP_KERNEL memory allocation with task_lock(tsk->group_leader);
held when called from security_task_setrlimit.  This will only occur when the
task's current policy has been replaced, and the task's creds have not been
updated before entering the LSM security_task_setrlimit() hook.

BUG: sleeping function called from invalid context at mm/slub.c:847
 in_atomic(): 1, irqs_disabled(): 0, pid: 1583, name: cupsd
 2 locks held by cupsd/1583:
  #0:  (tasklist_lock){.+.+.+}, at: [] do_prlimit+0x61/0x189
  #1:  (&(&p->alloc_lock)->rlock){+.+.+.}, at: []
do_prlimit+0x94/0x189
 Pid: 1583, comm: cupsd Not tainted 3.0.0-rc2-git1 #7
 Call Trace:
  [] __might_sleep+0x10d/0x112
  [] slab_pre_alloc_hook.isra.49+0x2d/0x33
  [] kmem_cache_alloc+0x22/0x132
  [] prepare_creds+0x35/0xe4
  [] aa_replace_current_profile+0x35/0xb2
  [] aa_current_profile+0x45/0x4c
  [] apparmor_task_setrlimit+0x19/0x3a
  [] security_task_setrlimit+0x11/0x13
  [] do_prlimit+0xd2/0x189
  [] sys_setrlimit+0x3b/0x48
  [] system_call_fastpath+0x16/0x1b

Signed-off-by: John Johansen 
Reported-by: Miles Lane 
Cc: stable@kernel.org
Signed-off-by: James Morris

AppArmor: fix oops in apparmor_setprocattr

2011-06-01T03:07:03+00:00

When invalid parameters are passed to apparmor_setprocattr a NULL deref
oops occurs when it tries to record an audit message. This is because
it is passing NULL for the profile parameter for aa_audit. But aa_audit
now requires that the profile passed is not NULL.

Fix this by passing the current profile on the task that is trying to
setprocattr.

Signed-off-by: Kees Cook 
Signed-off-by: John Johansen 
Cc: stable@kernel.org
Signed-off-by: James Morris

Create Documentation/security/,

2011-05-19T22:59:38+00:00

move LSM-, credentials-, and keys-related files from Documentation/
  to Documentation/security/,
add Documentation/security/00-INDEX, and
update all occurrences of Documentation/
  to Documentation/security/.

Fix common misspellings

2011-03-31T14:26:23+00:00

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi

userns: security: make capabilities relative to the user namespace

2011-03-24T02:47:02+00:00

- Introduce ns_capable to test for a capability in a non-default
  user namespace.
- Teach cap_capable to handle capabilities in a non-default
  user namespace.

The motivation is to get to the unprivileged creation of new
namespaces.  It looks like this gets us 90% of the way there, with
only potential uid confusion issues left.

I still need to handle getting all caps after creation but otherwise I
think I have a good starter patch that achieves all of your goals.

Changelog:
	11/05/2010: [serge] add apparmor
	12/14/2010: [serge] fix capabilities to created user namespaces
	Without this, if user serge creates a user_ns, he won't have
	capabilities to the user_ns he created.  THis is because we
	were first checking whether his effective caps had the caps
	he needed and returning -EPERM if not, and THEN checking whether
	he was the creator.  Reverse those checks.
	12/16/2010: [serge] security_real_capable needs ns argument in !security case
	01/11/2011: [serge] add task_ns_capable helper
	01/11/2011: [serge] add nsown_capable() helper per Bastian Blank suggestion
	02/16/2011: [serge] fix a logic bug: the root user is always creator of
		    init_user_ns, but should not always have capabilities to
		    it!  Fix the check in cap_capable().
	02/21/2011: Add the required user_ns parameter to security_capable,
		    fixing a compile failure.
	02/23/2011: Convert some macros to functions as per akpm comments.  Some
		    couldn't be converted because we can't easily forward-declare
		    them (they are inline if !SECURITY, extern if SECURITY).  Add
		    a current_user_ns function so we can use it in capability.h
		    without #including cred.h.  Move all forward declarations
		    together to the top of the #ifdef __KERNEL__ section, and use
		    kernel-doc format.
	02/23/2011: Per dhowells, clean up comment in cap_capable().
	02/23/2011: Per akpm, remove unreachable 'return -EPERM' in cap_capable.

(Original written and signed off by Eric;  latest, modified version
acked by him)

[akpm@linux-foundation.org: fix build]
[akpm@linux-foundation.org: export current_user_ns() for ecryptfs]
[serge.hallyn@canonical.com: remove unneeded extra argument in selinux's task_has_capability]
Signed-off-by: Eric W. Biederman 
Signed-off-by: Serge E. Hallyn 
Acked-by: "Eric W. Biederman" 
Acked-by: Daniel Lezcano 
Acked-by: David Howells 
Cc: James Morris 
Signed-off-by: Serge E. Hallyn 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'security-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev into next

2011-03-09T03:12:07+00:00

AppArmor: kill unused macros in lsm.c

2011-03-09T01:04:07+00:00

Remove unused macros.

Signed-off-by: Shan Wei 
Signed-off-by: John Johansen