[00/11] Kernel: Improve hardening

  This patchset improves hardening of our Linux kernel configurations for all
architectures. Most importantly, it features the activation of the "Linux
Security Module", also known as "kernel lockdown" (a phrase coined before the
pandemic), or LSM for short.

Being set to "integrity" mode for a start, LSM prevents the kernel from being
modified by various mechanisms, of which we have some already covered. However,
it comes as a more holistic approach, which is why enabling it is desirable
for our userbase.

Most of this patchset is based on recommendations by the "kconfig-hardened-check"
tool (https://github.com/a13xp0p0v/kconfig-hardened-check/), with some inspiration
taken directly from KSPP and grsecurity.

Being unable to cross-compile IPFire for non-x86_64-architectures on my own,
and my VM on the Mustang currently being offline, this patchset does not come
with aligned kernel rootfiles for other architectures than x86_64. I am sorry
for any inconvenience and extra workload caused by this.

Also, for the sake of completeness, the effect of LSM on virtualisation has not
been tested due to time constraints, and a lack of oversight _which_ virtualisation
features we officially support and which we don't. In doubt, however, I believe
the security benefit gained from LSM outweighs a partial functional loss of
virtualisation - but that is a highly biased opinion. :-)

Peter Müller (11):
  Kernel: Set CONFIG_ARCH_MMAP_RND_BITS to 32 bits
  Kernel: Disable support for tracing block I/O actions
  Kernel: Pin loading kernel files to one filesystem
  Kernel: Enable undefined behaviour sanity checker
  Kernel: Gate SETID transitions to limit CAP_SET(G|U)ID capabilities
  Kernel: Enable LSM support and set security level to "integrity"
  Kernel: Trigger BUG if data corruption is detected
  Kernel: Do not automatically load TTY line disciplines, only if
    necessary
  Kernel: Enable SVA support for both Intel and AMD CPUs
  Kernel: Disable function and stack tracers
  Kernel: Update rootfile for x86_64

 config/kernel/kernel.config.aarch64-ipfire | 47 ++++++++++--------
 config/kernel/kernel.config.armv6l-ipfire  | 47 ++++++++++--------
 config/kernel/kernel.config.riscv64-ipfire | 47 ++++++++++--------
 config/kernel/kernel.config.x86_64-ipfire  | 57 ++++++++++++----------
 config/rootfiles/common/x86_64/linux       | 33 +++++++------
 5 files changed, 131 insertions(+), 100 deletions(-)
  

Hello,

I don’t know exactly which patch is responsible for this, but /dev/port is no longer accessible by sensors-detect.

This leads to ugly messages when the system is booting up for the first time. Please see the attached screenshot.

At least the message needs to be silenced, but you should investigate whether sensors will still work and is able to access readings for its hardware sensors.



-Michael

> On 19 Mar 2022, at 21:08, Peter Müller <peter.mueller@ipfire.org> wrote:
> 
> This patchset improves hardening of our Linux kernel configurations for all
> architectures. Most importantly, it features the activation of the "Linux
> Security Module", also known as "kernel lockdown" (a phrase coined before the
> pandemic), or LSM for short.
> 
> Being set to "integrity" mode for a start, LSM prevents the kernel from being
> modified by various mechanisms, of which we have some already covered. However,
> it comes as a more holistic approach, which is why enabling it is desirable
> for our userbase.
> 
> Most of this patchset is based on recommendations by the "kconfig-hardened-check"
> tool (https://github.com/a13xp0p0v/kconfig-hardened-check/), with some inspiration
> taken directly from KSPP and grsecurity.
> 
> Being unable to cross-compile IPFire for non-x86_64-architectures on my own,
> and my VM on the Mustang currently being offline, this patchset does not come
> with aligned kernel rootfiles for other architectures than x86_64. I am sorry
> for any inconvenience and extra workload caused by this.
> 
> Also, for the sake of completeness, the effect of LSM on virtualisation has not
> been tested due to time constraints, and a lack of oversight _which_ virtualisation
> features we officially support and which we don't. In doubt, however, I believe
> the security benefit gained from LSM outweighs a partial functional loss of
> virtualisation - but that is a highly biased opinion. :-)
> 
> Peter Müller (11):
>  Kernel: Set CONFIG_ARCH_MMAP_RND_BITS to 32 bits
>  Kernel: Disable support for tracing block I/O actions
>  Kernel: Pin loading kernel files to one filesystem
>  Kernel: Enable undefined behaviour sanity checker
>  Kernel: Gate SETID transitions to limit CAP_SET(G|U)ID capabilities
>  Kernel: Enable LSM support and set security level to "integrity"
>  Kernel: Trigger BUG if data corruption is detected
>  Kernel: Do not automatically load TTY line disciplines, only if
>    necessary
>  Kernel: Enable SVA support for both Intel and AMD CPUs
>  Kernel: Disable function and stack tracers
>  Kernel: Update rootfile for x86_64
> 
> config/kernel/kernel.config.aarch64-ipfire | 47 ++++++++++--------
> config/kernel/kernel.config.armv6l-ipfire  | 47 ++++++++++--------
> config/kernel/kernel.config.riscv64-ipfire | 47 ++++++++++--------
> config/kernel/kernel.config.x86_64-ipfire  | 57 ++++++++++++----------
> config/rootfiles/common/x86_64/linux       | 33 +++++++------
> 5 files changed, 131 insertions(+), 100 deletions(-)
> 
> -- 
> 2.34.1
  

