Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Hi Adam & other release managers,

Adam D. Barratt:
> Any news on this?

Yes: the main blocker (in src:linux) has been fixed a few weeks ago
so it's now feasible to make progress on the src:apparmor side.
The next steps are tracked on #879585 that I've kept up-to-date.

> We're likely to be looking at freezing p-u for the next point
> release in a couple of weeks time.

I've been following the Stretch 9.4 scheduling thread with this in
mind. My current plan is to prepare an updated stable p-u around
February 24-25.

Thanks for the ping! :)

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[Adam D. Barratt]

On 2018-01-07 11:23, intrigeri wrote:

Control: tag -1 + moreinfo

The issue in Linux 4.14 with feature set pinning vs. mount operations
was not fixed yet so the 2.11.0-3+deb9u1 package that was accepted in
the proposed-updates stable queue is not suitable for Stretch
currently ⇒ dear release team, feel free to reject or delete it if it
helps you ensure it does not land in the next point release.

Also, after some discussion with Fabian the proposed change was
re-implemented slightly differently in testing/sid; I want to do the
same for the Stretch proposed update ⇒ tagging "moreinfo".


Any news on this? We're likely to be looking at freezing p-u for the 
next point release in a couple of weeks time.


Regards,

Adam

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Control: tag -1 + moreinfo

The issue in Linux 4.14 with feature set pinning vs. mount operations
was not fixed yet so the 2.11.0-3+deb9u1 package that was accepted in
the proposed-updates stable queue is not suitable for Stretch
currently ⇒ dear release team, feel free to reject or delete it if it
helps you ensure it does not land in the next point release.

Also, after some discussion with Fabian the proposed change was
re-implemented slightly differently in testing/sid; I want to do the
same for the Stretch proposed update ⇒ tagging "moreinfo".

I'm not sure if I should remove the "confirmed" and/or "pending" tag
so in doubt I'll leave it to you to do the right thing.

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[Adam D. Barratt]

On Wed, 2017-12-06 at 19:13 +0100, intrigeri wrote:
> intrigeri:
> > At first glance this very much looks like a bug in the custom
> > kernel
> > you're using.
> 
> According to #883703 this bug affects the mainline Linux kernel as
> well so this stretch-pu may break as many use cases at it'll repair
> when running Linux 4.13+ on Stretch :/
> 
> Dear release team, how can we revert this s-p-u? Should I upload
> 2.11.0-3+deb9u2 that reverts to what we had in 2.11.0-3?

