hi guys , mentioned about IMA Integrity Measurement Architecture
allows greater security , can be automated with one click ,
kernel > ima_policy=appraise_tcb ima_appraise=fix ima_policy=tcb ima_hash=sha512 evm=fix
Debian project, with ima-evm, whonix could include this security
https://www.phoronix.com/scan.php?page=news_item&px=Sony-Lock-Up-DebugFS
Sony contributes more safeguards against debugFS abuse from userland. The KConf becomes effective in more modern versions.
We’ve already mitigated exploiting this by non-kernel attackers via apparmor-profile-everything and hide-hardware-info’s sysfs restrictions. However, we can also disable
CONFIG_INTEL_RAPL
CONFIG_PERF_EVENTS_INTEL_RAPL
in the kernel configuration. We could probably disable the entire powercap interface as future-proofing against other variations of this type of sidechannel attack but this may be too extreme and hurt usability (depending on how frequently it’s used, I’m not sure).
Probably should not break CPU temperature control. Related:
GrapheneOS now enables CONFIG_FORTIFY_SOURCE_STRICT_STRING in production builds:
This is a feature from linux-hardened that I added back to GrapheneOS which makes the FORTIFY_SOURCE feature more strict and better at catching buffer overflows but it wasn’t intended for use in end-user builds, only for bug finding as it can cause false positives so I didn’t enable it before.
We should test enabling this too and see if it works. CLIP OS only enables it in debug builds.
GCC plugins (including STRUCTLEAK, STACKLEAK, RANDSTRUCT and others) may get removed because upstream is being pedantic about a single second difference.
Of course Linux maintains century old drivers that nobody ever uses but when it comes to actually important security features, they get rid of them at any chance they get. This is ridiculous and quite worrying.
I am baffled by Kees’ reply who’s supposed to be the checks and balance on stupid stuff like that.
Merged and uploaded to all repositories.
CI build failing.
I can’t tell what’s causing this. Can you?
Happening when using --debug with environment variable CI=true being set.
+ true 'Sanity test. '\''make oldconfig'\'' should not modify '\''.config'\''.'
+ true https://forums.whonix.org/t/kernel-recompilation-for-better-hardening/7598/317
+ make oldconfig -C /var/lib/hardened-kernel/hardened-vm-kernel/linux-4.19.122/
...
+ diff /home/travis/build/Whonix/hardened-kernel/usr/share/hardened-kernel/hardened-vm-kernel /var/lib/hardened-kernel/hardened-vm-kernel/linux-4.19.122//.config
diff then exits non-zero.
See the diff.
diff /home/travis/build/Whonix/hardened-kernel/usr/share/hardened-kernel/hardened-vm-kernel /var/lib/hardened-kernel/hardened-vm-kernel/linux-4.19.122//.config
.
> # CONFIG_GENERIC_IRQ_DEBUGFS is not set
286a288
> # CONFIG_IOSF_MBI_DEBUG is not set
292a295
> # CONFIG_QUEUED_LOCK_STAT is not set
300a304
> # CONFIG_XEN_DEBUG_FS is not set
302a307
> # CONFIG_KVM_DEBUG_FS is not set
344a350
> # CONFIG_X86_MCE_INJECT is not set
488a495
> # CONFIG_ACPI_CUSTOM_METHOD is not set
496a504
> # CONFIG_ACPI_APEI_EINJ is not set
685c693
< # CONFIG_KPROBES is not set
---
> CONFIG_KPROBES=y
687a696
> CONFIG_OPTPROBES=y
689a699
> CONFIG_KRETPROBES=y
758a769
> # CONFIG_GCOV_KERNEL is not set
802a814,815
> CONFIG_BLK_DEBUG_FS=y
> CONFIG_BLK_DEBUG_FS_ZONED=y
1500a1514
> # CONFIG_ZRAM_MEMORY_TRACKING is not set
2079a2094
> # CONFIG_NETDEVSIM is not set
3718a3734
> # CONFIG_SW_SYNC is not set
3895a3912
> # CONFIG_IOMMU_DEBUGFS is not set
3989a4007
> # CONFIG_RAS_CEC is not set
4019a4038
> # CONFIG_INTEL_TH_DEBUG is not set
4616a4636
> # CONFIG_DYNAMIC_DEBUG is not set
4632c4652
< # CONFIG_DEBUG_FS is not set
---
> CONFIG_DEBUG_FS=y
4733a4754
> CONFIG_FUNCTION_ERROR_INJECTION=y
4749a4771
> # CONFIG_LKDTM is not set
4751a4774
> # CONFIG_KPROBES_SANITY_TEST is not set
4808a4832
> # CONFIG_DEBUG_BOOT_PARAMS is not set
That should not be happening.
Running
make oldconfig -C "$extracted_linux_kernel_sources_folder"
should not be modifying "$extracted_linux_kernel_sources_folder/.config" "${MYDIR}/${kernel_config}" should already be in a state where a later make oldconfig would do nothing. That is to make the process “less magic”. Less auto generated. Easier to review. More predictable. Allow reviewers to review to full kernel configuration. No implicit filling the blanks during compilation. Solution? Run make oldconfig yourself, review, and update config in git. Make make oldconfig out of work.
Build history reveals that this is only happening since https://github.com/Whonix/hardened-kernel/pull/55 was merged.
But I don’t see how that pull request could have caused that since it’s opt in and not used on CI.
The sanity check runs after the kprobes/ftrace configs are appended: https://github.com/Whonix/hardened-kernel/blob/629b62475455ce5ef073e6ba8b970ea76ade88a0/usr/share/hardened-kernel/build#L109
make oldconfig will then shift those configs about to put them in the correct order in the full file. The sanity test must run before those options are added.
The build for that passed though? It seems to fail because of https://github.com/Whonix/hardened-kernel/commit/629b62475455ce5ef073e6ba8b970ea76ade88a0
Indeed.
That sanity test runs if [ "$debug" = "true" ]; then. It is nested in another IF. if [ "$CI" = "true" ]; then. Btw I don’t see why that should be nested. (Perhaps was implemented this way because CI build uses --debug anyhow.)
Could run that sanity test outside of if [ "$debug" = "true" ]; then and earlier. I’ll try that now.
No. On https://github.com/Whonix/hardened-kernel/commit/629b62475455ce5ef073e6ba8b970ea76ade88a0 the red X indicates a failed Travis CI build. I should have noticed this earlier.
Seems like. But I understand how it can be the cause since it added an opt-in. Didn’t changed actual execution on CI.
Now I get why this was happening on CI. --debug results in kprobes="true".
That CI issue seems now fixed. Build hasn’t completed yet but it’s past that issue.
Another thing…
if [ "${kprobes}" = "true" ]; then
cat "${MYDIR}/kprobes-ftrace" >> "$extracted_linux_kernel_sources_folder/.config"
fi
We don’t run make oldconfig -C "$extracted_linux_kernel_sources_folder".
vs
cat "${MYDIR}/debugging-config" >> "$extracted_linux_kernel_sources_folder/.config"
if [ "${kernel_config}" = "hardened-host-kernel" ]; then
cat "${MYDIR}/debugging-config-host" >> "$extracted_linux_kernel_sources_folder/.config"
fi
make oldconfig -C "$extracted_linux_kernel_sources_folder"
We do run make oldconfig -C "$extracted_linux_kernel_sources_folder".
Does that look alright?
It shouldn’t be too important but running make oldconfig wouldn’t hurt. It’ll rearrange the file properly before build but this isn’t required.