Hello Michael,

thanks for your e-mail.

This is caused by the kernel lockdown patch, since /dev/ports apparently can be used to alter
the running kernel, hence it is no longer available if LSM runs in "integrity" mode.

On my testing machine, sensors and sensors-detect continue to work, but any sensor that requires
/dev/ports access is no longer available. On my testing hardware, that does not make a difference,
but I presume it will on other hardware with more or different sensors.

sensors-detect does not implement any option to probe non-/dev/ports-sensors only, so I guess
there is nothing we can do besides a "> /dev/null 2>&1". I will change the collectd initscript
to reflect that.

Thanks, and best regards,
Peter Müller


> Hello,
> 
> I don’t know exactly which patch is responsible for this, but /dev/port is no longer accessible by sensors-detect.
> 
> This leads to ugly messages when the system is booting up for the first time. Please see the attached screenshot.
> 
> At least the message needs to be silenced, but you should investigate whether sensors will still work and is able to access readings for its hardware sensors.
> 
> 
> 
> -Michael
> 
>> On 19 Mar 2022, at 21:08, Peter Müller <peter.mueller@ipfire.org> wrote:
>>
>> This patchset improves hardening of our Linux kernel configurations for all
>> architectures. Most importantly, it features the activation of the "Linux
>> Security Module", also known as "kernel lockdown" (a phrase coined before the
>> pandemic), or LSM for short.
>>
>> Being set to "integrity" mode for a start, LSM prevents the kernel from being
>> modified by various mechanisms, of which we have some already covered. However,
>> it comes as a more holistic approach, which is why enabling it is desirable
>> for our userbase.
>>
>> Most of this patchset is based on recommendations by the "kconfig-hardened-check"
>> tool (https://github.com/a13xp0p0v/kconfig-hardened-check/), with some inspiration
>> taken directly from KSPP and grsecurity.
>>
>> Being unable to cross-compile IPFire for non-x86_64-architectures on my own,
>> and my VM on the Mustang currently being offline, this patchset does not come
>> with aligned kernel rootfiles for other architectures than x86_64. I am sorry
>> for any inconvenience and extra workload caused by this.
>>
>> Also, for the sake of completeness, the effect of LSM on virtualisation has not
>> been tested due to time constraints, and a lack of oversight _which_ virtualisation
>> features we officially support and which we don't. In doubt, however, I believe
>> the security benefit gained from LSM outweighs a partial functional loss of
>> virtualisation - but that is a highly biased opinion. :-)
>>
>> Peter Müller (11):
>>  Kernel: Set CONFIG_ARCH_MMAP_RND_BITS to 32 bits
>>  Kernel: Disable support for tracing block I/O actions
>>  Kernel: Pin loading kernel files to one filesystem
>>  Kernel: Enable undefined behaviour sanity checker
>>  Kernel: Gate SETID transitions to limit CAP_SET(G|U)ID capabilities
>>  Kernel: Enable LSM support and set security level to "integrity"
>>  Kernel: Trigger BUG if data corruption is detected
>>  Kernel: Do not automatically load TTY line disciplines, only if
>>    necessary
>>  Kernel: Enable SVA support for both Intel and AMD CPUs
>>  Kernel: Disable function and stack tracers
>>  Kernel: Update rootfile for x86_64
>>
>> config/kernel/kernel.config.aarch64-ipfire | 47 ++++++++++--------
>> config/kernel/kernel.config.armv6l-ipfire  | 47 ++++++++++--------
>> config/kernel/kernel.config.riscv64-ipfire | 47 ++++++++++--------
>> config/kernel/kernel.config.x86_64-ipfire  | 57 ++++++++++++----------
>> config/rootfiles/common/x86_64/linux       | 33 +++++++------
>> 5 files changed, 131 insertions(+), 100 deletions(-)
>>
>> -- 
>> 2.34.1
> 
>
  

