Repository navigation
document sysctl settings / kernel parameters using KSPP=yes / KSPP=no #256
Description
Activity
Yes this is a good idea.
Not sure what would be the best and most clear presentation style.
As a random example where to insert the KSPP recommendation notice:
## Enable ASLR for mmap base, stack, VDSO pages, and heap. ## Heap randomization can lead to breakages with legacy applications. ## ## https://en.wikipedia.org/wiki/Address_space_layout_randomization#Linux ## kernel.randomize_va_space=2Top:
## KSPP=yes ## ## Enable ASLR for mmap base, stack, VDSO pages, and heap. ## Heap randomization can lead to breakages with legacy applications. ## ## https://en.wikipedia.org/wiki/Address_space_layout_randomization#Linux ## kernel.randomize_va_space=2Bottom:
## Enable ASLR for mmap base, stack, VDSO pages, and heap. ## Heap randomization can lead to breakages with legacy applications. ## ## https://en.wikipedia.org/wiki/Address_space_layout_randomization#Linux ## ## KSPP=yes ## kernel.randomize_va_space=2Or some other alternative?
I guess below is more user friendly?
Maybe later we'll add more (machine-readable) or other metadata.
Ok sounds good.
- How should we handle partial compliance with KSPP?
For example, for
ptrace(), KSPP recommends=3.Current:
## Restrict usage of the ptrace() system call to only processes with CAP_SYS_PTRACE. ... ## kernel.yama.ptrace_scope=2Proposal 1:
## Restrict usage of the ptrace() system call to only processes with CAP_SYS_PTRACE. ... ## ## KSPP=partial (KSSP recommends the stricter setting kernel.yama.ptrace_scope=3.) ## kernel.yama.ptrace_scope=2Proposal 2:
## Restrict usage of the ptrace() system call to only processes with CAP_SYS_PTRACE. ... ## ## KSPP=partial ## KSSP recommends the stricter setting kernel.yama.ptrace_scope=3. ## kernel.yama.ptrace_scope=2Which one would be better? I would personally go with the second.
- Another thing would be the question of equivalence between CONFIGs and kernel boot parameters.
For example, for IOMMU, KSPP currently has:
# Force IOMMU TLB invalidation so devices will never be able to access stale data contents (or set "iommu.passthrough=0 iommu.strict=1" at boot) CONFIG_IOMMU_SUPPORT=y CONFIG_IOMMU_DEFAULT_DMA_STRICT=y # CONFIG_IOMMU_DEFAULT_PASSTHROUGH is not set ... # Enable chip-specific IOMMU support. CONFIG_INTEL_IOMMU=y CONFIG_INTEL_IOMMU_DEFAULT_ON=y CONFIG_INTEL_IOMMU_SVM=y CONFIG_AMD_IOMMU=y CONFIG_AMD_IOMMU_V2=y ... # Enable chip-specific IOMMU support. CONFIG_INTEL_IOMMU=y CONFIG_INTEL_IOMMU_DEFAULT_ON=y ... # Force IOMMU TLB invalidation so devices will never be able to access stale data contents (see CONFIG_IOMMU_DEFAULT_DMA_STRICT=y above). iommu.passthrough=0 iommu.strict=1We have:
## Enable CPU manufacturer-specific IOMMU drivers to protect against DMA attacks. ## GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX amd_iommu=force_isolation" GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX intel_iommu=on" ## Enable and force use of IOMMU translation to protect against DMA attacks. ## Strictly force DMA unmap operations to synchronously invalidate IOMMU hardware TLBs. ## Ensures devices will never be able to access stale data contents. ## ## https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit ## https://en.wikipedia.org/wiki/DMA_attack ## https://lenovopress.lenovo.com/lp1467.pdf ## GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX iommu=force" GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX iommu.passthrough=0" GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX iommu.strict=1"Should we still treat our settings as "KSPP=yes"?
My opinion is that we probably should say they are similar enough.
However, a valid argument can be made saying that kernel compilation with the CONFIGs sets a far higher standard and so we should not consider our approach equivalent.
KSPP=partialis nice.Should we still treat our settings as "KSPP=yes"?
Yes, until we hear a strong argument for the contrary.
However, a valid argument can be made saying that kernel compilation with the CONFIGs sets a far higher standard and so we should not consider our approach equivalent.
Right. That we can address by having a good definition what
KSPP=is supposed to mean.Reacted by raja-grewalIs this complete?
Yes it should be good for now.
Just for the record there are 4 areas where we do not adhere to the KSPP.
https://kspp.github.io/Recommended_SettingsPartial compliance:
sysctl kernel.yama.ptrace_scope=3
Disable
ptrace()entirely #242. Can easily enable.sysctl kernel.panic=-1
Force immediate reboot upon a kernel panic #264 #268. Can enable but may cause system crashes.
sysctl user.max_user_namespaces=0
Disable user namespaces entirely #263. Unadvisable due to numerous potential breakages.
Non-compliance:
sysctl fs.binfmt_misc.status=0
Disable registering interpreters for miscellaneous binary formats #249 #267. Currently unadvisable due to breakage with Firefox.
Rewritten your comment a bit and added to readme.
- added a commit that references this issue
on Sep 5, 2024
Would be useful if each setting was documented.
Meaning, as recommended by KSPP.
Not mentioned by KSPP.