linux-toradex.git/security/commoncap.c, branch v3.3.5

security: fix compile error in commoncap.c

2012-04-22T22:39:17+00:00

commit 51b79bee627d526199b2f6a6bef8ee0c0739b6d1 upstream.

Add missing "personality.h"
security/commoncap.c: In function 'cap_bprm_set_creds':
security/commoncap.c:510: error: 'PER_CLEAR_ON_SETID' undeclared (first use in this function)
security/commoncap.c:510: error: (Each undeclared identifier is reported only once
security/commoncap.c:510: error: for each function it appears in.)

Signed-off-by: Jonghwan Choi 
Acked-by: Serge Hallyn 
Signed-off-by: James Morris 
Cc: Eric Paris 
Signed-off-by: Greg Kroah-Hartman

fcaps: clear the same personality flags as suid when fcaps are used

2012-04-22T22:39:16+00:00

commit d52fc5dde171f030170a6cb78034d166b13c9445 upstream.

If a process increases permissions using fcaps all of the dangerous
personality flags which are cleared for suid apps should also be cleared.
Thus programs given priviledge with fcaps will continue to have address space
randomization enabled even if the parent tried to disable it to make it
easier to attack.

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

Merge branch 'for-linus' of git://selinuxproject.org/~jmorris/linux-security

2012-01-15T02:36:33+00:00

* 'for-linus' of git://selinuxproject.org/~jmorris/linux-security:
  capabilities: remove __cap_full_set definition
  security: remove the security_netlink_recv hook as it is equivalent to capable()
  ptrace: do not audit capability check when outputing /proc/pid/stat
  capabilities: remove task_ns_* functions
  capabitlies: ns_capable can use the cap helpers rather than lsm call
  capabilities: style only - move capable below ns_capable
  capabilites: introduce new has_ns_capabilities_noaudit
  capabilities: call has_ns_capability from has_capability
  capabilities: remove all _real_ interfaces
  capabilities: introduce security_capable_noaudit
  capabilities: reverse arguments to security_capable
  capabilities: remove the task from capable LSM hook entirely
  selinux: sparse fix: fix several warnings in the security server cod
  selinux: sparse fix: fix warnings in netlink code
  selinux: sparse fix: eliminate warnings for selinuxfs
  selinux: sparse fix: declare selinux_disable() in security.h
  selinux: sparse fix: move selinux_complete_init
  selinux: sparse fix: make selinux_secmark_refcount static
  SELinux: Fix RCU deref check warning in sel_netport_insert()

Manually fix up a semantic mis-merge wrt security_netlink_recv():

 - the interface was removed in commit fd7784615248 ("security: remove
   the security_netlink_recv hook as it is equivalent to capable()")

 - a new user of it appeared in commit a38f7907b926 ("crypto: Add
   userspace configuration API")

causing no automatic merge conflict, but Eric Paris pointed out the
issue.

security: remove the security_netlink_recv hook as it is equivalent to capable()

2012-01-05T23:53:01+00:00

Once upon a time netlink was not sync and we had to get the effective
capabilities from the skb that was being received.  Today we instead get
the capabilities from the current task.  This has rendered the entire
purpose of the hook moot as it is now functionally equivalent to the
capable() call.

Signed-off-by: Eric Paris

capabilities: remove the task from capable LSM hook entirely

2012-01-05T23:52:53+00:00

The capabilities framework is based around credentials, not necessarily the
current task.  Yet we still passed the current task down into LSMs from the
security_capable() LSM hook as if it was a meaningful portion of the security
decision.  This patch removes the 'generic' passing of current and instead
forces individual LSMs to use current explicitly if they think it is
appropriate.  In our case those LSMs are SELinux and AppArmor.

I believe the AppArmor use of current is incorrect, but that is wholely
unrelated to this patch.  This patch does not change what AppArmor does, it
just makes it clear in the AppArmor code that it is doing it.

The SELinux code still uses current in it's audit message, which may also be
wrong and needs further investigation.  Again this is NOT a change, it may
have always been wrong, this patch just makes it clear what is happening.

Signed-off-by: Eric Paris

capabilities: initialize has_cap

2011-08-15T23:20:45+00:00

Initialize has_cap in cap_bprm_set_creds()

Reported-by: Andrew G. Morgan 
Signed-off-by: Serge Hallyn 
Signed-off-by: James Morris

capabilities: do not grant full privs for setuid w/ file caps + no effective caps

2011-08-12T05:06:57+00:00

A task (when !SECURE_NOROOT) which executes a setuid-root binary will
obtain root privileges while executing that binary.  If the binary also
has effective capabilities set, then only those capabilities will be
granted.  The rationale is that the same binary can carry both setuid-root
and the minimal file capability set, so that on a filesystem not
supporting file caps the binary can still be executed with privilege,
while on a filesystem supporting file caps it will run with minimal
privilege.

This special case currently does NOT happen if there are file capabilities
but no effective capabilities.  Since capability-aware programs can very
well start with empty pE but populated pP and move those caps to pE when
needed.  In other words, if the file has file capabilities but NOT
effective capabilities, then we should do the same thing as if there
were file capabilities, and not grant full root privileges.

This patchset does that.

(Changelog by Serge Hallyn).

Signed-off-by: Zhi Li 
Acked-by: Serge Hallyn 
Signed-off-by: James Morris

capabilities: do not special case exec of init

2011-04-04T00:31:06+00:00

When the global init task is exec'd we have special case logic to make sure
the pE is not reduced.  There is no reason for this.  If init wants to drop
it's pE is should be allowed to do so.  Remove this special logic.

Signed-off-by: Eric Paris 
Acked-by: Serge Hallyn 
Acked-by: David Howells 
Acked-by: Andrew G. Morgan 
Signed-off-by: James Morris

userns: allow ptrace from non-init user namespaces

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

ptrace is allowed to tasks in the same user namespace according to the
usual rules (i.e.  the same rules as for two tasks in the init user
namespace).  ptrace is also allowed to a user namespace to which the
current task the has CAP_SYS_PTRACE capability.

Changelog:
	Dec 31: Address feedback by Eric:
		. Correct ptrace uid check
		. Rename may_ptrace_ns to ptrace_capable
		. Also fix the cap_ptrace checks.
	Jan  1: Use const cred struct
	Jan 11: use task_ns_capable() in place of ptrace_capable().
	Feb 23: same_or_ancestore_user_ns() was not an appropriate
		check to constrain cap_issubset.  Rather, cap_issubset()
		only is meaningful when both capsets are in the same
		user_ns.

Signed-off-by: Serge E. Hallyn 
Cc: "Eric W. Biederman" 
Acked-by: Daniel Lezcano 
Acked-by: David Howells 
Cc: James Morris 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

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