Could you please check with Arne how severe this is for the sensors?

> On 13 Apr 2022, at 10:18, Peter Müller <peter.mueller@ipfire.org> wrote:
> 
> Hello Michael,
> 
> thanks for your e-mail.
> 
> This is caused by the kernel lockdown patch, since /dev/ports apparently can be used to alter
> the running kernel, hence it is no longer available if LSM runs in "integrity" mode.
> 
> On my testing machine, sensors and sensors-detect continue to work, but any sensor that requires
> /dev/ports access is no longer available. On my testing hardware, that does not make a difference,
> but I presume it will on other hardware with more or different sensors.
> 
> sensors-detect does not implement any option to probe non-/dev/ports-sensors only, so I guess
> there is nothing we can do besides a "> /dev/null 2>&1". I will change the collectd initscript
> to reflect that.
> 
> Thanks, and best regards,
> Peter Müller
> 
> 
>> Hello,
>> 
>> I don’t know exactly which patch is responsible for this, but /dev/port is no longer accessible by sensors-detect.
>> 
>> This leads to ugly messages when the system is booting up for the first time. Please see the attached screenshot.
>> 
>> At least the message needs to be silenced, but you should investigate whether sensors will still work and is able to access readings for its hardware sensors.
>> 
>> 
>> 
>> -Michael
>> 
>>> On 19 Mar 2022, at 21:08, Peter Müller <peter.mueller@ipfire.org> wrote:
>>> 
>>> This patchset improves hardening of our Linux kernel configurations for all
>>> architectures. Most importantly, it features the activation of the "Linux
>>> Security Module", also known as "kernel lockdown" (a phrase coined before the
>>> pandemic), or LSM for short.
>>> 
>>> Being set to "integrity" mode for a start, LSM prevents the kernel from being
>>> modified by various mechanisms, of which we have some already covered. However,
>>> it comes as a more holistic approach, which is why enabling it is desirable
>>> for our userbase.
>>> 
>>> Most of this patchset is based on recommendations by the "kconfig-hardened-check"
>>> tool (https://github.com/a13xp0p0v/kconfig-hardened-check/), with some inspiration
>>> taken directly from KSPP and grsecurity.
>>> 
>>> Being unable to cross-compile IPFire for non-x86_64-architectures on my own,
>>> and my VM on the Mustang currently being offline, this patchset does not come
>>> with aligned kernel rootfiles for other architectures than x86_64. I am sorry
>>> for any inconvenience and extra workload caused by this.
>>> 
>>> Also, for the sake of completeness, the effect of LSM on virtualisation has not
>>> been tested due to time constraints, and a lack of oversight _which_ virtualisation
>>> features we officially support and which we don't. In doubt, however, I believe
>>> the security benefit gained from LSM outweighs a partial functional loss of
>>> virtualisation - but that is a highly biased opinion. :-)
>>> 
>>> Peter Müller (11):
>>> Kernel: Set CONFIG_ARCH_MMAP_RND_BITS to 32 bits
>>> Kernel: Disable support for tracing block I/O actions
>>> Kernel: Pin loading kernel files to one filesystem
>>> Kernel: Enable undefined behaviour sanity checker
>>> Kernel: Gate SETID transitions to limit CAP_SET(G|U)ID capabilities
>>> Kernel: Enable LSM support and set security level to "integrity"
>>> Kernel: Trigger BUG if data corruption is detected
>>> Kernel: Do not automatically load TTY line disciplines, only if
>>>   necessary
>>> Kernel: Enable SVA support for both Intel and AMD CPUs
>>> Kernel: Disable function and stack tracers
>>> Kernel: Update rootfile for x86_64
>>> 
>>> config/kernel/kernel.config.aarch64-ipfire | 47 ++++++++++--------
>>> config/kernel/kernel.config.armv6l-ipfire  | 47 ++++++++++--------
>>> config/kernel/kernel.config.riscv64-ipfire | 47 ++++++++++--------
>>> config/kernel/kernel.config.x86_64-ipfire  | 57 ++++++++++++----------
>>> config/rootfiles/common/x86_64/linux       | 33 +++++++------
>>> 5 files changed, 131 insertions(+), 100 deletions(-)
>>> 
>>> -- 
>>> 2.34.1
>> 
>>
  

