kernel recompilation for better hardening

Development
,
302

Compare them to the upstream code.

0002-lockdown-efivar_ssdt_load.patch → LKML: Matthew Garrett: [PATCH V40 28/29] efi: Restrict efivar_ssdt_load when the kernel is locked down

0003-lockdown-pci-bar-access.patch → LKML: Matthew Garrett: [PATCH V40 11/29] PCI: Lock down BAR access when the kernel is locked down

0004-lockdown-perf.patch → LKML: Matthew Garrett: [PATCH V40 24/29] lockdown: Lock down perf when in confidentiality mode

0005-lockdown-tiocsserial.patch → LKML: Matthew Garrett: [PATCH V40 18/29] lockdown: Lock down TIOCSSERIAL

0006-lockdown-ioport.patch → LKML: Matthew Garrett: [PATCH V40 12/29] x86: Lock down IO port access when the kernel is locked down

0007-lockdown-pcmcia.patch → LKML: Matthew Garrett: [PATCH V40 17/29] lockdown: Prohibit PCMCIA CIS storage when the kernel is locked down

0008-lockdown-module-params.patch → LKML: Matthew Garrett: [PATCH V40 19/29] lockdown: Lock down module params that specify hardware parameters (eg. ioport)

They’re all very similar. They’re mostly just simple if statements and exits. You can see they do the same even with limited C skills.

The perf lockdown patch is slightly different as my patch locks down perf entirely instead of just PERF_SAMPLE_REGS_INTR as more bad things can be done with perf such as kernel address leaking with PERF_SAMPLE_IP Breaking KASLR with perf

I’m not aware of any other project these patches would make sense in due to the reasons above.

This isn’t for inclusion in linux-hardened as they’ll prefer the official lockdown LSM and these patches only complement our config (things such as LOCKDOWN_KPROBES would be needed for linux-hardened but not us).

ClipOS uses the official lockdown LSM so these patches don’t make sense for them.

303

Should we also disable coredumps and enable them in the debug kernel?

1 Like
304

madaidan via Whonix Forum:

Compare them to the upstream code.

I can’t even do that. For all of Whonix’s source code, for any reviewers
reporting any security issues or asking any reasonable questions, I can
can handle that. For kernel code, I could not even fix minor things.

2 Likes
305

For simplicity, I think Whonix redistributed (downloadable) versions
could come with Debian standard stable kernel by default. This would
also serve as “debug” kernel. I.e. those VMs that can’t boot with the
hardened kernel can at least boot with the Debian kernel. During the
first boot, the hardened kernel could be compiled and installed
automatically before any networking goes up and before the user can do
anything except cancel compilation of the kernel.

Not much of an enhancement to do same as above but ship with a hardened
kernel which layout is public knowledge (redistributed, downloadable,
public build) anyhow. Related to

madaidan via Whonix Forum:

Should we also disable coredumps and enable them in the debug kernel?

I guess yes. Debugging in hardened-kernel (non-debug) isn’t possible now
anymore?

2 Likes
306

Patrick via Whonix Forum:

[1] For simplicity, I think Whonix redistributed (downloadable) versions
could come with Debian standard stable kernel by default. This would
also serve as “debug” kernel. I.e. those VMs that can’t boot with the
hardened kernel can at least boot with the Debian kernel. During the
first boot, the hardened kernel could be compiled and installed
automatically before any networking goes up and before the user can do
anything except cancel compilation of the kernel.

[2] Not much of an enhancement to do same as above but ship with a hardened
kernel which layout is public knowledge (redistributed, downloadable,
public build) anyhow. Related to
Hide Kernel Symbols for Better Security vs Reproducible Builds

This also simplifies reproducible builds since it doesn’t introduce new
non-determinism. Our hardened kernel uses all available randomization
security options. Disabling these for redistributed (downloadable)
versions would add even more complexity. [1] is enough.

2 Likes
307

I could. Not much could go wrong in such little changes though.

Basic debugging is possible. Not really anything advanced though.

1 Like
308
1 Like
309
1 Like
310

madaidan via Whonix Forum:

