NAK: [X][SRU][PATCH 1/1] UBUNTU: [Config] Enable CONFIG_SECURITY_SELINUX_DISABLE for s390x

[Steve Beattie]

[Sorry for the delay on this]

On Tue, Jul 09, 2019 at 05:02:40PM -0500, Tyler Hicks wrote:
> [+sbeattie]
> 
> On 2019-07-09 13:53:58, Po-Hsu Lin wrote:
> > BugLink: https://bugs.launchpad.net/bugs/1813721
> > 
> > Enable CONFIG_SECURITY_SELINUX_DISABLE for s390x.
> > 
> > Signed-off-by: Po-Hsu Lin <po-hsu.lin at canonical.com>
> > ---
> >  debian.master/config/annotations               | 2 +-
> >  debian.master/config/s390x/config.common.s390x | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/debian.master/config/annotations b/debian.master/config/annotations
> > index adb84bb..3d6015b 100644
> > --- a/debian.master/config/annotations
> > +++ b/debian.master/config/annotations
> > @@ -9864,7 +9864,7 @@ CONFIG_IMA_SIG_TEMPLATE                         policy<{'amd64': 'n', 'arm64': '
> >  CONFIG_SECURITY_SELINUX                         policy<{'amd64': 'y', 'arm64': 'y', 'armhf': 'y', 'i386': 'y', 'powerpc': 'y', 'ppc64el': 'y', 's390x': 'y'}>
> >  CONFIG_SECURITY_SELINUX_BOOTPARAM               policy<{'amd64': 'y', 'arm64': 'y', 'armhf': 'y', 'i386': 'y', 'powerpc': 'y', 'ppc64el': 'y', 's390x': 'n'}>
> >  CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE         policy<{'amd64': '0', 'arm64': '0', 'armhf': '0', 'i386': '0', 'powerpc': '0', 'ppc64el': '0'}>
> > -CONFIG_SECURITY_SELINUX_DISABLE                 policy<{'amd64': 'y', 'arm64': 'y', 'armhf': 'y', 'i386': 'y', 'powerpc': 'y', 'ppc64el': 'y', 's390x': 'n'}>
> > +CONFIG_SECURITY_SELINUX_DISABLE                 policy<{'amd64': 'y', 'arm64': 'y', 'armhf': 'y', 'i386': 'y', 'powerpc': 'y', 'ppc64el': 'y', 's390x': 'y'}>
> 
> Having CONFIG_SECURITY_SELINUX_DISABLE off is the more secure setting.
> The current s390x setting follows the KSPP recommended settings:
> 
>   https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
> 
> In other words, turning it on would weaken security.
> 
> QRT is failing due to the config test added earlier this year:
> 
>   https://git.launchpad.net/qa-regression-testing/commit/?id=8ad898971ba8c1b3be8f237bad277f3888371e6a
> 
> Here's the description from the bug linked to in that QRT test
> (LP: #1680315):
> 
>   In the v4.12 kernel, CONFIG_SECURITY_SELINUX_DISABLE (which allows
>   disabling selinux after boot) will conflict with read-only LSM
>   structures. Since Ubuntu is primarily using AppArmor for its LSM, and
>   SELinux is disabled by default, it makes sense to drop this feature in
>   favor of the protections offered by __ro_after_init markings on the
>   LSM structures.
> 
> The test is a little misguided, IMO, as it shouldn't be failing if
> the config setting is off, regardless of kernel version.
> 
> I think this patch should be NAK'ed and the test should be adjusted. Do
> you agree, Steve?

The ability to make the LSM structures read only after init
was added in the 4.12 cycle (specifically starting with commit
dd0859dccbe291cf8179a96390f5c0e45cb9af1d), which is where the major
security benefit comes from, and is not backported to xenial (and
I am not asking for a backport). I agree that the test before 4.12
should not fail if the config setting is off.

That said, making the kernel config consistent across architectures
would probably be for the best. But I can also see the argument for
leaving the config alone at this point in xenial's lifetime.

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20190716/c3a6f556/attachment.sig>