For the records: I spoke to Arne regarding this on the phone the other day. He confirmed to
me that this is by no means a severe issue from his point of view, and will check whether
firmware flashing continues to work with the hardened kernel.

> Could you please check with Arne how severe this is for the sensors?
> 
>> On 13 Apr 2022, at 10:18, Peter Müller <peter.mueller@ipfire.org> wrote:
>>
>> Hello Michael,
>>
>> thanks for your e-mail.
>>
>> This is caused by the kernel lockdown patch, since /dev/ports apparently can be used to alter
>> the running kernel, hence it is no longer available if LSM runs in "integrity" mode.
>>
>> On my testing machine, sensors and sensors-detect continue to work, but any sensor that requires
>> /dev/ports access is no longer available. On my testing hardware, that does not make a difference,
>> but I presume it will on other hardware with more or different sensors.
>>
>> sensors-detect does not implement any option to probe non-/dev/ports-sensors only, so I guess
>> there is nothing we can do besides a "> /dev/null 2>&1". I will change the collectd initscript
>> to reflect that.
>>
>> Thanks, and best regards,
>> Peter Müller
>>
>>
>>> Hello,
>>>
>>> I don’t know exactly which patch is responsible for this, but /dev/port is no longer accessible by sensors-detect.
>>>
>>> This leads to ugly messages when the system is booting up for the first time. Please see the attached screenshot.
>>>
>>> At least the message needs to be silenced, but you should investigate whether sensors will still work and is able to access readings for its hardware sensors.
>>>
>>>
>>>
>>> -Michael
>>>
>>>> On 19 Mar 2022, at 21:08, Peter Müller <peter.mueller@ipfire.org> wrote:
>>>>
>>>> This patchset improves hardening of our Linux kernel configurations for all
>>>> architectures. Most importantly, it features the activation of the "Linux
>>>> Security Module", also known as "kernel lockdown" (a phrase coined before the
>>>> pandemic), or LSM for short.
>>>>
>>>> Being set to "integrity" mode for a start, LSM prevents the kernel from being
>>>> modified by various mechanisms, of which we have some already covered. However,
>>>> it comes as a more holistic approach, which is why enabling it is desirable
>>>> for our userbase.
>>>>
>>>> Most of this patchset is based on recommendations by the "kconfig-hardened-check"
>>>> tool (https://github.com/a13xp0p0v/kconfig-hardened-check/), with some inspiration
>>>> taken directly from KSPP and grsecurity.
>>>>
>>>> Being unable to cross-compile IPFire for non-x86_64-architectures on my own,
>>>> and my VM on the Mustang currently being offline, this patchset does not come
>>>> with aligned kernel rootfiles for other architectures than x86_64. I am sorry
>>>> for any inconvenience and extra workload caused by this.
>>>>
>>>> Also, for the sake of completeness, the effect of LSM on virtualisation has not
>>>> been tested due to time constraints, and a lack of oversight _which_ virtualisation
>>>> features we officially support and which we don't. In doubt, however, I believe
>>>> the security benefit gained from LSM outweighs a partial functional loss of
>>>> virtualisation - but that is a highly biased opinion. :-)
>>>>
>>>> Peter Müller (11):
>>>> Kernel: Set CONFIG_ARCH_MMAP_RND_BITS to 32 bits
>>>> Kernel: Disable support for tracing block I/O actions
>>>> Kernel: Pin loading kernel files to one filesystem
>>>> Kernel: Enable undefined behaviour sanity checker
>>>> Kernel: Gate SETID transitions to limit CAP_SET(G|U)ID capabilities
>>>> Kernel: Enable LSM support and set security level to "integrity"
>>>> Kernel: Trigger BUG if data corruption is detected
>>>> Kernel: Do not automatically load TTY line disciplines, only if
>>>>   necessary
>>>> Kernel: Enable SVA support for both Intel and AMD CPUs
>>>> Kernel: Disable function and stack tracers
>>>> Kernel: Update rootfile for x86_64
>>>>
>>>> config/kernel/kernel.config.aarch64-ipfire | 47 ++++++++++--------
>>>> config/kernel/kernel.config.armv6l-ipfire  | 47 ++++++++++--------
>>>> config/kernel/kernel.config.riscv64-ipfire | 47 ++++++++++--------
>>>> config/kernel/kernel.config.x86_64-ipfire  | 57 ++++++++++++----------
>>>> config/rootfiles/common/x86_64/linux       | 33 +++++++------
>>>> 5 files changed, 131 insertions(+), 100 deletions(-)
>>>>
>>>> -- 
>>>> 2.34.1
>>>
>>>
>
  

