search

Kicksecure / security-misc

Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings - https://www.kicksecure.com/wiki/Security-misc
https://www.kicksecure.com/wiki/Impressum
Other
513 stars 50 forks source link

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

Closed adrelanos closed 1 month ago

adrelanos commented 2 months ago

Would be useful if each setting was documented.

KSPP=yes

Meaning, as recommended by KSPP.

KSPP=no

Not mentioned by KSPP.

raja-grewal commented 2 months ago

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 commented 2 months ago

I guess below is more user friendly?

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

raja-grewal commented 2 months ago

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.

  1. 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 commented 2 months ago

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 commented 1 month ago

Is this complete?

raja-grewal commented 1 month ago

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 https://github.com/Kicksecure/security-misc/pull/242. Can easily enable.

  1. sysctl kernel.panic=-1

Force immediate reboot upon a kernel panic https://github.com/Kicksecure/security-misc/pull/264 https://github.com/Kicksecure/security-misc/pull/268. Can enable but may cause system crashes.

  1. sysctl user.max_user_namespaces=0

Disable user namespaces entirely https://github.com/Kicksecure/security-misc/pull/263. Unadvisable due to numerous potential breakages.

Non-compliance:

  1. sysctl fs.binfmt_misc.status=0

Disable registering interpreters for miscellaneous binary formats https://github.com/Kicksecure/security-misc/pull/249 https://github.com/Kicksecure/security-misc/issues/267. Currently unadvisable due to breakage with Firefox.

adrelanos commented 1 month ago

Rewritten your comment a bit and added to readme.