Sign all kernel modules by madaidan · Pull Request #36 · Kicksecure/hardened-kernel · GitHub

Merged.

1 Like
311

All merged.

1 Like
312

Do you have any ideas to assist reviewing the kernel config?

cat usr/share/hardened-kernel/hardened-vm-kernel | wc -l

5223

Maybe around 5000 kernel parameters. When calculating with 3 minutes to review if 1 kernel parameter makes sense (5000 kernel parameters * 3 minutes / 60 minutes / 24 hours) it needs more than 10 days nonstop to review all.

Reviewing a kernel parameter usually requires copying such as for example CONFIG_PREEMPT into a search engine and then at least reading the basic explanation from for example Linux Kernel Driver DataBase: CONFIG_PREEMPT_VOLUNTARY: Voluntary Kernel Preemption (Desktop). An inefficient workflow.

How to make this process more efficient? We’re probably not the first ones having this problem?

Can we somehow if we hover over our config parameters such as CONFIG_PREEMPT by mice being shown the relevant help text [1]?

Could you write a script to copy the help text from somewhere (kernel source) on top of the kernel parameter so no manual search of all parameters is required? If that makes sense?

Or can kconfig (or any fork / frontend) help to walk through parameters, current settings and help texts?

[1]

Preemptible Kernel found in arch/x86_64/Kconfig

The configuration item CONFIG_PREEMPT:

  • prompt: Preemptible Kernel
  • type: bool
  • depends on: (none)
  • defined in arch/x86_64/Kconfig
  • found in Linux kernels: 2.5.45–2.5.75, 2.6.0–2.6.12

Help text

This option reduces the latency of the kernel when reacting to real-time or interactive events by allowing a low priority process to be preempted even if it is in kernel mode executing a system call. This allows applications to run more reliably even when the system is under load. On contrary it may also break your drivers and add priority inheritance problems to your system. Don’t select it if you rely on a stable system or have slightly obscure hardware. It’s also not very well tested on x86-64 currently. You have been warned.

Say Y here if you are feeling brave and building a kernel for a desktop, embedded or real-time system. Say N if you are unsure.

2 Likes
313

Maybe make xconfig can do that? Any way to point make xconfig to our kernel config or does this need to be run from extracted kerne source folder only? Something better than make xconfig?

2 Likes
314

That’s counting empty lines and comments/unselected options too. With those removed, the actual config is 2171 parameters.

You can learn what most of the kernel parameters do without having to look them up.

Or, use make menuconfig which shows help options.

315
2 Likes
316

Merged.

1 Like
317

Could you please check the diff between hardened-host-kernel and hardened-vm-kernel config?

Using your favorite diff viewer.

meld hardened-host-kernel hardened-vm-kernel

kdiff3 hardened-host-kernel hardened-vm-kernel

diff hardened-host-kernel hardened-vm-kernel

The following difference seems wrong…

hardened-host-kernel:

CONFIG_BUILD_SALT=“4.19.0-6-amd64”

hardened-vm-kernel:

CONFIG_BUILD_SALT=“4.19.0-67-amd64”

Also any other differences where the delta can be reduced? Ideally, the delta should be as minimal as possible to make this more easy to review.

Also during automated testing (CI) is there some command make defconfig, make oldconfig or similar (I don’t understand all of these yet) that could be run?

[1] Maybe we can give up on the top comment. Reset that to whatever the default is.

Then during testing run “make configsomething” (whatever appropriate) and check that our .config stays the same prior and after running “make configsomething” ?

I guess make oldconfig makes most sense and shouldn’t prompt for anything. Presupposing [1] it shouldn’t result in any changes to the .config.

1 Like
318
1 Like
319
1 Like
320

I already have. It’s just hardware stuff.

It is. Both should be the current kernel version (4.19.97).

1 Like
321

Another way to prevent mount from being abused to overwrite things like apt (in the case of apparmor-profile-everything), would be to create a kernel patch to deny mounting if a sysctl has been set and prevent changing that sysctl after it’s been set. We can then set the sysctl in early boot after necessary filesystems have been mounted.

Grsecurity has a similar feature called GRKERNSEC_ROFS which does some mount restrictions.