linux-kernel - linux-next: manual merge of the akpm with the security tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Apr 2012 15:02:58 +1000
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Andy Lutomirski <luto@...capital.net>,
	Will Drewry <wad@...omium.org>,
	James Morris <jmorris@...ei.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>
Subject: linux-next: manual merge of the akpm with the security tree

Hi Andrew,

Today's linux-next merge of the akpm tree got conflicts in kernel/sys.c
and include/linux/prctl.h between commit 259e5e6c75a9 ("Add PR_{GET,SET}
_NO_NEW_PRIVS to prevent execve from granting privs") from the security
tree and patch "c/r: prctl: add ability to get clear_tid_address" from
the akpm tree.

I fixed them up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au

diff --cc include/linux/prctl.h
index 711e0a3,ecbe30e..0000000
--- a/include/linux/prctl.h
+++ b/include/linux/prctl.h
@@@ -130,19 -130,6 +130,21 @@@
  #define PR_SET_CHILD_SUBREAPER 36
  #define PR_GET_CHILD_SUBREAPER 37
  
 -#define PR_GET_TID_ADDRESS     38
 +/*
 + * If no_new_privs is set, then operations that grant new privileges (i.e.
 + * execve) will either fail or not grant them.  This affects suid/sgid,
 + * file capabilities, and LSMs.
 + *
 + * Operations that merely manipulate or drop existing privileges (setresuid,
 + * capset, etc.) will still work.  Drop those privileges if you want them gone.
 + *
 + * Changing LSM security domain is considered a new privilege.  So, for example,
 + * asking selinux for a specific new context (e.g. with runcon) will result
 + * in execve returning -EPERM.
 + */
 +#define PR_SET_NO_NEW_PRIVS 38
 +#define PR_GET_NO_NEW_PRIVS 39
 +
++#define PR_GET_TID_ADDRESS     40
+ 
  #endif /* _LINUX_PRCTL_H */
diff --cc kernel/sys.c
index 500c885,1d57adf..0000000
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@@ -2082,16 -2092,9 +2092,19 @@@ SYSCALL_DEFINE5(prctl, int, option, uns
  			error = put_user(me->signal->is_child_subreaper,
  					 (int __user *) arg2);
  			break;
 +		case PR_SET_NO_NEW_PRIVS:
 +			if (arg2 != 1 || arg3 || arg4 || arg5)
 +				return -EINVAL;
 +
 +			current->no_new_privs = 1;
 +			break;
 +		case PR_GET_NO_NEW_PRIVS:
 +			if (arg2 || arg3 || arg4 || arg5)
 +				return -EINVAL;
 +			return current->no_new_privs ? 1 : 0;
+ 		case PR_GET_TID_ADDRESS:
+ 			error = prctl_get_tid_address(me, (int __user **)arg2);
+ 			break;
  		default:
  			error = -EINVAL;
  			break;

Content of type "application/pgp-signature" skipped