I don't think there's a particular need for that currently (and it
wouldn't get accepted until after the point release anyway). We'll ask
ftp-master not to include the package during the point release at the
weekend and in the meantime affected users still have the possibility
to downgrade the package to its current stable version.

Regards,

Adam

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

intrigeri:
> At first glance this very much looks like a bug in the custom kernel
> you're using.

According to #883703 this bug affects the mainline Linux kernel as
well so this stretch-pu may break as many use cases at it'll repair
when running Linux 4.13+ on Stretch :/

Dear release team, how can we revert this s-p-u? Should I upload
2.11.0-3+deb9u2 that reverts to what we had in 2.11.0-3?

I'm very sorry for the mess.

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Hi again Fabian & release team,

Fabian Grünbichler:
> On Wed, Dec 06, 2017 at 03:28:03PM +0100, intrigeri wrote:
>> > it potentially breaks systems using a custom/backports/newer kernel
>> > and AA profiles requiring features not supported by the pinned 4.9
>> > feature set.
>> 
>> In this case, "breaks" == the AppArmor confinement becomes weaker,
>> but the application keeps working.

> not the case for all scenarios unfortunately. LXC containers using the
> upstream profiles (and a kernel supporting the needed features) don't
> start anymore:

> apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 
> profile="/usr/bin/lxc-start" name="/" pid=21550 comm="lxc-start" flags="rw, 
> rslave"

Wow, Assuming you're indeed running with the 4.9 feature set I've
uploaded, that's definitely a bug: the 4.9 feature set is supposed to
fully disable mount mediation, so a mount denial should never happen.
At first glance this very much looks like a bug in the custom kernel
you're using.

If you can reproduce this with a pristine 4.13 or 4.14 Debian kernel,
then I'm very sorry and I agree we should revert this s-p-u until this
kernel bug is fixed in mainline; I'll gladly help you report this bug
upstream. If, however, you can't reproduce this bug with a Debian
kernel, well, then it's a bug in the kernel patches you've applied and
I think we should leave s-p-u as-is.

Possibly helpful: can you please share the content of
/etc/apparmor.d/cache/.features on the system that exposes
this problem?

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[Fabian Grünbichler]

On Wed, Dec 06, 2017 at 03:28:03PM +0100, intrigeri wrote:
> Hi,
> 
> I'll first clarify because it seems to me you're using the same word
> with very different meanings in a comparison:
> 
> Fabian Grünbichler:
> > TL;DR: while pinning the features prevents breakage for people using
> > AA who install a more recent kernel from backports,
> 
> In this case, "breakage" == application stops working after installing
> a newer kernel.
> 
> > it potentially breaks systems using a custom/backports/newer kernel
> > and AA profiles requiring features not supported by the pinned 4.9
> > feature set.
> 
> In this case, "breaks" == the AppArmor confinement becomes weaker,
> but the application keeps working.

not the case for all scenarios unfortunately. LXC containers using the
upstream profiles (and a kernel supporting the needed features) don't
start anymore:

apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 
profile="/usr/bin/lxc-start" name="/" pid=21550 comm="lxc-start" flags="rw, 
rslave"

the profile[1] contains:

mount options=(rw, make-slave) -> **,
mount options=(rw, make-rslave) -> **,

the same profile and container worked fine without feature pinning. this
is not specific to certain container configurations either AFAICT.

> 
> > since
> > both the AA config file itself and the feature set file are conffiles,
> > overriding is not easily possible without conffile modification.
> 
> Right. Sorry I did not think about this Debian derivative use case.
> 

while it is sometimes cumbersome to work around such issues, it is
understandable to not have them on one's radar, especially if the
upstream software does not provide an easy way to extend configuration
files.

> > I'll of course defer to intrigeri and the release team on whether to go
> > ahead as-is, include the patch to allow easier overriding or postpone
> > the apparmor stable update until the next cycle to allow for further
> > discussion.
> 
> I slightly prefer fixing ASAP a non-default use case I want to support
> in Debian (that's what we did in s-p-u already), even if it makes
> a derivative's life slightly harder temporarily when using an much
> more non-default configuration. I would understand if the release team
> prefers to delay this update to a future point release though.
> 

obviously with my downstream hat on, I'd strongly prefer not having to
carry apparmor packages for the remainder of Stretch ;) but if necessary
we will take this route, and work together with upstream and you to get
more easily overridden apparmor config including feature pinning in time
for Buster, hopefully eliminating the need for forked apparmor packages.

> But I can live with both approaches. The vast majority of Stretch
> users are not affected by either of the problems described
> above anyway.

I am glad we noticed it before the point release went live!

1: 
https://github.com/lxc/lxc/blob/d680929bbc07e399ceaf8954c2059bd788905fc7/config/apparmor/abstractions/start-container

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Hi,

I'll first clarify because it seems to me you're using the same word
with very different meanings in a comparison:

Fabian Grünbichler:
> TL;DR: while pinning the features prevents breakage for people using
> AA who install a more recent kernel from backports,

In this case, "breakage" == application stops working after installing
a newer kernel.

> it potentially breaks systems using a custom/backports/newer kernel
> and AA profiles requiring features not supported by the pinned 4.9
> feature set.

In this case, "breaks" == the AppArmor confinement becomes weaker,
but the application keeps working.

> since
> both the AA config file itself and the feature set file are conffiles,
> overriding is not easily possible without conffile modification.

Right. Sorry I did not think about this Debian derivative use case.

> I'll of course defer to intrigeri and the release team on whether to go
> ahead as-is, include the patch to allow easier overriding or postpone
> the apparmor stable update until the next cycle to allow for further
> discussion.

I slightly prefer fixing ASAP a non-default use case I want to support
in Debian (that's what we did in s-p-u already), even if it makes
a derivative's life slightly harder temporarily when using an much
more non-default configuration. I would understand if the release team
prefers to delay this update to a future point release though.

But I can live with both approaches. The vast majority of Stretch
users are not affected by either of the problems described
above anyway.

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[Fabian Grünbichler]

On Sat, Dec 02, 2017 at 07:21:59PM +, Adam D. Barratt wrote:
> Control: tags -1 + pending
> 
> On Sat, 2017-12-02 at 14:37 +0100, intrigeri wrote:
> > Adam D. Barratt:
> > > Please go ahead, bearing in mind that the window for getting fixes
> > > into
> > > the 9.3 point release closes during this weekend.
> > 
> > Thanks, uploaded.
> > 
> 
> Flagged for acceptance.
> 
> Regards,
> 
> Adam
> 

please see #879585 / #882697 for potential fallout caused by this
update.

TL;DR: while pinning the features prevents breakage for people using
AA who install a more recent kernel from backports, it potentially
breaks systems using a custom/backports/newer kernel and AA profiles
requiring features not supported by the pinned 4.9 feature set. since
both the AA config file itself and the feature set file are conffiles,
overriding is not easily possible without conffile modification.

we (a Debian derived hypervisor distribution) are using Debian Stretch
as base, but ship a more recent 4.13-based kernel with full AA support
and LXC with matching AA profiles. pinning the features to those offered
by Stretch's 4.9 kernel would break all user installations using LXC,
and we (as a distribution) could only override this pinning by shipping
our own apparmor packages (which we would like to avoid if possible).

I'll of course defer to intrigeri and the release team on whether to go
ahead as-is, include the patch to allow easier overriding or postpone
the apparmor stable update until the next cycle to allow for further
discussion.

thanks for your time and consideration!

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2017-12-02 at 14:37 +0100, intrigeri wrote:
> Adam D. Barratt:
> > Please go ahead, bearing in mind that the window for getting fixes
> > into
> > the 9.3 point release closes during this weekend.
> 
> Thanks, uploaded.
> 

Flagged for acceptance.

Regards,

Adam

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Adam D. Barratt:
> Please go ahead, bearing in mind that the window for getting fixes into
> the 9.3 point release closes during this weekend.

Thanks, uploaded.

Cheers,
-- 
intrigeri

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2017-11-25 at 20:42 +0100, intrigeri wrote:
> this update avoids breakage for Stretch users who have enabled
> AppArmor and run
> Linux 4.14+ (e.g. from backports once it's there), by pinning the
> AppArmor
> feature set in the kernel to the Stretch kernel's feature set, i.e.
> the feature
> set the AppArmor policy shipped in Stretch supports (it's not ready
> to deal with
> new AppArmor mediation features brought in recent kernels).
> 
> We already have exactly the same thing in current testing/sid, albeit
> with Linux
> 4.13's feature set for now.
> 

Please go ahead, bearing in mind that the window for getting fixes into
the 9.3 point release closes during this weekend.

Regards,

Adam

Bug#882697: stretch-pu: package apparmor/2.11.0-3+deb9u1

[intrigeri]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi!

this update avoids breakage for Stretch users who have enabled AppArmor and run
Linux 4.14+ (e.g. from backports once it's there), by pinning the AppArmor
feature set in the kernel to the Stretch kernel's feature set, i.e. the feature
set the AppArmor policy shipped in Stretch supports (it's not ready to deal with
new AppArmor mediation features brought in recent kernels).

We already have exactly the same thing in current testing/sid, albeit with Linux
4.13's feature set for now.

Cheers!
diff -Nru apparmor-2.11.0/debian/apparmor.install 
apparmor-2.11.0/debian/apparmor.install
--- apparmor-2.11.0/debian/apparmor.install 2017-03-28 12:23:08.0 
+0200
+++ apparmor-2.11.0/debian/apparmor.install 2017-11-25 19:01:04.0 
+0100
@@ -1,4 +1,5 @@
 debian/apport/source_apparmor.py /usr/share/apport/package-hooks/
+debian/features /etc/apparmor/
 debian/lib/apparmor/functions /lib/apparmor/
 debian/lib/apparmor/profile-load /lib/apparmor/
 etc/apparmor/parser.conf
diff -Nru apparmor-2.11.0/debian/changelog apparmor-2.11.0/debian/changelog
--- apparmor-2.11.0/debian/changelog2017-03-28 12:29:15.0 +0200
+++ apparmor-2.11.0/debian/changelog2017-11-25 19:04:05.0 +0100
@@ -1,3 +1,14 @@
+apparmor (2.11.0-3+deb9u1) stretch; urgency=medium
+
+  * Pin the AppArmor feature set to Stretch's kernel (Closes: #879585).
+This ensures Stretch systems, even when running a newer kernel (e.g.
+from backports), have their AppArmor feature set pinned to the one
+supported by the AppArmor policy shipped in Stretch. Otherwise they
+would experience breakage due to new AppArmor mediation features
+introduced in recent kernels.
+
+ -- intrigeri   Sat, 25 Nov 2017 18:04:05 +
+
 apparmor (2.11.0-3) unstable; urgency=medium
 
   * Fix CVE-2017-6507: don't unload unknown profiles during package
diff -Nru apparmor-2.11.0/debian/features apparmor-2.11.0/debian/features
--- apparmor-2.11.0/debian/features 1970-01-01 01:00:00.0 +0100
+++ apparmor-2.11.0/debian/features 2017-11-25 18:55:55.0 +0100
@@ -0,0 +1,23 @@
+caps {mask {chown dac_override dac_read_search fowner fsetid kill setgid 
setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw 
ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct 
sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease 
audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm 
block_suspend audit_read
+}
+}
+rlimit {mask {cpu fsize data stack core rss nproc nofile memlock as locks 
sigpending msgqueue nice rtprio rttime
+}
+}
+capability {0xff
+}
+file {mask {create read write exec append mmap_exec link lock
+}
+}
+domain {change_profile {yes
+}
+change_onexec {yes
+}
+change_hatv {yes
+}
+change_hat {yes
+}
+}
+policy {set_load {yes
+}
+}
diff -Nru apparmor-2.11.0/debian/patches/pin-feature-set.patch 
apparmor-2.11.0/debian/patches/pin-feature-set.patch
--- apparmor-2.11.0/debian/patches/pin-feature-set.patch1970-01-01 
01:00:00.0 +0100
+++ apparmor-2.11.0/debian/patches/pin-feature-set.patch2017-11-25 
18:59:40.0 +0100
@@ -0,0 +1,18 @@
+Description: pin the AppArmor feature set to the one shipped by the apparmor 
package
+ .
+ Let's smooth UX on kernel upgrades and allow ourselves to update the AppArmor
+ policy in a relaxed manner.
+Bug-Debian: https://bugs.debian.org/879585 
+Forwarded: not-needed
+Author: intrigeri 
+
+--- a/parser/parser.conf
 b/parser/parser.conf
+@@ -59,3 +59,7 @@
+ ## Adjust compression
+ #Optimize=compress-small
+ #Optimize=compress-fast
++
++## Pin feature set (avoid regressions when policy is lagging behind
++## the kernel)
++features-file=/etc/apparmor/features
diff -Nru apparmor-2.11.0/debian/patches/series 
apparmor-2.11.0/debian/patches/series
--- apparmor-2.11.0/debian/patches/series   2017-03-28 12:24:44.0 
+0200
+++ apparmor-2.11.0/debian/patches/series   2017-11-25 18:59:40.0 
+0100
@@ -2,6 +2,7 @@
 # Debian-specific patches
 #
 
+pin-feature-set.patch
 notify-group.patch
 
 #