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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

Hi Andrew,

Today's linux-next merge of the scsi-post-merge tree got a conflict in
include/linux/prctl.h between commit 2d514487faf1 ("security: Yama LSM")
from the security tree and commit "prctl: add PR_{SET,GET}
_CHILD_SUBREAPER to allow simple process supervision" from the akpm tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/prctl.h
index 4d0e5bc,b885c85..0000000
--- a/include/linux/prctl.h
+++ b/include/linux/prctl.h
@@@ -114,10 -114,7 +114,13 @@@
  # define PR_SET_MM_START_BRK		6
  # define PR_SET_MM_BRK			7
  
+ #define PR_SET_CHILD_SUBREAPER 35
+ #define PR_GET_CHILD_SUBREAPER 36
+ 
 +/*
 + * Set specific pid that is allowed to ptrace the current task.
 + * A value of 0 mean "no process".
 + */
 +#define PR_SET_PTRACER 0x59616d61
 +
  #endif /* _LINUX_PRCTL_H */

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Cyrill Gorcunov]

On Mon, Apr 16, 2012 at 03:02:58PM +1000, Stephen Rothwell wrote:
> 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.

Thanks, Stephen.

	Cyrill

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]

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@canb.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;

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]