document sysctl settings / kernel parameters using KSPP=yes / KSPP=no

[adrelanos]

Would be useful if each setting was documented.

KSPP=yes

Meaning, as recommended by KSPP.

KSPP=no

Not mentioned by KSPP.

[raja-grewal]

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=2

Top:

## 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=2

Bottom:

## 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=2

Or some other alternative?

[adrelanos]

I guess below is more user friendly?

Maybe later we'll add more (machine-readable) or other metadata.

[raja-grewal]

Ok sounds good.

1. 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=2

Proposal 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=2

Proposal 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=2

Which one would be better? I would personally go with the second.

2. 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=1

We 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.

[adrelanos]

KSPP=partial is 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.

[adrelanos]

Is this complete?

[raja-grewal]

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_Settings

Partial compliance:

1. sysctl kernel.yama.ptrace_scope=3

Disable ptrace() entirely #242. Can easily enable.

2. sysctl kernel.panic=-1

Force immediate reboot upon a kernel panic #264 #268. Can enable but may cause system crashes.

3. sysctl user.max_user_namespaces=0

Disable user namespaces entirely #263. Unadvisable due to numerous potential breakages.

Non-compliance:

4. sysctl fs.binfmt_misc.status=0

Disable registering interpreters for miscellaneous binary formats #249 #267. Currently unadvisable due to breakage with Firefox.

[adrelanos]

Rewritten your comment a bit and added to readme.