From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: [PATCH 00/11] Kernel: Improve hardening Date: Thu, 14 Apr 2022 14:51:26 +0000 Message-ID: In-Reply-To: <4FB151A4-A8DA-4D73-8A3F-D6B146456931@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1303321046326485063==" List-Id: --===============1303321046326485063== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 archite= ctures. Another option would leaving LSM enabled, but without enforcing the "integrit= y" level. It can be enabled via a trigger to some /proc location on runtime - but attackers can tamper with t= hat, it kind of renders the whole idea ad absurdum, and I would really consider this as a last resort. Be= sides, 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=C3=BCller > Hello Peter, >=20 > Thank you. So for the sensors, we can keep LSM on. Cool. >=20 > -Michael >=20 >> On 14 Apr 2022, at 07:16, Peter M=C3=BCller w= rote: >> >> 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 wil= l 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=C3=BCller = 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 "inte= grity" 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 d= oes 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-sen= sors only, so I guess >>>> there is nothing we can do besides a "> /dev/null 2>&1". I will change t= he collectd initscript >>>> to reflect that. >>>> >>>> Thanks, and best regards, >>>> Peter M=C3=BCller >>>> >>>> >>>>> Hello, >>>>> >>>>> I don=E2=80=99t 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 w= hether sensors will still work and is able to access readings for its hardwar= e sensors. >>>>> >>>>> >>>>> >>>>> -Michael >>>>> >>>>>> On 19 Mar 2022, at 21:08, Peter M=C3=BCller wrote: >>>>>> >>>>>> This patchset improves hardening of our Linux kernel configurations fo= r all >>>>>> architectures. Most importantly, it features the activation of the "Li= nux >>>>>> Security Module", also known as "kernel lockdown" (a phrase coined bef= ore the >>>>>> pandemic), or LSM for short. >>>>>> >>>>>> Being set to "integrity" mode for a start, LSM prevents the kernel fro= m 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 desi= rable >>>>>> for our userbase. >>>>>> >>>>>> Most of this patchset is based on recommendations by the "kconfig-hard= ened-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 m= y own, >>>>>> and my VM on the Mustang currently being offline, this patchset does n= ot come >>>>>> with aligned kernel rootfiles for other architectures than x86_64. I a= m sorry >>>>>> for any inconvenience and extra workload caused by this. >>>>>> >>>>>> Also, for the sake of completeness, the effect of LSM on virtualisatio= n has not >>>>>> been tested due to time constraints, and a lack of oversight _which_ v= irtualisation >>>>>> features we officially support and which we don't. In doubt, however, = I believe >>>>>> the security benefit gained from LSM outweighs a partial functional lo= ss of >>>>>> virtualisation - but that is a highly biased opinion. :-) >>>>>> >>>>>> Peter M=C3=BCller (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(-) >>>>>> >>>>>> --=20 >>>>>> 2.34.1 >>>>> >>>>> >>> >=20 --===============1303321046326485063==--