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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the apparmor tree got a conflict in:

  security/apparmor/lsm.c

between commit:

  3c3bda37ca1d ("AppArmor: Add selfattr hooks")

from the security tree and commits:

  bd7bd201ca46 ("apparmor: combine common_audit_data and apparmor_audit_data")
  d20f5a1a6e79 ("apparmor: rename audit_data->label to audit_data->subj_label")

from the apparmor tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc security/apparmor/lsm.c
index 5e16c03936b9,4d34180e9799..000000000000
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@@ -771,16 -868,11 +917,16 @@@ out
  	return error;
  
  fail:
- 	aad(&sa)->label = begin_current_label_crit_section();
+ 	ad.subj_label = begin_current_label_crit_section();
 -	ad.info = name;
 +	if (attr == LSM_ATTR_CURRENT)
- 		aad(&sa)->info = "current";
++		ad.info = "current";
 +	else if (attr == LSM_ATTR_EXEC)
- 		aad(&sa)->info = "exec";
++		ad.info = "exec";
 +	else
- 		aad(&sa)->info = "invalid";
- 	aad(&sa)->error = error = -EINVAL;
- 	aa_audit_msg(AUDIT_APPARMOR_DENIED, &sa, NULL);
- 	end_current_label_crit_section(aad(&sa)->label);
++		ad.info = "invalid";
+ 	ad.error = error = -EINVAL;
+ 	aa_audit_msg(AUDIT_APPARMOR_DENIED, &ad, NULL);
+ 	end_current_label_crit_section(ad.subj_label);
  	goto out;
  }
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Paul Moore]

On Thu, Oct 26, 2023 at 10:03 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the apparmor tree got a conflict in:
>
>   security/apparmor/lsm.c
>
> between commit:
>
>   3c3bda37ca1d ("AppArmor: Add selfattr hooks")
>
> from the security tree and commits:
>
>   bd7bd201ca46 ("apparmor: combine common_audit_data and apparmor_audit_data")
>   d20f5a1a6e79 ("apparmor: rename audit_data->label to audit_data->subj_label")
>
> from the apparmor tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks Stephen.

John, can you take a look and make sure this is correct (it looks okay to me)?

> diff --cc security/apparmor/lsm.c
> index 5e16c03936b9,4d34180e9799..000000000000
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@@ -771,16 -868,11 +917,16 @@@ out
>         return error;
>
>   fail:
> -       aad(&sa)->label = begin_current_label_crit_section();
> +       ad.subj_label = begin_current_label_crit_section();
>  -      ad.info = name;
>  +      if (attr == LSM_ATTR_CURRENT)
> -               aad(&sa)->info = "current";
> ++              ad.info = "current";
>  +      else if (attr == LSM_ATTR_EXEC)
> -               aad(&sa)->info = "exec";
> ++              ad.info = "exec";
>  +      else
> -               aad(&sa)->info = "invalid";
> -       aad(&sa)->error = error = -EINVAL;
> -       aa_audit_msg(AUDIT_APPARMOR_DENIED, &sa, NULL);
> -       end_current_label_crit_section(aad(&sa)->label);
> ++              ad.info = "invalid";
> +       ad.error = error = -EINVAL;
> +       aa_audit_msg(AUDIT_APPARMOR_DENIED, &ad, NULL);
> +       end_current_label_crit_section(ad.subj_label);
>         goto out;
>   }

-- 
paul-moore.com

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

[John Johansen]

On 10/28/23 08:32, Paul Moore wrote:
> On Thu, Oct 26, 2023 at 10:03 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Hi all,
>>
>> Today's linux-next merge of the apparmor tree got a conflict in:
>>
>>    security/apparmor/lsm.c
>>
>> between commit:
>>
>>    3c3bda37ca1d ("AppArmor: Add selfattr hooks")
>>
>> from the security tree and commits:
>>
>>    bd7bd201ca46 ("apparmor: combine common_audit_data and apparmor_audit_data")
>>    d20f5a1a6e79 ("apparmor: rename audit_data->label to audit_data->subj_label")
>>
>> from the apparmor tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
> 
> Thanks Stephen.
> 
> John, can you take a look and make sure this is correct (it looks okay to me)?
> 
yes its good, thanks Stephan.

Acked-by: John Johansen <john.johansen@canonical.com>

Paul just to double check, to make sure we get ordering on this right
    3c3bda37ca1d ("AppArmor: Add selfattr hooks")