Hello Peter,

Thank you. So for the sensors, we can keep LSM on. Cool.

-Michael

> On 14 Apr 2022, at 07:16, Peter Müller <peter.mueller@ipfire.org> wrote:
> 
> For the records: I spoke to Arne regarding this on the phone the other day. He confirmed to
> me that this is by no means a severe issue from his point of view, and will check whether
> firmware flashing continues to work with the hardened kernel.
> 
>> Could you please check with Arne how severe this is for the sensors?
>> 
>>> On 13 Apr 2022, at 10:18, Peter Müller <peter.mueller@ipfire.org> wrote:
>>> 
>>> Hello Michael,
>>> 
>>> thanks for your e-mail.
>>> 
>>> This is caused by the kernel lockdown patch, since /dev/ports apparently can be used to alter
>>> the running kernel, hence it is no longer available if LSM runs in "integrity" mode.
>>> 
>>> On my testing machine, sensors and sensors-detect continue to work, but any sensor that requires
>>> /dev/ports access is no longer available. On my testing hardware, that does not make a difference,
>>> but I presume it will on other hardware with more or different sensors.
>>> 
>>> sensors-detect does not implement any option to probe non-/dev/ports-sensors only, so I guess
>>> there is nothing we can do besides a "> /dev/null 2>&1". I will change the collectd initscript
>>> to reflect that.
>>> 
>>> Thanks, and best regards,
>>> Peter Müller
>>> 
>>> 
>>>> Hello,
>>>> 
>>>> I don’t know exactly which patch is responsible for this, but /dev/port is no longer accessible by sensors-detect.
>>>> 
>>>> This leads to ugly messages when the system is booting up for the first time. Please see the attached screenshot.
>>>> 
>>>> At least the message needs to be silenced, but you should investigate whether sensors will still work and is able to access readings for its hardware sensors.
>>>> 
>>>> 
>>>> 
>>>> -Michael
>>>> 
>>>>> On 19 Mar 2022, at 21:08, Peter Müller <peter.mueller@ipfire.org> wrote:
>>>>> 
>>>>> This patchset improves hardening of our Linux kernel configurations for all
>>>>> architectures. Most importantly, it features the activation of the "Linux
>>>>> Security Module", also known as "kernel lockdown" (a phrase coined before the
>>>>> pandemic), or LSM for short.
>>>>> 
>>>>> Being set to "integrity" mode for a start, LSM prevents the kernel from being
>>>>> modified by various mechanisms, of which we have some already covered. However,
>>>>> it comes as a more holistic approach, which is why enabling it is desirable
>>>>> for our userbase.
>>>>> 
>>>>> Most of this patchset is based on recommendations by the "kconfig-hardened-check"
>>>>> tool (https://github.com/a13xp0p0v/kconfig-hardened-check/), with some inspiration
>>>>> taken directly from KSPP and grsecurity.
>>>>> 
>>>>> Being unable to cross-compile IPFire for non-x86_64-architectures on my own,
>>>>> and my VM on the Mustang currently being offline, this patchset does not come
>>>>> with aligned kernel rootfiles for other architectures than x86_64. I am sorry
>>>>> for any inconvenience and extra workload caused by this.
>>>>> 
>>>>> Also, for the sake of completeness, the effect of LSM on virtualisation has not
>>>>> been tested due to time constraints, and a lack of oversight _which_ virtualisation
>>>>> features we officially support and which we don't. In doubt, however, I believe
>>>>> the security benefit gained from LSM outweighs a partial functional loss of
>>>>> virtualisation - but that is a highly biased opinion. :-)
>>>>> 
>>>>> Peter Müller (11):
>>>>> Kernel: Set CONFIG_ARCH_MMAP_RND_BITS to 32 bits
>>>>> Kernel: Disable support for tracing block I/O actions
>>>>> Kernel: Pin loading kernel files to one filesystem
>>>>> Kernel: Enable undefined behaviour sanity checker
>>>>> Kernel: Gate SETID transitions to limit CAP_SET(G|U)ID capabilities
>>>>> Kernel: Enable LSM support and set security level to "integrity"
>>>>> Kernel: Trigger BUG if data corruption is detected
>>>>> Kernel: Do not automatically load TTY line disciplines, only if
>>>>>  necessary
>>>>> Kernel: Enable SVA support for both Intel and AMD CPUs
>>>>> Kernel: Disable function and stack tracers
>>>>> Kernel: Update rootfile for x86_64
>>>>> 
>>>>> config/kernel/kernel.config.aarch64-ipfire | 47 ++++++++++--------
>>>>> config/kernel/kernel.config.armv6l-ipfire  | 47 ++++++++++--------
>>>>> config/kernel/kernel.config.riscv64-ipfire | 47 ++++++++++--------
>>>>> config/kernel/kernel.config.x86_64-ipfire  | 57 ++++++++++++----------
>>>>> config/rootfiles/common/x86_64/linux       | 33 +++++++------
>>>>> 5 files changed, 131 insertions(+), 100 deletions(-)
>>>>> 
>>>>> -- 
>>>>> 2.34.1
>>>> 
>>>> 
>>
  

