linux-next: manual merge of the security-testing tree with Linus' tree

linux-next: manual merge of the security-testing tree with Linus' tree

[Stephen Rothwell]

Hi James,

Today's linux-next merge of the security-testing tree got a conflict in
fs/namei.c between commit cb23beb55100171646e69e248fb45f10db6e99a4 ("kill
vfs_permission") from Linus' tree and commit
6146f0d5e47ca4047ffded0fb79b6c25359b386c ("integrity: IMA hooks") from
the security-testing tree.

Just a context change.  I fixed it up (see below) and can carry the fix
for a while.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc fs/namei.c
index bbc15c2,734f2b5..0000000
--- a/fs/namei.c
+++ b/fs/namei.c
@@@ -848,8 -860,9 +849,10 @@@ static int __link_path_walk(const char 
  		nd->flags |= LOOKUP_CONTINUE;
  		err = exec_permission_lite(inode);
  		if (err == -EAGAIN)
 -			err = vfs_permission(nd, MAY_EXEC);
 +			err = inode_permission(nd->path.dentry->d_inode,
 +					       MAY_EXEC);
+ 		if (!err)
+ 			err = ima_path_check(&nd->path, MAY_EXEC);
   		if (err)
  			break;
  
@@@ -1506,9 -1525,14 +1509,14 @@@ int may_open(struct path *path, int acc
  		flag &= ~O_TRUNC;
  	}
  
 -	error = vfs_permission(nd, acc_mode);
 +	error = inode_permission(inode, acc_mode);
  	if (error)
  		return error;
+ 
+ 	error = ima_path_check(&nd->path,
+ 			       acc_mode & (MAY_READ | MAY_WRITE | MAY_EXEC));
+ 	if (error)
+ 		return error;
  	/*
  	 * An append-only file must be opened in append mode for writing.
  	 */

Re: linux-next: manual merge of the security-testing tree with Linus' tree

[James Morris]

On Fri, 6 Feb 2009, Stephen Rothwell wrote:

> Hi James,
> 
> Today's linux-next merge of the security-testing tree got a conflict in
> fs/namei.c between commit cb23beb55100171646e69e248fb45f10db6e99a4 ("kill
> vfs_permission") from Linus' tree and commit
> 6146f0d5e47ca4047ffded0fb79b6c25359b386c ("integrity: IMA hooks") from
> the security-testing tree.
> 
> Just a context change.  I fixed it up (see below) and can carry the fix
> for a while.

It was already fixed in my tree earlier today.

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> diff --cc fs/namei.c
> index bbc15c2,734f2b5..0000000
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@@ -848,8 -860,9 +849,10 @@@ static int __link_path_walk(const char 
>   		nd->flags |= LOOKUP_CONTINUE;
>   		err = exec_permission_lite(inode);
>   		if (err == -EAGAIN)
>  -			err = vfs_permission(nd, MAY_EXEC);
>  +			err = inode_permission(nd->path.dentry->d_inode,
>  +					       MAY_EXEC);
> + 		if (!err)
> + 			err = ima_path_check(&nd->path, MAY_EXEC);
>    		if (err)
>   			break;
>   
> @@@ -1506,9 -1525,14 +1509,14 @@@ int may_open(struct path *path, int acc
>   		flag &= ~O_TRUNC;
>   	}
>   
>  -	error = vfs_permission(nd, acc_mode);
>  +	error = inode_permission(inode, acc_mode);
>   	if (error)
>   		return error;
> + 
> + 	error = ima_path_check(&nd->path,
> + 			       acc_mode & (MAY_READ | MAY_WRITE | MAY_EXEC));
> + 	if (error)
> + 		return error;
>   	/*
>   	 * An append-only file must be opened in append mode for writing.
>   	 */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
James Morris
<jmorris@namei.org>

linux-next: manual merge of the security-testing tree with Linus' tree

[Stephen Rothwell]

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

Hi James,

Today's linux-next merge of the security-testing tree got a conflict in
fs/exec.c between commits a44ddbb6d8a8ffe4e34e417048dfdd8f3dd1de4f ("Make
open_exec() and sys_uselib() use may_open(), instead of duplicating its
parts") and 6e8341a11eb21826b7192d0bb88cb5b44900a9af ("Switch open_exec()
and sys_uselib() to do_open_filp()") from Linus' tree and commit
b9fc745db833bbf74b4988493b8cd902a84c9415 ("integrity: path_check update")
from the security-testing tree.

I used the version of these conflicts from Linus' tree as I assume that
the changes to may_open() from the latter patch are sufficient.  Please
check and let me know (or merge Linus' tree and do the resolution for
yourself :-)).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the security-testing tree with Linus' tree

[Al Viro]

On Fri, May 22, 2009 at 03:29:01PM +1000, Stephen Rothwell wrote:
> Hi James,
> 
> Today's linux-next merge of the security-testing tree got a conflict in
> fs/exec.c between commits a44ddbb6d8a8ffe4e34e417048dfdd8f3dd1de4f ("Make
> open_exec() and sys_uselib() use may_open(), instead of duplicating its
> parts") and 6e8341a11eb21826b7192d0bb88cb5b44900a9af ("Switch open_exec()
> and sys_uselib() to do_open_filp()") from Linus' tree and commit
> b9fc745db833bbf74b4988493b8cd902a84c9415 ("integrity: path_check update")
> from the security-testing tree.
> 
> I used the version of these conflicts from Linus' tree as I assume that
> the changes to may_open() from the latter patch are sufficient.  Please
> check and let me know (or merge Linus' tree and do the resolution for
> yourself :-)).

Just drop their changes to sys_uselib() and open_exec() and keep the
rest of their patch.

Re: linux-next: manual merge of the security-testing tree with Linus' tree

[James Morris]

On Fri, 22 May 2009, Al Viro wrote:

> On Fri, May 22, 2009 at 03:29:01PM +1000, Stephen Rothwell wrote:
> > Hi James,
> > 
> > Today's linux-next merge of the security-testing tree got a conflict in
> > fs/exec.c between commits a44ddbb6d8a8ffe4e34e417048dfdd8f3dd1de4f ("Make
> > open_exec() and sys_uselib() use may_open(), instead of duplicating its
> > parts") and 6e8341a11eb21826b7192d0bb88cb5b44900a9af ("Switch open_exec()
> > and sys_uselib() to do_open_filp()") from Linus' tree and commit
> > b9fc745db833bbf74b4988493b8cd902a84c9415 ("integrity: path_check update")
> > from the security-testing tree.
> > 
> > I used the version of these conflicts from Linus' tree as I assume that
> > the changes to may_open() from the latter patch are sufficient.  Please
> > check and let me know (or merge Linus' tree and do the resolution for
> > yourself :-)).
> 
> Just drop their changes to sys_uselib() and open_exec() and keep the
> rest of their patch.

I've merged Linus' tree into mine and done the above, see fs/exec.c in 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next

(I don't know how to get the conflict resolution diff out of git).


- James
-- 
James Morris
<jmorris@namei.org>

linux-next: manual merge of the security-testing tree with Linus' tree

[Stephen Rothwell]

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

Hi James,

Today's linux-next merge of the security-testing tree got a conflict in
security/keys/keyring.c between commit
cea7daa3589d6b550546a8c8963599f7c1a3ae5c ("KEYS: find_keyring_by_name()
can gain access to a freed keyring") from Linus' tree and commit
c5b60b5e67af8be4c58d3ffcc36894f69c4fbdc1 ("security: whitespace coding
style fixes") from the security-testing tree.

I just used the version from Linus' tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: linux-next: manual merge of the security-testing tree with Linus' tree

[David Howells]

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> I just used the version from Linus' tree.

Okay.

However, I'd like to NAK some bits of c5b60b5e67af8be4c58d3ffcc36894f69c4fbdc1
now that I see it...

	@@ -1282,16 +1282,16 @@ long keyctl_session_to_parent(void)
	 
	        /* the parent must have the same effective ownership and mustn't be
	         * SUID/SGID */
	-       if (pcred-> uid != mycred->euid ||
	+       if (pcred->uid  != mycred->euid ||
	            pcred->euid != mycred->euid ||
	            pcred->suid != mycred->euid ||
	-           pcred-> gid != mycred->egid ||
	+           pcred->gid  != mycred->egid ||
	            pcred->egid != mycred->egid ||
	            pcred->sgid != mycred->egid)
	                goto not_permitted;
	 
	        /* the keyrings must have the same UID */
	-       if (pcred ->tgcred->session_keyring->uid != mycred->euid ||
	+       if (pcred->tgcred->session_keyring->uid != mycred->euid ||
	            mycred->tgcred->session_keyring->uid != mycred->euid)
	                goto not_permitted;

_Please_ don't do either of these.  The whole point is to line stuff up so
that as the eye scans down the lines, it can easily pick out the differences
in stuff that's otherwise greatly repetitive.

David

Re: linux-next: manual merge of the security-testing tree with Linus' tree

[James Morris]

On Thu, 6 May 2010, David Howells wrote:

> 
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > I just used the version from Linus' tree.
> 
> Okay.
> 
> However, I'd like to NAK some bits of c5b60b5e67af8be4c58d3ffcc36894f69c4fbdc1
> now that I see it...

Will a patch -R of below be correct enough for you?  Otherwise, please 
send me a new patch.

(This is one of the reasons why I'm not so keen on whitespace fixes, also 
having to resolve merge conflicts, peturbing the history of the code etc.)


> 
> 	@@ -1282,16 +1282,16 @@ long keyctl_session_to_parent(void)
> 	 
> 	        /* the parent must have the same effective ownership and mustn't be
> 	         * SUID/SGID */
> 	-       if (pcred-> uid != mycred->euid ||
> 	+       if (pcred->uid  != mycred->euid ||
> 	            pcred->euid != mycred->euid ||
> 	            pcred->suid != mycred->euid ||
> 	-           pcred-> gid != mycred->egid ||
> 	+           pcred->gid  != mycred->egid ||
> 	            pcred->egid != mycred->egid ||
> 	            pcred->sgid != mycred->egid)
> 	                goto not_permitted;
> 	 
> 	        /* the keyrings must have the same UID */
> 	-       if (pcred ->tgcred->session_keyring->uid != mycred->euid ||
> 	+       if (pcred->tgcred->session_keyring->uid != mycred->euid ||
> 	            mycred->tgcred->session_keyring->uid != mycred->euid)
> 	                goto not_permitted;
> 
> _Please_ don't do either of these.  The whole point is to line stuff up so
> that as the eye scans down the lines, it can easily pick out the differences
> in stuff that's otherwise greatly repetitive.
> 
> David
> 

-- 
James Morris
<jmorris@namei.org>

Re: linux-next: manual merge of the security-testing tree with Linus' tree

[Justin P. Mattock]

On 05/06/2010 04:10 PM, James Morris wrote:
> On Thu, 6 May 2010, David Howells wrote:
>
>>
>> Stephen Rothwell<sfr@canb.auug.org.au>  wrote:
>>
>>> I just used the version from Linus' tree.
>>
>> Okay.
>>
>> However, I'd like to NAK some bits of c5b60b5e67af8be4c58d3ffcc36894f69c4fbdc1
>> now that I see it...
>
> Will a patch -R of below be correct enough for you?  Otherwise, please
> send me a new patch.
>
> (This is one of the reasons why I'm not so keen on whitespace fixes, also
> having to resolve merge conflicts, peturbing the history of the code etc.)
>
>
>>
>> 	@@ -1282,16 +1282,16 @@ long keyctl_session_to_parent(void)
>> 	
>> 	        /* the parent must have the same effective ownership and mustn't be
>> 	         * SUID/SGID */
>> 	-       if (pcred->  uid != mycred->euid ||
>> 	+       if (pcred->uid  != mycred->euid ||
>> 	            pcred->euid != mycred->euid ||
>> 	            pcred->suid != mycred->euid ||
>> 	-           pcred->  gid != mycred->egid ||
>> 	+           pcred->gid  != mycred->egid ||
>> 	            pcred->egid != mycred->egid ||
>> 	            pcred->sgid != mycred->egid)
>> 	                goto not_permitted;
>> 	
>> 	        /* the keyrings must have the same UID */
>> 	-       if (pcred ->tgcred->session_keyring->uid != mycred->euid ||
>> 	+       if (pcred->tgcred->session_keyring->uid != mycred->euid ||
>> 	            mycred->tgcred->session_keyring->uid != mycred->euid)
>> 	                goto not_permitted;
>>
>> _Please_ don't do either of these.  The whole point is to line stuff up so
>> that as the eye scans down the lines, it can easily pick out the differences
>> in stuff that's otherwise greatly repetitive.
>>
>> David
>>
>

I never would of thought this. So the != has to be lined
up so things don't break?!

Justin P. Mattock

linux-next: manual merge of the security-testing tree with Linus' tree

[Stephen Rothwell]

Hi James,

Today's linux-next merge of the security-testing tree got a conflict in
include/linux/capability.h between commit 47a150edc2ae ("Cache user_ns in
struct cred") from Linus' tree and commit ffa8e59df047 ("capabilities: do
not drop CAP_SETPCAP from the initial task") from the security-testing
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/capability.h
index d4675af,04fed72..0000000
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@@ -546,8 -541,21 +541,10 @@@ extern bool has_capability_noaudit(stru
  extern bool capable(int cap);
  extern bool ns_capable(struct user_namespace *ns, int cap);
  extern bool task_ns_capable(struct task_struct *t, int cap);
 +extern bool nsown_capable(int cap);
  
+ extern const kernel_cap_t __cap_empty_set;
+ 
 -/**
 - * nsown_capable - Check superior capability to one's own user_ns
 - * @cap: The capability in question
 - *
 - * Return true if the current task has the given superior capability
 - * targeted at its own user namespace.
 - */
 -static inline bool nsown_capable(int cap)
 -{
 -	return ns_capable(current_user_ns(), cap);
 -}
 -
  /* audit system wants to get cap info from files as well */
  extern int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps);
  

Re: linux-next: manual merge of the security-testing tree with Linus' tree

[Serge Hallyn]

Hi Stephen,

looking at commit ffa8e59df047, it also adds

+extern const kernel_cap_t __cap_full_set;

under __cap_empty_set.  My trees are a bit screwed up so I'm not sure if
that gets later removed, but I just wanted to make sure you didn't
accidentally drop that.

Otherwise looks good, thanks and sorry for the noise.

thanks,
-serge

Quoting Stephen Rothwell (sfr@canb.auug.org.au):
> Hi James,
> 
> Today's linux-next merge of the security-testing tree got a conflict in
> include/linux/capability.h between commit 47a150edc2ae ("Cache user_ns in
> struct cred") from Linus' tree and commit ffa8e59df047 ("capabilities: do
> not drop CAP_SETPCAP from the initial task") from the security-testing
> 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/capability.h
> index d4675af,04fed72..0000000
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@@ -546,8 -541,21 +541,10 @@@ extern bool has_capability_noaudit(stru
>   extern bool capable(int cap);
>   extern bool ns_capable(struct user_namespace *ns, int cap);
>   extern bool task_ns_capable(struct task_struct *t, int cap);
>  +extern bool nsown_capable(int cap);
>   
> + extern const kernel_cap_t __cap_empty_set;
> + 
>  -/**
>  - * nsown_capable - Check superior capability to one's own user_ns
>  - * @cap: The capability in question
>  - *
>  - * Return true if the current task has the given superior capability
>  - * targeted at its own user namespace.
>  - */
>  -static inline bool nsown_capable(int cap)
>  -{
>  -	return ns_capable(current_user_ns(), cap);
>  -}
>  -
>   /* audit system wants to get cap info from files as well */
>   extern int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps);
>   

Re: linux-next: manual merge of the security-testing tree with Linus' tree

[Stephen Rothwell]

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

Hi Serge,

On Mon, 16 May 2011 09:13:59 -0500 Serge Hallyn <serge.hallyn@canonical.com> wrote:
>
> looking at commit ffa8e59df047, it also adds
> 
> +extern const kernel_cap_t __cap_full_set;
> 
> under __cap_empty_set.  My trees are a bit screwed up so I'm not sure if
> that gets later removed, but I just wanted to make sure you didn't
> accidentally drop that.

Yeah, it got removed in the next commit (5163b583a036  "capabilities:
delete unused cap_set_full"), sorry for not mentioning that.

> Otherwise looks good,

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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