Comments (10)
There's just GrapheneOS/kernel_common-6.6@af734cc.
from kernel-hardening-checker.
Hello @thestinger ,
Thanks for the idea.
Collecting all pieces together, we can have the following rules:
l += [OR(KconfigCheck('cut_attack_surface', 'clipos', 'MAGIC_SYSRQ', 'is not set'),
KconfigCheck('cut_attack_surface', 'my', 'MAGIC_SYSRQ_DEFAULT_ENABLE', '0x0'))]
...
l += [CmdlineCheck('cut_attack_surface', 'my', 'sysrq_always_enabled', 'is not set')]
...
l += [SysctlCheck('cut_attack_surface', 'my', 'kernel.sysrq', '0')]
Do you agree?
from kernel-hardening-checker.
MAGIC_SYSRQ_DEFAULT_ENABLE being set to 0x0 without being enabled via sysrq_always_enabled or kernel.sysrq should provide similar benefits. It's probably still best to fully disable the functionality.
Disabling it via the sysctl alone leaves a gap in early boot where it's enabled if MAGIC_SYSRQ_DEFAULT_ENABLE is 0x1 which seemed like a problem.
There's also MAGIC_SYSRQ_SERIAL for controlling whether sysrq can be enabled via the serial port. Having that enabled is a potential hole although it depends on having something implementing it.
I think either having MAGIC_SYSRQ disabled or having MAGIC_SYSRQ_DEFAULT_ENABLE set to 0x0 + MAGIC_SYSRQ_SERIAL disabled + not overriding it via kernel command line or kernel.sysrq is fine.
Android sets kernel.sysrq in early boot but yet lots of devices enable it via sysrq_always_enabled on the kernel command line and disabling in early boot also doesn't really seem right since there's a gap between the kernel being ready and init disabling it.
from kernel-hardening-checker.
Hello @thestinger,
Thanks again for your explanation.
I added:
- the
MAGIC_SYSRQ_DEFAULT_ENABLE
check: 48ff855 - the
kernel.sysrq
check: 538af12 - the
MAGIC_SYSRQ_SERIAL
check: d995dd6
Do you like it?
from kernel-hardening-checker.
By the way, the KSPP added this recommendation:
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=176
It allows sync, remount read-only and reboot/poweroff.
@thestinger, what do you think about it?
from kernel-hardening-checker.
Hi @thestinger!
Currently, these sysrq checks in kernel-hardening-checker
are marked as my recommendations.
But it would be nice to mark them as GrapheneOS
recommendations.
Could you give a link to the GrapheneOS documentation or code enforcing this configuration?
I would put it to the references.
And what do you think about CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=176
recommended by KSPP?
from kernel-hardening-checker.
We don't really need credit for it particularly since many of the KSPP recommendations came from us anyway.
from kernel-hardening-checker.
I mean the sysrq checks that I developed according to this issue #104:
l += [OR(KconfigCheck('cut_attack_surface', 'clipos', 'MAGIC_SYSRQ', 'is not set'),
KconfigCheck('cut_attack_surface', 'a13xp0p0v', 'MAGIC_SYSRQ_DEFAULT_ENABLE', '0x0'))]
l += [OR(KconfigCheck('cut_attack_surface', 'a13xp0p0v', 'MAGIC_SYSRQ_SERIAL', 'is not set'),
KconfigCheck('cut_attack_surface', 'a13xp0p0v', 'MAGIC_SYSRQ_DEFAULT_ENABLE', '0x0'))]
l += [CmdlineCheck('cut_attack_surface', 'a13xp0p0v', 'sysrq_always_enabled', 'is not set')]
l += [OR(SysctlCheck('cut_attack_surface', 'a13xp0p0v', 'kernel.sysrq', '0'),
AND(KconfigCheck('cut_attack_surface', 'clipos', 'MAGIC_SYSRQ', 'is not set'),
have_kconfig))]
They are currently marked as clipos
or a13xp0p0v
.
They are more restrictive than the KSPP recommendation.
Is it possible to refer to the GrapheneOS documentation or code for these checks?
from kernel-hardening-checker.
You can see our overall core kernel changes here:
https://github.com/GrapheneOS/kernel_common-6.6/commits/15/
Bear in mind we're starting from the Android Generic Kernel Image configuration with Clang CFI, etc. already enabled and some downstream hardening features. Android uses strict full system SELinux policies and that is what gets used to restrict eBPF, io_uring, userfaultfd, ioctl commands, dmesg, perf events, etc. rather than very coarse kernel features that are close to all or nothing. This means most things related to restricting userspace access aren't relevant since SELinux policy is used. We also introduce our own extensions to SELinux.
Some our hardening is hardware-specific so it's outside of this GKI repository.
As an example of how a feature can be spread out across a bunch of areas, we have this USB-C / pogo pins port control feature for reducing attack surface while locked at both a software (kernel) and hardware (USB-C / pogo pins controller) level:
https://grapheneos.org/features#usb-c-port-and-pogo-pins-control
Due to this feature, disabling SYSRQ support isn't very relevant since we disable USB at a hardware and software level anyway.
Here's our software-level USB protection infrastructure in the kernel:
GrapheneOS/kernel_common-6.6@777f92a
GrapheneOS/kernel_common-6.6@7da1fe7
GrapheneOS/kernel_common-6.6@57b0d1c
GrapheneOS/kernel_common-6.6@1b31f2c
Hardware-level USB-C and pogo pins protection infrastructure:
https://github.com/GrapheneOS/kernel_google-modules_soc_gs/commits/14/ and
https://github.com/GrapheneOS/kernel_gs/commits/14/ (USB-C driver)
https://github.com/GrapheneOS/kernel_devices_google_tangorpro/commits/14/ (pogo pins driver)
The userspace part is spread across several repositories, at least these:
https://github.com/GrapheneOS/platform_frameworks_base/commits/14/ (tiny portion of our changes there are relevant)
https://github.com/GrapheneOS/platform_system_sepolicy/commits/14/ (small portion of our changes there are relevant)
https://github.com/GrapheneOS/platform_packages_apps_Settings/commits/14/ (tiny portion of our changes there are relevant)
https://github.com/GrapheneOS/device_google_gs101/commits/14/ (small portion of our changes there are relevant)
https://github.com/GrapheneOS/device_google_gs201/commits/14/ (small portion of our changes there are relevant)
https://github.com/GrapheneOS/device_google_zuma/commits/14/ (small portion of our changes there are relevant)
Just as an example of one of our major features which involves kernel changes. There are others, and we try to put as much as possible in SELinux, etc. as possible rather than changing the kernel so there's not really that much there especially since we try to upstream stuff.
from kernel-hardening-checker.
There are GKI repositories for 5.10, 5.15, 6.1 and 6.6 but soon only the 6.1 and 6.6 ones will be relevant once Pixels all move to 6.1 which hopefully happens sooner rather than later. 6th/7th gen Pixels have out-of-tree drivers built from kernel/gs (kernel_gs) but 8th gen onwards have moved to having small repositories used with the GKI common kernel repository instead rather than both the common kernel repository for the kernel image / generic modules and another device kernel repository. Will go away for 6th/7th gen Pixels when they move to a newer kernel. Anyway, it's spread out more than you'd probably think. We've also been trying to do as much as we can via SELinux, seccomp-bpf and userspace code rather than patching the kernel when not necessary. When things get a bit cleaner when Pixels move to newer GKI branches and the last device kernel repository is gone (kernel_gs), we'll probably start making more kernel changes again such as making our hardened allocator with a best in class MTE implementation as we did in userspace.
from kernel-hardening-checker.
Related Issues (20)
- 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
- Add the `with care` column
- Relatively low code coverage in the engine unit test
- Implement the `CONFIG_ARCH_MMAP_RND_COMPAT_BITS` check
- New kconfig SECURITY_PROC_MEM_RESTRICT_WRITES HOT 1
- Add kconfig option CONFIG_CFI_AUTO_DEFAULT
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.