Hello Michael,

aaaaand here is the disappointment: As already apprehended, firmware flashing does no longer work with the
hardened kernel, as Arne told me on the phone today. :-/

(And since all these APUs run on x86_64 as well, we cannot even enable LSM on that kernel, like we did with
other hardening features that were not available or usable on certain architectures.

Another option would leaving LSM enabled, but without enforcing the "integrity" level. It can be enabled via
a trigger to some /proc location on runtime - but attackers can tamper with that, it kind of renders the
whole idea ad absurdum, and I would really consider this as a last resort. Besides, users would have to disable
it every time they want to flash a firmware.)

Oh, goddammit. Why can't _one_ thing in life just _work_?!

Thanks, and best regards,
Peter Müller


> Hello Peter,
> 
> Thank you. So for the sensors, we can keep LSM on. Cool.
> 
> -Michael
> 
>> On 14 Apr 2022, at 07:16, Peter Müller <peter.mueller@ipfire.org> wrote:
>>
>> For the records: I spoke to Arne regarding this on the phone the other day. He confirmed to
>> me that this is by no means a severe issue from his point of view, and will check whether
>> firmware flashing continues to work with the hardened kernel.
>>
>>> Could you please check with Arne how severe this is for the sensors?
>>>
>>>> On 13 Apr 2022, at 10:18, Peter Müller <peter.mueller@ipfire.org> wrote:
>>>>
>>>> Hello Michael,
>>>>
>>>> thanks for your e-mail.
>>>>
>>>> This is caused by the kernel lockdown patch, since /dev/ports apparently can be used to alter
>>>> the running kernel, hence it is no longer available if LSM runs in "integrity" mode.
>>>>
>>>> On my testing machine, sensors and sensors-detect continue to work, but any sensor that requires
>>>> /dev/ports access is no longer available. On my testing hardware, that does not make a difference,
>>>> but I presume it will on other hardware with more or different sensors.
>>>>
>>>> sensors-detect does not implement any option to probe non-/dev/ports-sensors only, so I guess
>>>> there is nothing we can do besides a "> /dev/null 2>&1". I will change the collectd initscript
>>>> to reflect that.
>>>>
>>>> Thanks, and best regards,
>>>> Peter Müller
>>>>
>>>>
>>>>> Hello,
>>>>>
>>>>> I don’t know exactly which patch is responsible for this, but /dev/port is no longer accessible by sensors-detect.
>>>>>
>>>>> This leads to ugly messages when the system is booting up for the first time. Please see the attached screenshot.
>>>>>
>>>>> At least the message needs to be silenced, but you should investigate whether sensors will still work and is able to access readings for its hardware sensors.
>>>>>
>>>>>
>>>>>
>>>>> -Michael
>>>>>
>>>>>> On 19 Mar 2022, at 21:08, Peter Müller <peter.mueller@ipfire.org> wrote:
>>>>>>
>>>>>> This patchset improves hardening of our Linux kernel configurations for all
>>>>>> architectures. Most importantly, it features the activation of the "Linux
>>>>>> Security Module", also known as "kernel lockdown" (a phrase coined before the
>>>>>> pandemic), or LSM for short.
>>>>>>
>>>>>> Being set to "integrity" mode for a start, LSM prevents the kernel from being
>>>>>> modified by various mechanisms, of which we have some already covered. However,
>>>>>> it comes as a more holistic approach, which is why enabling it is desirable
>>>>>> for our userbase.
>>>>>>
>>>>>> Most of this patchset is based on recommendations by the "kconfig-hardened-check"
>>>>>> tool (https://github.com/a13xp0p0v/kconfig-hardened-check/), with some inspiration
>>>>>> taken directly from KSPP and grsecurity.
>>>>>>
>>>>>> Being unable to cross-compile IPFire for non-x86_64-architectures on my own,
>>>>>> and my VM on the Mustang currently being offline, this patchset does not come
>>>>>> with aligned kernel rootfiles for other architectures than x86_64. I am sorry
>>>>>> for any inconvenience and extra workload caused by this.
>>>>>>
>>>>>> Also, for the sake of completeness, the effect of LSM on virtualisation has not
>>>>>> been tested due to time constraints, and a lack of oversight _which_ virtualisation
>>>>>> features we officially support and which we don't. In doubt, however, I believe
>>>>>> the security benefit gained from LSM outweighs a partial functional loss of
>>>>>> virtualisation - but that is a highly biased opinion. :-)
>>>>>>
>>>>>> Peter Müller (11):
>>>>>> Kernel: Set CONFIG_ARCH_MMAP_RND_BITS to 32 bits
>>>>>> Kernel: Disable support for tracing block I/O actions
>>>>>> Kernel: Pin loading kernel files to one filesystem
>>>>>> Kernel: Enable undefined behaviour sanity checker
>>>>>> Kernel: Gate SETID transitions to limit CAP_SET(G|U)ID capabilities
>>>>>> Kernel: Enable LSM support and set security level to "integrity"
>>>>>> Kernel: Trigger BUG if data corruption is detected
>>>>>> Kernel: Do not automatically load TTY line disciplines, only if
>>>>>>  necessary
>>>>>> Kernel: Enable SVA support for both Intel and AMD CPUs
>>>>>> Kernel: Disable function and stack tracers
>>>>>> Kernel: Update rootfile for x86_64
>>>>>>
>>>>>> config/kernel/kernel.config.aarch64-ipfire | 47 ++++++++++--------
>>>>>> config/kernel/kernel.config.armv6l-ipfire  | 47 ++++++++++--------
>>>>>> config/kernel/kernel.config.riscv64-ipfire | 47 ++++++++++--------
>>>>>> config/kernel/kernel.config.x86_64-ipfire  | 57 ++++++++++++----------
>>>>>> config/rootfiles/common/x86_64/linux       | 33 +++++++------
>>>>>> 5 files changed, 131 insertions(+), 100 deletions(-)
>>>>>>
>>>>>> -- 
>>>>>> 2.34.1
>>>>>
>>>>>
>>>
>