Bug#1050256: AppArmor breaks locking non-fs Unix sockets
On Sun, 26 May 2024 13:39:07 +0200 Salvatore Bonaccorso wrote: > Hi, > > For those watching this bug: John has prepared backports in his tree, > with both approaches: > > https://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor.git/log/?h=debian-two-patch-1780227 > > and > > https://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor.git/log/?h=debian-backport-1780227 > > (but with the open question which one will be submitted for stable. > From upstream stable point of view probably the two patch backport > approach would be the preferred one). Very nice, thank you! In the meanwhile, I found a way to reliably detecting this and gracefully skipping it in systemd, so debci is now fixed. However, it still results in PrivateNetwork= being quietly disabled, so the backport is still very much needed, as it is a useful security feature. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
Hi, For those watching this bug: John has prepared backports in his tree, with both approaches: https://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor.git/log/?h=debian-two-patch-1780227 and https://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor.git/log/?h=debian-backport-1780227 (but with the open question which one will be submitted for stable. >From upstream stable point of view probably the two patch backport approach would be the preferred one). Regards, Salvatore
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
On Sun, 28 Jan 2024 10:57:03 +0100 Salvatore Bonaccorso
wrote:
> Hi John,
>
> On Sun, Jan 28, 2024 at 12:43:33AM -0800, John Johansen wrote:
> > On 12/30/23 20:24, Mathias Gibbens wrote:
> > > On Sat, 2023-12-30 at 16:44 +0100, Salvatore Bonaccorso wrote:
> > > > John, did you had a chance to work on this backport for 6.1.y
stable
> > > > upstream so we could pick it downstream in Debian in one of the
next
> > > > stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix
apparmor
> > > > mediating locking non-fs unix sockets") does not work, if not
> > > > havinging the work around e2967ede2297 ("apparmor: compute
policydb
> > > > permission on profile load") AFAICS, so that needs a 6.1.y
specific
> > > > backport submitted to sta...@vger.kernel.org ?
> > > >
> > > > I think we could have people from this bug as well providing a
> > > > Tested-by when necessary. I'm not feeling confident enough to
be able
> > > > to provide myself such a patch to sent to stable (and you only
giving
> > > > an Acked-by/Reviewed-by), so if you can help out here with your
> > > > upstream hat on that would be more than appreciated and welcome
:)
> > > >
> > > > Thanks a lot for your work!
> > >
> > > I played around with this a bit the past week as well, and
came to
> > > the same conclusion as Salvatore did that commits e2967ede2297
and
> > > 1cf26c3d2c4c need to be cherry-picked back to the 6.1 stable
tree.
> > >
> > > I've attached the two commits rebased onto 6.1.y as patches to
this
> > > message. Commit e2967ede2297 needed a little bit of touchup to
apply
> > > cleanly, and 1cf26c3d2c4c just needed adjustments for line number
> > > changes. I included some comments at the top of each patch.
> > >
> > > With these two commits cherry-picked on top of the 6.1.69
kernel, I
> > > can boot a bookworm system and successfully start a service
within a
> > > container that utilizes `PrivateNetwork=yes`. Rebooting back into
an
> > > unpatched vanilla 6.1.69 kernel continues to show the problem.
> > >
> > > While I didn't see any immediate issues (ie, `aa-status` and
log
> > > files looked OK), I don't understand the changes in the first
commit
> > > well enough to be confident in sending these patches for
inclusion in
> > > the upstream stable tree on my own.
> > >
> > > Mathias
> >
> > Your backports look good to me, and you can stick my acked-by on
them.
> > The changes are strictly more than necessary for the fix. They are
> > part of a larger change set that is trying to cleanup the runtime
> > code by changing the permission mapping from a runtime operation
> > to something that is done only at policy load/unpack time.
> >
> > The advantage of this approach is that while it is a larger change
> > than strictly necessary. It is backporting patches that are already
> > upstream, keep the code closer and making backports easier.
> >
> > Georgia did a minimal backport fix by keeping the version as part
> > of policy and doing the permission mapping at runtime. I have
> > included that patch below. Its advantage is it is a minimal
> > change to fix the issue.
> >
> > I am happy with either version going into stable. Do you want to
> > send them or do you want me to do it?
> Thanks a lot, that is *really* much appreicated!
>
> if you can send them that would be great, because think then they
> come
> directly from you, the trust from Greg or Sasha is higher. otherwise
> I
> think they will then explicitly want an ack on that submission thread
> from you (or pointing to this Debian downstream bug).
>
> Greg will probably want the backport apporach of the two commits if
> it
> feasible and we do not expect regression from it. But you are
> definitively in a better position to judge this :)
>
> Thanks again!
>
> Regards,
> Salvatore
>
> p.s.: feel free to CC us as well in the upstream stable submission.
Hi John,
Is there any update on this? As far as I am aware this patch has not
been sent for backporting yet, so apparmor in 6.1 is still borken, and
the CI still fails because of it.
Is there any chance you could please take care of that, so that we can
finally fix this issue?
Thanks!
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
Hi John,
On Sun, Jan 28, 2024 at 12:43:33AM -0800, John Johansen wrote:
> On 12/30/23 20:24, Mathias Gibbens wrote:
> > On Sat, 2023-12-30 at 16:44 +0100, Salvatore Bonaccorso wrote:
> > > John, did you had a chance to work on this backport for 6.1.y stable
> > > upstream so we could pick it downstream in Debian in one of the next
> > > stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix apparmor
> > > mediating locking non-fs unix sockets") does not work, if not
> > > havinging the work around e2967ede2297 ("apparmor: compute policydb
> > > permission on profile load") AFAICS, so that needs a 6.1.y specific
> > > backport submitted to sta...@vger.kernel.org ?
> > >
> > > I think we could have people from this bug as well providing a
> > > Tested-by when necessary. I'm not feeling confident enough to be able
> > > to provide myself such a patch to sent to stable (and you only giving
> > > an Acked-by/Reviewed-by), so if you can help out here with your
> > > upstream hat on that would be more than appreciated and welcome :)
> > >
> > > Thanks a lot for your work!
> >
> >I played around with this a bit the past week as well, and came to
> > the same conclusion as Salvatore did that commits e2967ede2297 and
> > 1cf26c3d2c4c need to be cherry-picked back to the 6.1 stable tree.
> >
> >I've attached the two commits rebased onto 6.1.y as patches to this
> > message. Commit e2967ede2297 needed a little bit of touchup to apply
> > cleanly, and 1cf26c3d2c4c just needed adjustments for line number
> > changes. I included some comments at the top of each patch.
> >
> >With these two commits cherry-picked on top of the 6.1.69 kernel, I
> > can boot a bookworm system and successfully start a service within a
> > container that utilizes `PrivateNetwork=yes`. Rebooting back into an
> > unpatched vanilla 6.1.69 kernel continues to show the problem.
> >
> >While I didn't see any immediate issues (ie, `aa-status` and log
> > files looked OK), I don't understand the changes in the first commit
> > well enough to be confident in sending these patches for inclusion in
> > the upstream stable tree on my own.
> >
> > Mathias
>
> Your backports look good to me, and you can stick my acked-by on them.
> The changes are strictly more than necessary for the fix. They are
> part of a larger change set that is trying to cleanup the runtime
> code by changing the permission mapping from a runtime operation
> to something that is done only at policy load/unpack time.
>
> The advantage of this approach is that while it is a larger change
> than strictly necessary. It is backporting patches that are already
> upstream, keep the code closer and making backports easier.
>
> Georgia did a minimal backport fix by keeping the version as part
> of policy and doing the permission mapping at runtime. I have
> included that patch below. Its advantage is it is a minimal
> change to fix the issue.
>
> I am happy with either version going into stable. Do you want to
> send them or do you want me to do it?
>
> Acked-by: John Johansen
Thanks a lot, that is *really* much appreicated!
if you can send them that would be great, because think then they come
directly from you, the trust from Greg or Sasha is higher. otherwise I
think they will then explicitly want an ack on that submission thread
from you (or pointing to this Debian downstream bug).
Greg will probably want the backport apporach of the two commits if it
feasible and we do not expect regression from it. But you are
definitively in a better position to judge this :)
Thanks again!
Regards,
Salvatore
p.s.: feel free to CC us as well in the upstream stable submission.
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
On 12/30/23 20:24, Mathias Gibbens wrote:
On Sat, 2023-12-30 at 16:44 +0100, Salvatore Bonaccorso wrote:
John, did you had a chance to work on this backport for 6.1.y stable
upstream so we could pick it downstream in Debian in one of the next
stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix apparmor
mediating locking non-fs unix sockets") does not work, if not
havinging the work around e2967ede2297 ("apparmor: compute policydb
permission on profile load") AFAICS, so that needs a 6.1.y specific
backport submitted to sta...@vger.kernel.org ?
I think we could have people from this bug as well providing a
Tested-by when necessary. I'm not feeling confident enough to be able
to provide myself such a patch to sent to stable (and you only giving
an Acked-by/Reviewed-by), so if you can help out here with your
upstream hat on that would be more than appreciated and welcome :)
Thanks a lot for your work!
I played around with this a bit the past week as well, and came to
the same conclusion as Salvatore did that commits e2967ede2297 and
1cf26c3d2c4c need to be cherry-picked back to the 6.1 stable tree.
I've attached the two commits rebased onto 6.1.y as patches to this
message. Commit e2967ede2297 needed a little bit of touchup to apply
cleanly, and 1cf26c3d2c4c just needed adjustments for line number
changes. I included some comments at the top of each patch.
With these two commits cherry-picked on top of the 6.1.69 kernel, I
can boot a bookworm system and successfully start a service within a
container that utilizes `PrivateNetwork=yes`. Rebooting back into an
unpatched vanilla 6.1.69 kernel continues to show the problem.
While I didn't see any immediate issues (ie, `aa-status` and log
files looked OK), I don't understand the changes in the first commit
well enough to be confident in sending these patches for inclusion in
the upstream stable tree on my own.
Mathias
Your backports look good to me, and you can stick my acked-by on them.
The changes are strictly more than necessary for the fix. They are
part of a larger change set that is trying to cleanup the runtime
code by changing the permission mapping from a runtime operation
to something that is done only at policy load/unpack time.
The advantage of this approach is that while it is a larger change
than strictly necessary. It is backporting patches that are already
upstream, keep the code closer and making backports easier.
Georgia did a minimal backport fix by keeping the version as part
of policy and doing the permission mapping at runtime. I have
included that patch below. Its advantage is it is a minimal
change to fix the issue.
I am happy with either version going into stable. Do you want to
send them or do you want me to do it?
Acked-by: John Johansen
From d716d8e6e8b6dc2fa1db2e72ee95c721aef12064 Mon Sep 17 00:00:00 2001
From: Georgia Garcia
Date: Tue, 9 Jan 2024 17:54:52 -0300
Subject: [PATCH] apparmor: backport fix apparmor mediating locking non-fs,
unix sockets
This is a minimal backport of
1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets
instead of pulling in the dependency patch
e2967ede2297 apparmor: compute policydb permission on profile load
which moves the permission mapping to unpack time. We push the version
information into the profile so the permission mapping fix can be
done in the run time aa_compute_perms() instead of the load time
equivalent in compute_perms_entry() introduced by e2967ede2297.
Signed-off-by: Georgia Garcia
Acked-by: John Johansen
---
security/apparmor/apparmorfs.c | 3 ++-
security/apparmor/include/perms.h | 2 +-
security/apparmor/include/policy.h | 12
security/apparmor/label.c | 9 ++---
security/apparmor/lib.c| 4 +++-
security/apparmor/net.c| 3 ++-
security/apparmor/policy_unpack.c | 11 +--
7 files changed, 27 insertions(+), 17 deletions(-)
diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c
index 7160e7aa58b9..8131c9345900 100644
--- a/security/apparmor/apparmorfs.c
+++ b/security/apparmor/apparmorfs.c
@@ -633,7 +633,8 @@ static void profile_query_cb(struct aa_profile *profile, struct aa_perms *perms,
state = aa_dfa_match_len(dfa, profile->policy.start[0],
match_str, match_len);
if (state)
- aa_compute_perms(dfa, state, );
+ aa_compute_perms(dfa, state, ,
+ profile->policy.version);
}
aa_apply_modes_to_perms(profile, );
aa_perms_accum_raw(perms, );
diff --git a/security/apparmor/include/perms.h b/security/apparmor/include/perms.h
index 13f20c598448..7d5c0c004978 100644
--- a/security/apparmor/include/perms.h
+++ b/security/apparmor/include/perms.h
@@ -142,7 +142,7 @@ void aa_audit_perm_mask(struct audit_buffer *ab, u32 mask, const char *chrs,
void aa_apply_modes_to_perms(struct aa_profile *profile,
struct aa_perms *perms);
void aa_compute_perms(struct aa_dfa *dfa, unsigned int state,
- struct aa_perms
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
On 1/27/24 01:21, Salvatore Bonaccorso wrote:
Hi John,
On Sun, Dec 31, 2023 at 04:24:47AM +, Mathias Gibbens wrote:
On Sat, 2023-12-30 at 16:44 +0100, Salvatore Bonaccorso wrote:
John, did you had a chance to work on this backport for 6.1.y stable
upstream so we could pick it downstream in Debian in one of the next
stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix apparmor
mediating locking non-fs unix sockets") does not work, if not
havinging the work around e2967ede2297 ("apparmor: compute policydb
permission on profile load") AFAICS, so that needs a 6.1.y specific
backport submitted to sta...@vger.kernel.org ?
I think we could have people from this bug as well providing a
Tested-by when necessary. I'm not feeling confident enough to be able
to provide myself such a patch to sent to stable (and you only giving
an Acked-by/Reviewed-by), so if you can help out here with your
upstream hat on that would be more than appreciated and welcome :)
Thanks a lot for your work!
I played around with this a bit the past week as well, and came to
the same conclusion as Salvatore did that commits e2967ede2297 and
1cf26c3d2c4c need to be cherry-picked back to the 6.1 stable tree.
I've attached the two commits rebased onto 6.1.y as patches to this
message. Commit e2967ede2297 needed a little bit of touchup to apply
cleanly, and 1cf26c3d2c4c just needed adjustments for line number
changes. I included some comments at the top of each patch.
With these two commits cherry-picked on top of the 6.1.69 kernel, I
can boot a bookworm system and successfully start a service within a
container that utilizes `PrivateNetwork=yes`. Rebooting back into an
unpatched vanilla 6.1.69 kernel continues to show the problem.
While I didn't see any immediate issues (ie, `aa-status` and log
files looked OK), I don't understand the changes in the first commit
well enough to be confident in sending these patches for inclusion in
the upstream stable tree on my own.
Do you had a chance to look at this for 6.1.y upstream?
Asking/Poking since the point release dates are now clear:
https://lists.debian.org/debian-security/2024/01/msg5.html
if possible I would like to include those fixes, but only if they are
at least queued fror 6.1.y itself to not diverge from upstream.
Otherwise we will wait another round, but which means usually 2 months
for the point release cadence.
I am looking at it right now, I should be done with it today
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
Hi John,
On Sun, Dec 31, 2023 at 04:24:47AM +, Mathias Gibbens wrote:
> On Sat, 2023-12-30 at 16:44 +0100, Salvatore Bonaccorso wrote:
> > John, did you had a chance to work on this backport for 6.1.y stable
> > upstream so we could pick it downstream in Debian in one of the next
> > stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix apparmor
> > mediating locking non-fs unix sockets") does not work, if not
> > havinging the work around e2967ede2297 ("apparmor: compute policydb
> > permission on profile load") AFAICS, so that needs a 6.1.y specific
> > backport submitted to sta...@vger.kernel.org ?
> >
> > I think we could have people from this bug as well providing a
> > Tested-by when necessary. I'm not feeling confident enough to be able
> > to provide myself such a patch to sent to stable (and you only giving
> > an Acked-by/Reviewed-by), so if you can help out here with your
> > upstream hat on that would be more than appreciated and welcome :)
> >
> > Thanks a lot for your work!
>
> I played around with this a bit the past week as well, and came to
> the same conclusion as Salvatore did that commits e2967ede2297 and
> 1cf26c3d2c4c need to be cherry-picked back to the 6.1 stable tree.
>
> I've attached the two commits rebased onto 6.1.y as patches to this
> message. Commit e2967ede2297 needed a little bit of touchup to apply
> cleanly, and 1cf26c3d2c4c just needed adjustments for line number
> changes. I included some comments at the top of each patch.
>
> With these two commits cherry-picked on top of the 6.1.69 kernel, I
> can boot a bookworm system and successfully start a service within a
> container that utilizes `PrivateNetwork=yes`. Rebooting back into an
> unpatched vanilla 6.1.69 kernel continues to show the problem.
>
> While I didn't see any immediate issues (ie, `aa-status` and log
> files looked OK), I don't understand the changes in the first commit
> well enough to be confident in sending these patches for inclusion in
> the upstream stable tree on my own.
Do you had a chance to look at this for 6.1.y upstream?
Asking/Poking since the point release dates are now clear:
https://lists.debian.org/debian-security/2024/01/msg5.html
if possible I would like to include those fixes, but only if they are
at least queued fror 6.1.y itself to not diverge from upstream.
Otherwise we will wait another round, but which means usually 2 months
for the point release cadence.
Regards,
Salvatore
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
On Sat, 2023-12-30 at 16:44 +0100, Salvatore Bonaccorso wrote:
> John, did you had a chance to work on this backport for 6.1.y stable
> upstream so we could pick it downstream in Debian in one of the next
> stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix apparmor
> mediating locking non-fs unix sockets") does not work, if not
> havinging the work around e2967ede2297 ("apparmor: compute policydb
> permission on profile load") AFAICS, so that needs a 6.1.y specific
> backport submitted to sta...@vger.kernel.org ?
>
> I think we could have people from this bug as well providing a
> Tested-by when necessary. I'm not feeling confident enough to be able
> to provide myself such a patch to sent to stable (and you only giving
> an Acked-by/Reviewed-by), so if you can help out here with your
> upstream hat on that would be more than appreciated and welcome :)
>
> Thanks a lot for your work!
I played around with this a bit the past week as well, and came to
the same conclusion as Salvatore did that commits e2967ede2297 and
1cf26c3d2c4c need to be cherry-picked back to the 6.1 stable tree.
I've attached the two commits rebased onto 6.1.y as patches to this
message. Commit e2967ede2297 needed a little bit of touchup to apply
cleanly, and 1cf26c3d2c4c just needed adjustments for line number
changes. I included some comments at the top of each patch.
With these two commits cherry-picked on top of the 6.1.69 kernel, I
can boot a bookworm system and successfully start a service within a
container that utilizes `PrivateNetwork=yes`. Rebooting back into an
unpatched vanilla 6.1.69 kernel continues to show the problem.
While I didn't see any immediate issues (ie, `aa-status` and log
files looked OK), I don't understand the changes in the first commit
well enough to be confident in sending these patches for inclusion in
the upstream stable tree on my own.
Mathias
This is a rebase of commit e2967ede2297 ("apparmor: compute policydb permission
on profile load") onto the 6.1.69 kernel release.
The original commit had a line that changed `kvzalloc()` -> `kvcalloc()` in
security/apparmor/policy_unpack.c, but that code doesn't appear in the 6.1 tree,
so I dropped it.
Also included is the one-line declaration of `struct aa_perms default_perms` in
security/apparmor/file.c which was introduced in commit 408d53e923bd ("apparmor:
compute file permissions on profile load").
Tested-by: Mathias Gibbens
diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c
index 7160e7aa5..aaba936e1 100644
--- a/security/apparmor/apparmorfs.c
+++ b/security/apparmor/apparmorfs.c
@@ -633,7 +633,7 @@ static void profile_query_cb(struct aa_profile *profile, struct aa_perms *perms,
state = aa_dfa_match_len(dfa, profile->policy.start[0],
match_str, match_len);
if (state)
- aa_compute_perms(dfa, state, );
+ tmp = *aa_lookup_perms(profile->policy.perms, state);
}
aa_apply_modes_to_perms(profile, );
aa_perms_accum_raw(perms, );
diff --git a/security/apparmor/file.c b/security/apparmor/file.c
index e1b7e9360..8cf610a22 100644
--- a/security/apparmor/file.c
+++ b/security/apparmor/file.c
@@ -212,6 +212,7 @@ static u32 map_old_perms(u32 old)
*
* Returns: computed permission set
*/
+struct aa_perms default_perms = {};
struct aa_perms aa_compute_fperms(struct aa_dfa *dfa, unsigned int state,
struct path_cond *cond)
{
diff --git a/security/apparmor/include/perms.h b/security/apparmor/include/perms.h
index 13f20c598..de9631edb 100644
--- a/security/apparmor/include/perms.h
+++ b/security/apparmor/include/perms.h
@@ -133,6 +133,17 @@ extern struct aa_perms allperms;
xcheck(fn_for_each((L1), (P), (FN1)), fn_for_each((L2), (P), (FN2)))
+extern struct aa_perms default_perms;
+
+static inline struct aa_perms *aa_lookup_perms(struct aa_perms *perms,
+ unsigned int state)
+{
+ if (!(perms))
+ return _perms;
+
+ return &(perms[state]);
+}
+
void aa_perm_mask_to_str(char *str, size_t str_size, const char *chrs,
u32 mask);
void aa_audit_perm_names(struct audit_buffer *ab, const char * const *names,
@@ -141,8 +152,6 @@ void aa_audit_perm_mask(struct audit_buffer *ab, u32 mask, const char *chrs,
u32 chrsmask, const char * const *names, u32 namesmask);
void aa_apply_modes_to_perms(struct aa_profile *profile,
struct aa_perms *perms);
-void aa_compute_perms(struct aa_dfa *dfa, unsigned int state,
- struct aa_perms *perms);
void aa_perms_accum(struct aa_perms *accum, struct aa_perms *addend);
void aa_perms_accum_raw(struct aa_perms *accum, struct aa_perms *addend);
void aa_profile_match_label(struct aa_profile *profile, struct aa_label *label,
diff --git a/security/apparmor/include/policy.h b/security/apparmor/include/policy.h
index 639b5b248..230ef5007 100644
--- a/security/apparmor/include/policy.h
+++ b/security/apparmor/include/policy.h
@@ -77,6 +77,7 @@ enum profile_mode {
struct aa_policydb {
/* Generic policy DFA specific rule types will
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
Hi John,
On Wed, Dec 06, 2023 at 10:47:45PM +0100, Salvatore Bonaccorso wrote:
> Hi Paul,
>
> On Wed, Dec 06, 2023 at 10:21:02PM +0100, Paul Gevers wrote:
> > Hi,
> >
> > On Mon, 18 Sep 2023 20:54:17 +0200 Paul Gevers wrote:
> > > On 09-09-2023 13:06, Paul Gevers wrote:
> > > > All ci.d.n workers (except riscv64) now run the kernel from >
> > > bookworm-backports. systemd passes it's autopkgtest again in unstable, >
> > > testing and stable.
> > >
> > > We're having issues [1] with the (backports and) unstable kernel on our
> > > main amd64 host, so we reverted back to the stable kernel for amd64.
> > >
> > > Paul
> > >
> > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052130
> >
> > We're having issues [2] with the backports kernel on arm64 so our arm64,
> > armhf and armel hosts are back to the previous backports (arm64) kernel.
> >
> > I'm slightly wondering if the next point release (on Saturday) will bring us
> > a fixed kernel for this issue? Given that this is the second time in 3
> > months we experience an issue with backports kernels, I think we'll have to
> > revert our hosts back to stable kernels for maintainability reasons.
>
> TTBOMK, a backport of 1cf26c3d2c4c ("apparmor: fix apparmor mediating
> locking non-fs unix sockets") for the 6.1.y stable series has not
> landed yet so it's not included in the 6.1.64-1 update of the upcoming
> point release next weekend.
>
> John, as it was said you are working on having the fix backpored to
> linux-6.1.y, is this still WIP?
John, did you had a chance to work on this backport for 6.1.y stable
upstream so we could pick it downstream in Debian in one of the next
stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix apparmor
mediating locking non-fs unix sockets") does not work, if not
havinging the work around e2967ede2297 ("apparmor: compute policydb
permission on profile load") AFAICS, so that needs a 6.1.y specific
backport submitted to sta...@vger.kernel.org ?
I think we could have people from this bug as well providing a
Tested-by when necessary. I'm not feeling confident enough to be able
to provide myself such a patch to sent to stable (and you only giving
an Acked-by/Reviewed-by), so if you can help out here with your
upstream hat on that would be more than appreciated and welcome :)
Thanks a lot for your work!
Regards,
Salvatore
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
Hi Paul,
On Wed, Dec 06, 2023 at 10:21:02PM +0100, Paul Gevers wrote:
> Hi,
>
> On Mon, 18 Sep 2023 20:54:17 +0200 Paul Gevers wrote:
> > On 09-09-2023 13:06, Paul Gevers wrote:
> > > All ci.d.n workers (except riscv64) now run the kernel from >
> > bookworm-backports. systemd passes it's autopkgtest again in unstable, >
> > testing and stable.
> >
> > We're having issues [1] with the (backports and) unstable kernel on our
> > main amd64 host, so we reverted back to the stable kernel for amd64.
> >
> > Paul
> >
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052130
>
> We're having issues [2] with the backports kernel on arm64 so our arm64,
> armhf and armel hosts are back to the previous backports (arm64) kernel.
>
> I'm slightly wondering if the next point release (on Saturday) will bring us
> a fixed kernel for this issue? Given that this is the second time in 3
> months we experience an issue with backports kernels, I think we'll have to
> revert our hosts back to stable kernels for maintainability reasons.
TTBOMK, a backport of 1cf26c3d2c4c ("apparmor: fix apparmor mediating
locking non-fs unix sockets") for the 6.1.y stable series has not
landed yet so it's not included in the 6.1.64-1 update of the upcoming
point release next weekend.
John, as it was said you are working on having the fix backpored to
linux-6.1.y, is this still WIP?
Regards,
Salvatore
Bug#1050256: AppArmor breaks locking non-fs Unix sockets
Hi, On Mon, 18 Sep 2023 20:54:17 +0200 Paul Gevers wrote: On 09-09-2023 13:06, Paul Gevers wrote: > All ci.d.n workers (except riscv64) now run the kernel from > bookworm-backports. systemd passes it's autopkgtest again in unstable, > testing and stable. We're having issues [1] with the (backports and) unstable kernel on our main amd64 host, so we reverted back to the stable kernel for amd64. Paul [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052130 We're having issues [2] with the backports kernel on arm64 so our arm64, armhf and armel hosts are back to the previous backports (arm64) kernel. I'm slightly wondering if the next point release (on Saturday) will bring us a fixed kernel for this issue? Given that this is the second time in 3 months we experience an issue with backports kernels, I think we'll have to revert our hosts back to stable kernels for maintainability reasons. Paul [2] https://bugs.debian.org/1057282 OpenPGP_signature.asc Description: OpenPGP digital signature
