* Re: [PATCH 00/11] Kernel: Improve hardening [not found] <265D481E-78F1-4A6D-AAF4-47A5997D5741@ipfire.org> @ 2022-04-13 9:18 ` Peter Müller 2022-04-13 9:20 ` Michael Tremer 0 siblings, 1 reply; 6+ messages in thread From: Peter Müller @ 2022-04-13 9:18 UTC (permalink / raw) To: development [-- Attachment #1: Type: text/plain, Size: 3901 bytes --] 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(a)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 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 00/11] Kernel: Improve hardening 2022-04-13 9:18 ` [PATCH 00/11] Kernel: Improve hardening Peter Müller @ 2022-04-13 9:20 ` Michael Tremer 2022-04-14 6:16 ` Peter Müller 0 siblings, 1 reply; 6+ messages in thread From: Michael Tremer @ 2022-04-13 9:20 UTC (permalink / raw) To: development [-- Attachment #1: Type: text/plain, Size: 4156 bytes --] 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(a)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(a)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 >> >> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 00/11] Kernel: Improve hardening 2022-04-13 9:20 ` Michael Tremer @ 2022-04-14 6:16 ` Peter Müller 2022-04-14 7:11 ` Michael Tremer 0 siblings, 1 reply; 6+ messages in thread From: Peter Müller @ 2022-04-14 6:16 UTC (permalink / raw) To: development [-- Attachment #1: Type: text/plain, Size: 4471 bytes --] 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(a)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(a)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 >>> >>> > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 00/11] Kernel: Improve hardening 2022-04-14 6:16 ` Peter Müller @ 2022-04-14 7:11 ` Michael Tremer 2022-04-14 14:51 ` Peter Müller 0 siblings, 1 reply; 6+ messages in thread From: Michael Tremer @ 2022-04-14 7:11 UTC (permalink / raw) To: development [-- Attachment #1: Type: text/plain, Size: 4764 bytes --] 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(a)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(a)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(a)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 >>>> >>>> >> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 00/11] Kernel: Improve hardening 2022-04-14 7:11 ` Michael Tremer @ 2022-04-14 14:51 ` Peter Müller 0 siblings, 0 replies; 6+ messages in thread From: Peter Müller @ 2022-04-14 14:51 UTC (permalink / raw) To: development [-- Attachment #1: Type: text/plain, Size: 5712 bytes --] 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(a)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(a)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(a)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 >>>>> >>>>> >>> > ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 00/11] Kernel: Improve hardening
@ 2022-03-19 21:08 Peter Müller
0 siblings, 0 replies; 6+ messages in thread
From: Peter Müller @ 2022-03-19 21:08 UTC (permalink / raw)
To: development
[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]
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
^ permalink raw reply [flat|nested] 6+ messages in threadend of thread, other threads:[~2022-04-14 14:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <265D481E-78F1-4A6D-AAF4-47A5997D5741@ipfire.org>
2022-04-13 9:18 ` [PATCH 00/11] Kernel: Improve hardening Peter Müller
2022-04-13 9:20 ` Michael Tremer
2022-04-14 6:16 ` Peter Müller
2022-04-14 7:11 ` Michael Tremer
2022-04-14 14:51 ` Peter Müller
2022-03-19 21:08 Peter Müller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox