madaidan via Whonix Forum:
Sign all kernel modules by madaidan · Pull Request #36 · Kicksecure/hardened-kernel · GitHub
Merged.
All merged.
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/KconfigThe 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.
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?
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.
Merged.
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.
I already have. It’s just hardware stuff.
It is. Both should be the current kernel version (4.19.97).
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.
Awesome initiative! Another alternative or additional enhancement could
be a wrapper script. mount is really powerful with lots of command
line options which I don’t even know all. First step could be for a
script to record all invocations of mount / umount ( / others? ) and
to pass to the real mount command unfiltered. That is to get a survey on
how it is being used in legitimate ways. A “passthrough mode”. Next step
could be adding a filtering mode where command line options and/or
parameters are restricted. I.e. no longer possible to mount anything on
anything with any mount option.
That wouldn’t work as mount isn’t just a program. It’s also a syscall (/bin/mount uses this syscall) so an attacker can just create their own program to abuse it.
We might want to add this to our kernel once our version catches up with STACKLEAK. This patch was part of the original STACKLEAK patch series sent upstream but it was dropped because all VLAs were removed from the kernel so it had no purpose anymore. It’d only be useful for out-of-tree code or as a fail-safe incase VLAs are reintroduced although that’s unlikely and even more so for an LTS kernel.
There’s also these extracted PaX features we can use:
https://github.com/vmware/photon/blob/master/SPECS/linux/0002-Added-PAX_RANDKSTACK.patch
https://github.com/vmware/photon/blob/master/SPECS/linux/0003-Added-rap_plugin.patch
Although it might be better to wait til S.A.R.A., CONFIG_RANDOMIZE_KSTACK_OFFSET and clang CFI are upstream.
We also need to prevent the init_on_free=1 init_on_alloc=1 / page_poison=1 slub_debug=P boot parameters from being set as we’re using linux-hardened’s CONFIG_PAGE_SANITIZE / CONFIG_SLAB_SANITIZE instead.
Can you please add this to a phab ticket? By the time kernel 5+ rolls around this megathread will be at least a thousand posts and your finding s will be buried.
I appropriate the effort but I cannot review C code, let alone kernel code. Unless another qualified Whonix team member joins the project and does such reviews (which may not be likely), I don’t want to merge it. It would be irresponsible of me if I merged code that I don’t understand.
Therefore this must go through a skilled upstream. I don’t want to become the host (upstream) of it. Any of Debian, linux-hardened and/or CLIP OS seem suitable. [1] Others possibly to if any exist. Another option could be to become upstream yourself and becoming the new Libre grsecurity alternative, hardened kernel.
Also even if I could review kernel patches, I think it’s much too early to focus on something as advanced as that. There’s still a ton to do related to packaging and integration work to do before this gets ready for wide testing / installation by default.
[1] I am aware of the previous discussion on LTS vs stable kernel but perhaps this needs to be reconsidered if there is no upstream that wants to merge security enhancement patches for Linux LTS.
Reminds me… Can’t we benefit from CLIP OS kernel config generation and/or hardened kernel sources? Is it only about ^[1]?
(Well, CLIP OS is based on hardened gentoo. That would still leave packaging and integration work left to do but maybe helpful nonetheless as this at least provides C/kernel code reviewers.)