Comments (5)
other use case is prevent leakage of kernel pointers to log file, /proc directory files, or terminal output.
Which is just a bunch of debugs and dmesg turned off.
another one is the one provided by Whonix.org (a KSPP variant) which is more rigorous form of kernel security.
Another one is for Spectre, et. al., mitigation and that has a bunch of config s as well.
from kernel-hardening-checker.
Hello @petervanvugt,
Thanks for your initiative!
May I ask you to describe your use-case in details?
Which new requirements to kconfig-hardened-check
behavior does it have?
Maybe a layered yaml that you propose is not a single solution for your use-case.
Moreover, I see that your use-case relates to this discussion: #9 (comment)
I think we can define some common solution.
Now about the syntax of check definitions.
- Currently all checks are grouped together in
kconfig_hardened_check/__init__.py
. - The check definitions are very short.
So I can observe them altogether. That helps me to understand and maintain these checks, which is not an easy task.
That is my main rationale.
Here you propose a completely different syntax.
I think we should discuss it before we start coding.
My thoughts:
- Can we separate changing check definition syntax from changing
kconfig-hardened-check
behavior? - The given syntax example doesn't cover all check types that we have. Could you please write all current checks in your new syntax? I think we need that for making the decision.
(I'm travelling till the beginning of March, excuse me for delayed replies)
Best regards,
Alexander
from kernel-hardening-checker.
Hi @a13xp0p0v ,
My use essentially falls into three cases:
- My system has kconfigs not in mainline that must always be set.
For example, I might want to verify PANIC_ON_DATA_CORRUPTION
from Android is enabled, as a defensive measure, because I'd rather the system immediately reboot at the first sign things are going off the rails, rather than risk being exploited by an attacker.
- My system has kconfigs that are in mainline, which are only in play for my hardware.
For example, I may want to verify that my chip's CONFIG_<HWVENDOR>_HWRANDOM
is enabled, because I'm using it as a cryptographically secure source of enropy.
- My system has kconfigs that are in mainline, which many/most users want enabled, but I want disabled, because they add no benefit, and some nonzero risk.
For example, if I'm building an embedded system that uses NXP's i.MX line, I may want to verify CONFIG_SERIAL_IMX
and CONFIG_SERIAL_IMX_CONSOLE
are not enabled, because I want to be absolutely certain that the serial drivers and associated kernel console drivers haven't been included. Or, in a similar vein to (1), I may want to enable CONFIG_PANIC_ON_OOPS
because I prioritize the correctness of my system over its availability.
[EDIT] Another, potentially stronger example I have run into recently is PROC_PAGE_MONITOR
. The grsecurity patch set removes it for good reason, because access to /proc/<pid>/smaps
can leak memory mapping information defeating ASLR. While there are mitigations all recent versions of the kernel to prevent insufficiently privileged processes from reading the map of a more privileged process, there have been a few race conditions and side channels that have been shown to circumvent this. So, it is reasonable that many users will want to disable this altogether. However, Android's libmeminfo needs to read this entry to compute process memory utilization, which is pretty hard to live without in some applications.
Can we serve all these use cases?
Clearly, there a few paths that could be taken here. We could add these requirements to the very compact representation in kconfig_hardened_check/__init__.py
. And for (1) and (2), we could likely produce some combination of AND/OR kconfig checks (albeit sometimes non-trivial) that keeps the check from generating unnecessarily noisy output/false positives when run on configs for non-applicable hardware, or for kernels that don't fully track mainline. But this wouldn't solve for (3), unless we require the tool be specially patched for such cases, or we add runtime args that turn on each of these checks.
If we want to be able to specify additional requirements at runtime and/or override requirements at runtime, we need a way to specify alternate requirements. This is why I am proposing representing the requirements as runtime configuration, rather than code. As to how we would represent some of the more complex requirements, I am proposing we break them down into requirements that each only check one config each, optionally only checked for some combination of specific architectures/kernel versions/CONFIG_
s.
We could take configs whose names changed, such as this:
282 l += [OR(OptCheck('self_protection', 'defconfig', 'STACKPROTECTOR_STRONG', 'y'),
283 OptCheck('self_protection', 'defconfig', 'CC_STACKPROTECTOR_STRONG', 'y'))]
and split them into two separate requirements, the first one for kernels >= 4.18, and the second one for kernels >= 3.14 and < 4.18.
The most complex requirement I see is this one:
307 if arch == 'ARM64':
...
310 l += [OR(OptCheck('self_protection', 'defconfig', 'HARDEN_EL2_VECTORS', 'y'),
311 AND(OptCheck('self_protection', 'defconfig', 'RANDOMIZE_BASE', 'y'),
312 VerCheck((5, 9))))] # HARDEN_EL2_VECTORS was included in RANDOMIZE_BASE in v5.9
which could be split into two requirements: one for RANDOMIZE_BASE
on kernels >= 5.9 for ARM64, and a second check for HARDEN_EL2_VECTORS
on older kernels >= 4.17 and < 5.9, also for ARM64. This would keep the requirements more readable in the long run.
What do you think?
from kernel-hardening-checker.
@petervanvugt thanks a lot for describing your use-cases.
I think they match with this one.
I want to make them possible.
I think kconfig-hardened-check
should allow to override the default checks and append custom checks.
As a first step, we need some simple solution without changing the check description syntax.
Then we can ponder over the check description syntax.
I will experiment with that.
If you create any prototype, please share!
from kernel-hardening-checker.
I implemented a part of this feature in override_expected_value()
.
-
Implementation: c109072
-
Unit-test: 7194de8
-
Refinement of the CONFIG_ARCH_MMAP_RND_BITS check using this feature: 9bbea5b
from kernel-hardening-checker.
Related Issues (20)
- add disabling CONFIG_AIO (legacy POSIX AIO) as a recommendation HOT 1
- add check for CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x0 too HOT 4
- add check for UNWIND_PATCH_PAC_INTO_SCS, which reduces security compared to using both PAC + SCS HOT 4
- Minimal kernel version ? HOT 1
- New CONFIG_MODULE_SIG_SHA3_512 option in kernel 6.7 HOT 1
- Better json output HOT 4
- Add io_uring_disabled sysctl to disable/limit io_uring creation
- Reducing Kernel Symbols on File System by Disabling CONFIG_VMLINUX_MAP and CONFIG_DEBUG_KERNEL HOT 2
- Kernel Debug Metadata Access with CONFIG_DYNAMIC_DEBUG HOT 3
- Add ia32_emulation kernel cmdline parameter to disable 32-bit emulation support on 64-bit x86 CPUs HOT 1
- Suggestions for kernel-hardening-checker HOT 3
- Add kconfig option for Intel CET shadow stack
- Add check for CONFIG_MITIGATION_RFDS HOT 1
- Linux 6.9 Renames Many CPU Mitigation CONFIGs to CONFIG_MITIGATION_... HOT 1
- The separation between desktop and server. HOT 3
- Integration with oracle/kconfigs HOT 2
- Disable `CONFIG_N_GSM` HOT 2
- Disable codecov upload for pull-requests HOT 6
- Improve --kernel-version and --cmdline HOT 4
- Which Python versions should `kernel-hardening-checker` support? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kernel-hardening-checker.