is part of the Three basic syscalls series, the plan is still to have that
series bake in next for a full cycle?

Regardless, I will wait until security-ext gets merged to send my pull
request, and handle the conflict if its present.

>> diff --cc security/apparmor/lsm.c
>> index 5e16c03936b9,4d34180e9799..000000000000
>> --- a/security/apparmor/lsm.c
>> +++ b/security/apparmor/lsm.c
>> @@@ -771,16 -868,11 +917,16 @@@ out
>>          return error;
>>
>>    fail:
>> -       aad(&sa)->label = begin_current_label_crit_section();
>> +       ad.subj_label = begin_current_label_crit_section();
>>   -      ad.info = name;
>>   +      if (attr == LSM_ATTR_CURRENT)
>> -               aad(&sa)->info = "current";
>> ++              ad.info = "current";
>>   +      else if (attr == LSM_ATTR_EXEC)
>> -               aad(&sa)->info = "exec";
>> ++              ad.info = "exec";
>>   +      else
>> -               aad(&sa)->info = "invalid";
>> -       aad(&sa)->error = error = -EINVAL;
>> -       aa_audit_msg(AUDIT_APPARMOR_DENIED, &sa, NULL);
>> -       end_current_label_crit_section(aad(&sa)->label);
>> ++              ad.info = "invalid";
>> +       ad.error = error = -EINVAL;
>> +       aa_audit_msg(AUDIT_APPARMOR_DENIED, &ad, NULL);
>> +       end_current_label_crit_section(ad.subj_label);
>>          goto out;
>>    }
> 

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

[Paul Moore]

On Sun, Oct 29, 2023 at 5:09 PM John Johansen
<john.johansen@canonical.com> wrote:
> On 10/28/23 08:32, Paul Moore wrote:
> > On Thu, Oct 26, 2023 at 10:03 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> Hi all,
> >>
> >> Today's linux-next merge of the apparmor tree got a conflict in:
> >>
> >>    security/apparmor/lsm.c
> >>
> >> between commit:
> >>
> >>    3c3bda37ca1d ("AppArmor: Add selfattr hooks")
> >>
> >> from the security tree and commits:
> >>
> >>    bd7bd201ca46 ("apparmor: combine common_audit_data and apparmor_audit_data")
> >>    d20f5a1a6e79 ("apparmor: rename audit_data->label to audit_data->subj_label")
> >>
> >> from the apparmor tree.
> >>
> >> I fixed it up (see below) and can carry the fix as necessary. This
> >> is now fixed as far as linux-next is concerned, but any non trivial
> >> conflicts should be mentioned to your upstream maintainer when your tree
> >> is submitted for merging.  You may also want to consider cooperating
> >> with the maintainer of the conflicting tree to minimise any particularly
> >> complex conflicts.
> >
> > Thanks Stephen.
> >
> > John, can you take a look and make sure this is correct (it looks okay to me)?
> >
> yes its good, thanks Stephan.
>
> Acked-by: John Johansen <john.johansen@canonical.com>
>
> Paul just to double check, to make sure we get ordering on this right
>     3c3bda37ca1d ("AppArmor: Add selfattr hooks")
>
> is part of the Three basic syscalls series, the plan is still to have that
> series bake in next for a full cycle?

Yes, that's still the plan.  Once v6.7-rc1 is out I'll rebase the LSM
syscall patches and I expect the vast majority of these conflicts to
disappear, although I'm sure we'll pick up some new ones with the rest
of the v6.7-rcX cycle :)

-- 
paul-moore.com

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

[Stephen Rothwell]

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

Hi Paul,

On Mon, 30 Oct 2023 12:52:50 -0400 Paul Moore <paul@paul-moore.com> wrote:
>
> On Sun, Oct 29, 2023 at 5:09 PM John Johansen <john.johansen@canonical.com> wrote:
> >
> > is part of the Three basic syscalls series, the plan is still to have that
> > series bake in next for a full cycle?  
> 
> Yes, that's still the plan.  Once v6.7-rc1 is out I'll rebase the LSM
> syscall patches and I expect the vast majority of these conflicts to
> disappear, although I'm sure we'll pick up some new ones with the rest
> of the v6.7-rcX cycle :)

These patches should not be in linux-next until after v6.7-rc1.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Paul Moore]

