Re: [PATCH 00/11] Kernel: Improve hardening

["Peter Müller" <peter.mueller@ipfire.org>]

[-- 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
>>>>>
>>>>>
>>>
>