yeah once this lands, LSM stacking is last missing piece to finally be “universal”
the most recent information that i can find on this is: https://lwn.net/Articles/919059 the discussed patchset seems to be merged by now: https://lkml.org/lkml/2023/10/26/1089 there is no sign yet of the “next step” afaict
The changes got pulled into linux-next ; so guess it is available as 6.14-rc1
oh wow that’s sooner than expected, i was looking at this, https://www.reddit.com/r/Ubuntu/comments/zoz5qd/comment/m8866es, expecting it in 6.15 
found this: it appears that it is not yet available in 6.14-rc2 but perhaps the next RC https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/
Yes. Stacking support is currently only mainlined for minor security modules (i.e. not AppArmor/SELinux). I thought Fedora would support running their kernels with AppArmor instead of SELinux like RHEL does (AFAIK choosing the LSMs as a kernel parameter), but it seems Fedora does not. I think the kernel has to be build to allow for that. So, bummer. Maybe I’ll switch to Arch on that machine.
yes, the missing peace to be able to run confined snaps on SELinux systems. Not sure what works out of the box though. Snap vendors its own apparmor, so hopefully there is not much to do.
its there since rc1; search for apparmor in the revision log; its this commit:
That is the correct commit, however look at the date: February 10th
rc2 was cut out on February 9th: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=v6.14-rc2&id=a64dcfb451e254085a7daee5fe51bf22959d52d3
yes snapd vendors apparmor, the challenge is running apparmor on top of SELinux, this does not work currently as far as i know
That is the date of the then-current linux-next, which Stephen Rothwell recreates several times a week. It’s not the date it was merged the first time into linux-next. The important part it is in linux-next at the time 6.14 gets released and there is no indication that won’t happen 
if that’s not enough for you, then here is linus’s tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/
The RC2 tag on here is the same tag as the rc2 tag on the linux-next tree, so if it has been in since rc1, the commit should also be in this tree 
yes this is the important part 
Now i wonder if we can reach out to the solus people to get some positive PR
Note that it isn’t the case that we’re dropping Snap support because we hate snaps, so we’ll gladly reverse on the deprecation decision if it turns out that no patches are needed for strict confinement (and things stay that way).
hm, yes it is not there. and the merge window is closed, so i am not sure it gets into 6.14 sigh
We should not tell the Solus people before it is released (definitly not before it is in linus tree); AFAIU they have nobody/not enough manpower to care about the kernel so it would not speed up anything even in the best case.
hmmm so it might be a 6.15 release after all 
hmmm but given they did do the patches before, and apparently not knowing which patches were actually needed, they likely could take this smaller patch until 6.15
at least we could slow their snap deprecation down hehe
snap deprecation in solus has been delayed:
Tho it appears they may need need help to get it working with the upstream work
Tho it appears they may need need help to get it working with the upstream work
We won’t really need help as long as everything actually makes it into upstream releases. Our patch sets for apparmor and snapd are fairly small and well-maintainable. We just need versions of those that actually result in strict confinement with a ‘vanilla’ Linux kernel.
oh hey good to see you here, i intentionally said “may”. My hope with the post is that a good collaboration will result in an actually working strict confinement with a vanilla Linux kernel.
at the time of writing the patches appear to still live in the next branch: https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=5989af12a3bfa3c86d27e8e409e37ab4c95ac4bf
Looks like it didn’t make it to 6.15 tree. Let’s hope for 6.16 
Commit has changed, new location is this commit.
Yes, at least its getting integration tested by being in linux-next.
On what is happening AppArmor I found some general dev info in https://gitlab.com/apparmor/apparmor/-/issues/510
it seems they are shaping up for a 4.1.0 release (release notes etc WIP…)
Development is currently very active. The next major release will be 5.0 (its possible there will be a minor 4.2 before 5.0 releases). … The goal is to have betas out this fall, and a release by the start of the year.
with these upstream relevant changes marked as “implementations exist and are relatively close to landing, should likely land”:
hmmm
seems it changes often, it is now here
yes, every time Stephen Rothwell is publishing the current version of linux-next (i.e. doing a git rebase) the commit revision will change. So in average every two days.
It might more sense to track the apparmor/kernel-next branch in the apparmor repo, but i do not think that is changing or needs to be changed. Think it is this one, which Stephen Rothwell applies: https://gitlab.com/apparmor/apparmor-kernel/-/commits/apparmor-next?ref_type=HEADS
The January commits are the “original patches”, the February changes are coming from the feedback via linux-next. Everybody is supposed to test against linux next to find integration issues before merging into the release branch.
There is also a “linus-next/linus-next” branch by Sasha Levin which as far as understand tries to merge all the PRs sent to Linus. So if the apparmor changes appear there i think they are slated for the next linux RC/release. ( https://kernel.googlesource.com/pub/scm/linux/kernel/git/sashal/linus-next/+/refs/heads/linus-next ; Tree location “git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linus-next.git linus-next” ; Announcement for linus-next on the kernel list )
nice find, tho looking at git.kernel.org/pub/scm/linux/kernel/git/sashal/linus-next.git linus-next i don’t seem to see tags for 6.14 or 6.15 so it seems its not that straightforward
seems they merge instead of rebase; and maybe manually https://kernel.googlesource.com/pub/scm/linux/kernel/git/sashal/linus-next/+log/refs/heads/linus-next
huh, interesting. i would expect the tags to show up still tho
git tags always mean one “immutable” revision; the revision changes on a rebase (but stays the same with a merge). I agree that merging the released kernel into linus-next should keep the revisions. But maybe they did not copy the tags over. I think i’ll have a look on command line. edit: I checked for 6.15 and the linus-next is lagging behind on tags; but history is as expected
else still waiting, nothing in 6.16 (and nothing in linus-next for 6.17) There was some development on apparmor-next (unrelated to af_unix), this could mean that its getting more important to merge that branch into the kernel and some work on af_unix by amazon (which might mean some destabilization)