On Mon, Oct 30, 2023 at 4:46 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Paul,
>
> On Mon, 30 Oct 2023 12:52:50 -0400 Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Sun, Oct 29, 2023 at 5:09 PM John Johansen <john.johansen@canonical.com> wrote:
> > >
> > > is part of the Three basic syscalls series, the plan is still to have that
> > > series bake in next for a full cycle?
> >
> > Yes, that's still the plan.  Once v6.7-rc1 is out I'll rebase the LSM
> > syscall patches and I expect the vast majority of these conflicts to
> > disappear, although I'm sure we'll pick up some new ones with the rest
> > of the v6.7-rcX cycle :)
>
> These patches should not be in linux-next until after v6.7-rc1.

What if we wanted additional testing beyond the typical?  Do you not
support that?

-- 
paul-moore.com

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

[Stephen Rothwell]

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

Hi Paul,

[Sorry for the slow reply]

On Mon, 30 Oct 2023 17:04:01 -0400 Paul Moore <paul@paul-moore.com> wrote:
>
> On Mon, Oct 30, 2023 at 4:46 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Mon, 30 Oct 2023 12:52:50 -0400 Paul Moore <paul@paul-moore.com> wrote:  
> > >
> > > On Sun, Oct 29, 2023 at 5:09 PM John Johansen <john.johansen@canonical.com> wrote:  
> > > >
> > > > is part of the Three basic syscalls series, the plan is still to have that
> > > > series bake in next for a full cycle?  
> > >
> > > Yes, that's still the plan.  Once v6.7-rc1 is out I'll rebase the LSM
> > > syscall patches and I expect the vast majority of these conflicts to
> > > disappear, although I'm sure we'll pick up some new ones with the rest
> > > of the v6.7-rcX cycle :)  
> >
> > These patches should not be in linux-next until after v6.7-rc1.  
> 
> What if we wanted additional testing beyond the typical?  Do you not
> support that?

No, I try hard not to.  It just complicates things when I and others
have to cope with conflicts and build problems caused by
patches/features destined for next+1 while trying to stabilise the
current/next release.

Sometimes it happens that a feature slips after being added to -next,
but please don't do it deliberately.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Paul Moore]

On Sun, Nov 5, 2023 at 6:14 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Paul,
>
> [Sorry for the slow reply]
>
> On Mon, 30 Oct 2023 17:04:01 -0400 Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Mon, Oct 30, 2023 at 4:46 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > On Mon, 30 Oct 2023 12:52:50 -0400 Paul Moore <paul@paul-moore.com> wrote:
> > > >
> > > > On Sun, Oct 29, 2023 at 5:09 PM John Johansen <john.johansen@canonical.com> wrote:
> > > > >
> > > > > is part of the Three basic syscalls series, the plan is still to have that
> > > > > series bake in next for a full cycle?
> > > >
> > > > Yes, that's still the plan.  Once v6.7-rc1 is out I'll rebase the LSM
> > > > syscall patches and I expect the vast majority of these conflicts to
> > > > disappear, although I'm sure we'll pick up some new ones with the rest
> > > > of the v6.7-rcX cycle :)
> > >
> > > These patches should not be in linux-next until after v6.7-rc1.
> >
> > What if we wanted additional testing beyond the typical?  Do you not
> > support that?
>
> No, I try hard not to.  It just complicates things when I and others
> have to cope with conflicts and build problems caused by
> patches/features destined for next+1 while trying to stabilise the
> current/next release.

The LSM, SELinux, and audit dev-staging branches will no longer flow
into the next branches, and I've reset the current lsm/next branch so
this should not be an issue the next time you pull.

> Sometimes it happens that a feature slips after being added to -next,
> but please don't do it deliberately.

-- 
paul-moore.com

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

[Stephen Rothwell]

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

Hi Paul,

On Sun, 5 Nov 2023 18:36:49 -0500 Paul Moore <paul@paul-moore.com> wrote:
>
> The LSM, SELinux, and audit dev-staging branches will no longer flow
> into the next branches, and I've reset the current lsm/next branch so
> this should not be an issue the next time you pull.

Thanks for that.  It can all come back after the merge window, of course.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

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

Hi all,

On Fri, 27 Oct 2023 13:03:20 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the apparmor tree got a conflict in:
> 
>   security/apparmor/lsm.c
> 
> between commit:
> 
>   3c3bda37ca1d ("AppArmor: Add selfattr hooks")
> 
> from the security tree and commits:
> 
>   bd7bd201ca46 ("apparmor: combine common_audit_data and apparmor_audit_data")
>   d20f5a1a6e79 ("apparmor: rename audit_data->label to audit_data->subj_label")
> 
> from the apparmor tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc security/apparmor/lsm.c
> index 5e16c03936b9,4d34180e9799..000000000000
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@@ -771,16 -868,11 +917,16 @@@ out
>   	return error;
>   
>   fail:
> - 	aad(&sa)->label = begin_current_label_crit_section();
> + 	ad.subj_label = begin_current_label_crit_section();
>  -	ad.info = name;
>  +	if (attr == LSM_ATTR_CURRENT)
> - 		aad(&sa)->info = "current";
> ++		ad.info = "current";
>  +	else if (attr == LSM_ATTR_EXEC)
> - 		aad(&sa)->info = "exec";
> ++		ad.info = "exec";
>  +	else
> - 		aad(&sa)->info = "invalid";
> - 	aad(&sa)->error = error = -EINVAL;
> - 	aa_audit_msg(AUDIT_APPARMOR_DENIED, &sa, NULL);
> - 	end_current_label_crit_section(aad(&sa)->label);
> ++		ad.info = "invalid";
> + 	ad.error = error = -EINVAL;
> + 	aa_audit_msg(AUDIT_APPARMOR_DENIED, &ad, NULL);
> + 	end_current_label_crit_section(ad.subj_label);
>   	goto out;
>   }
>   

This is now a conflict between the security tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the apparmor tree got a conflict in:

  security/apparmor/domain.c

between commit:

  f6fbd8cbf3ed ("lsm,fs: fix vfs_getxattr_alloc() return type and caller error paths")

from the security tree and commit:

  217af7e2f4de ("apparmor: refactor profile rules and attachments")

from the apparmor tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc security/apparmor/domain.c
index 00dc0ec066de,b447bc13ea8e..000000000000
--- a/security/apparmor/domain.c
+++ b/security/apparmor/domain.c
@@@ -308,14 -296,16 +296,15 @@@ static int change_profile_perms(struct 
   * Returns: number of extended attributes that matched, or < 0 on error
   */
  static int aa_xattrs_match(const struct linux_binprm *bprm,
- 			   struct aa_profile *profile, unsigned int state)
+ 			   struct aa_profile *profile, aa_state_t state)
  {
  	int i;
 -	ssize_t size;
  	struct dentry *d;
  	char *value = NULL;
- 	int size, value_size = 0, ret = profile->xattr_count;
+ 	struct aa_attachment *attach = &profile->attach;
 -	int value_size = 0, ret = attach->xattr_count;
++	int size, value_size = 0, ret = attach->xattr_count;
  
- 	if (!bprm || !profile->xattr_count)
+ 	if (!bprm || !attach->xattr_count)
  		return 0;
  	might_sleep();
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Paul Moore]

On Sun, Nov 20, 2022 at 10:27 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the apparmor tree got a conflict in:
>
>   security/apparmor/domain.c
>
> between commit:
>
>   f6fbd8cbf3ed ("lsm,fs: fix vfs_getxattr_alloc() return type and caller error paths")
>
> from the security tree and commit:
>
>   217af7e2f4de ("apparmor: refactor profile rules and attachments")
>
> from the apparmor tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc security/apparmor/domain.c
> index 00dc0ec066de,b447bc13ea8e..000000000000
> --- a/security/apparmor/domain.c
> +++ b/security/apparmor/domain.c
> @@@ -308,14 -296,16 +296,15 @@@ static int change_profile_perms(struct
>    * Returns: number of extended attributes that matched, or < 0 on error
>    */
>   static int aa_xattrs_match(const struct linux_binprm *bprm,
> -                          struct aa_profile *profile, unsigned int state)
> +                          struct aa_profile *profile, aa_state_t state)
>   {
>         int i;
>  -      ssize_t size;
>         struct dentry *d;
>         char *value = NULL;
> -       int size, value_size = 0, ret = profile->xattr_count;
> +       struct aa_attachment *attach = &profile->attach;
>  -      int value_size = 0, ret = attach->xattr_count;
> ++      int size, value_size = 0, ret = attach->xattr_count;
>
> -       if (!bprm || !profile->xattr_count)
> +       if (!bprm || !attach->xattr_count)
>                 return 0;
>         might_sleep();

John's the AppArmor expert, but this looks okay to me.  As a reminder,
the lsm/next commit only changes the type of @size from a ssize_t to
an int type.

-- 
paul-moore.com