| View previous topic :: View next topic |
| Author |
Message |
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
 Posted: Sun May 10, 2020 7:45 pm Post subject: B2 Manuelle Konfiguration des Kernels II |
 |
|
(Dieser Post ist Teil einer Installation-Anleitung. Falls nicht schon geschehen lies bitte: Installation Guide for Paranoid Dummies)
B.2 Manuelle Konfiguration des Kernels II.
A. Hardened Kernel I.
Wie schon in A.2 angedroht, wollen wir die Empfehlungen aus
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
umsetzen. Eine davon ist den Modul Support des Kernels auszuschalten. Wenn alle Module fest in den Kernel reincompiliert wurden, haben wir einen monolithischen Kernel. Welche Vorteile bringt das ?
1. Es ist sicherer ! Wenn der Kernel keine Module laden kann, sind alle Rootkits die das nutzen / benötigen schon mal ausgesperrt. Falls Du jetzt einwendest: Moment, dafür gibt es doch signierte Kernel Module, stimmt das zwar - aber genau das können wir uns doch sparen ! Dieses hier:
https://wiki.gentoo.org/wiki/Signed_kernel_module_support
ist eigentlich nur für Anwender gedacht, die eben keine manuelle Kernel Konfig machen können/wollen (also eigentlich für binäre Distributionen, die halt nur mit Modulen arbeiten können).
2. Fast alles was mein Kernel nutzt, will ich doch eh immer haben: Grafik, Tastatur, Maus, Ethernet, Sound, USB, u.s.w. Es macht also keinen Unterschied ob dies gleich mit dem Kernel oder während des Bootvorgangs als Modul geladen wird (leider liegt der Zeitvorteil auch nur im millisek. Bereich; wir gewinnen also fast nichts).
3. Dafür sparen wir uns einen ganzen Befehl bei der nächsten Kernel Compilierung: "make modules_install" 
Hat es Nachteile ?
1. Falls Du die Sorge hast, dass Du dann ja nicht mehr ausprobieren kannst, welche Module der Kernel lädt, wenn Du z.B. ein neues Programm installierst, welches irgendein Crypto-Modul aus der Cryptographic API benötigt, kann ich Dich beruhigen. Ich habe selbst, zu diesem Zweck den "Enable loadable module support" im Kernel wieder aktiviert, alle Module mit "M" reingenommen und geprüft, welches der Kernel dann geladen hat. Ein monolithischer Kernel kann zu solchen Zwecken jederzeit wieder temporär zurückkonfiguriert werden.
2. Ja, es gibt einen kleinen Nachteil: Es gibt einige wenige Module, die selten geladen werden, wie z.B. für das CD-ROM (außer Du benutzt das auch täglich). Dieses wird nun unnötig mitgeladen und verbrät auch ein paar kB Speicher (aber was sind schon ein paar kB bei den heutigen Speichergrößen im Gigabyte-Bereich). Das gleiche ist mir passiert mit einem USB-Stick eines Kollgen, den er unter Windows mit NTFS formatiert hat (ok, da hatte ich nichtmal vorher das NTFS-Modul als Modul drin). Du musst also nicht nur, die derzeit mit "lsmod" als geladen gemeldeten Module reinnehmen, sondern auch prüfen, was der Kernel sonst noch lädt, wenn Du mal nichtalltägliches tust (das waren bei mir aber nur diese zwei Dinge).
Die Entscheidung liegt also bei Dir, ob Du das machen möchtest oder lieber den Signed_kernel_module_support ausprobieren willst. Mir hat ein Blick in die Anleitung dazu genügt, um ...
Du kannst/solltest dann auch in der make.conf ein USE-Flag abwählen mit "-kmod" (falls nicht, ists aber auch nicht schlimm; Du bekomst dann halt eine harmlose Fehlermeldung wenn Du "lspci" aufrufst). Das Package "kmod" wollen wir aber nicht rausschmeißen, um uns die Möglichkeit zu erhalten temporär wieder den Modul Support einzuschalten (also nicht das hier machen: https://wiki.gentoo.org/wiki/Kernel_Modules#Going_completely_module-less ).
Bei der Übertragung der o.g. Empfehlungen in Deinen Kernel kann ich Dir eigentlich nicht mehr groß helfen (*) (**), möchte Dich aber darauf hinweisen, dass am Ende auch noch ein paar Kernel Parameter über sysctls geladen werden sollen. Diese kannst Du aber einfach unverändert mittels copy/paste reinkopieren in:
| Code: | | # nano -w /etc/sysctl.conf |
Die Kernel Command Line Options habe ich NICHT übernommen. Warum sollte ich Hyperthreading/SMT mit "nosmt" ausschalten, wenn ich keine virtuellen Maschinen habe ? (Dies wäre bei Servern anders zu bewerten). Anderes ist bereits in der Kernel Konfig drin; und bei "slub_debug=ZF" ist mir die Performance ausnahmsweise wichtiger.
Diesen Link darf man ruhig öfter mal besuchen - zumindest nach größeren Kernel-Versions-Änderungen - die halten das ziemlich aktuell.
* Falls Du Probleme hast das Linux Security Modul (LSM) "YAMA" zu finden, dann lies - und mache - gleich mal das 1. Kapitel "Vorbereitung" aus C.2 (die dort mit "!!!" markierten Zeilen erhältst Du genauso wenn Du einen Teil der Empfehlungen von hier umsetzt).
** Edit 2021-07-08: Falls Du Kernel-5.10.48-r1 (oder neuer) benutzt (oder 5.12.15 oder neuer; oder 5.13.0-r1 oder neuer), siehe Dir gleich mal Post Nr.4 in diesem Thread an 
-----
Edit 2024-04-26: Falls Du diesen Thread erstmalig gefunden hast, dann lese ihn Dir ruhig durch ... ohne gleich etwas zu machen, DENN die ganzen KSPP Optionen werde ich nur noch im Wiki weiterführen. Der Link ist:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Kernel_Hardening_with_KSPP
-----
B. Stub-Kernel
UEFI kann nicht nur einen Bootloader wie z.B. den Grub starten, sondern auch gleich direkt unseren Kernel, wenn wir aus unseren Kernel einen Stub Kernel machen. Das ist wirklich sehr einfach ! Allerdings ist die Beschreibung im Wiki m.M. eher verwirrend (und in einem Punkt falsch).
Edit-2023-09-24: Der letzte Satz stimmt nicht mehr ... weil ich heute diesen Wiki Artikel umgeschrieben habe 
1. Mach einfach nur das Kapitel "Kernel-Konfiguration" aber nicht das Kapitel "Installation" aus:
https://wiki.gentoo.org/wiki/EFI_stub_kernel
Außerdem habe ich vorher mal bei mir in /var/log/messsages meinen letzten Bootvorgang geprüft und dort war in der "command line" hinter "root=/dev/sda3" noch ein "ro" (für read-only) angegeben. Das habe ich dann auch übernommen. Enable bitte auch zusätzlich den letzten Parameter (... overrides boot loader ...).
| Code: | Processor type and features --->
[*] Built-in kernel command line
(root=PARTUUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ro) Built-in kernel command string
[*] Built-in command line overrides boot loader arguments |
Folgendes habe ich in keiner Gentoo Dokumentation gefunden, ist aber bei manchen Mainboards zwingend notwendig (enable es einfach, dann bist Du auf der sicheren Seite):
| Code: | Device Drivers -> Graphics Support -> Frame Buffer Devices ->
<*> Support for frame buffer devices --->
[*] EFI-based Framebuffer Support |
Du solltest auch keine anderen Framebuffer-Devices enabled haben - außer dem Simple-FB als Fallback (Details: https://forums.gentoo.org/viewtopic-t-1144293-highlight-.html)
Natürlich musst Du diese Änderungen im Kernel wieder compilieren (make (+ ggf. make modules_install falls Du KEINEN monolithischen Kernel gemacht hast)); jedoch muss dieser nicht wie sonst installiert werden (make install), da wir das jetzt gleich anders machen.
2. Erstelle ein neues Verzeichnis "Boot" in "/boot/EFI". Also "/boot/EFI/Boot" (vielleicht ist das "EFI" bei Dir klein geschrieben; dann lass das so und passe meine Befehle an Dein kleines efi an). Kopiere dann Deinen Kernel nach "/boot/EFI/Boot/bzImage.efi" OHNE Versions-Nr.
| Code: | # mount /boot
# cd /boot
# ls
# cd EFI
# mkdir Boot
# cp /usr/src/linux/arch/x86/boot/bzImage /boot/EFI/Boot/bzImage.efi |
3. Mache nun eine Abfrage der Boot-Einträge die Dein UEFI bisher kennt. Es sollte mindestens ein Eintrag vom Grub (="grubx64.efi") erscheinen mit dem Titel "gentoo" (diesen Titel darfst Du deshalb im nächsten Schritt nicht nochmal verwenden).
Edit 2022-09-04: Mit efibootmgr Version 18 genügt ein:
| Code: | # efibootmgr
- oder
# efibootmgr -u |
4. Jetzt machen wir unseren Kernel dem UEFI bekannt: Für sdX musst Du Deine Bootplatte und für Y Deine Boot-Partition verwenden - wäre nach einer Grundinstallation nach A.1.4 also: "-d /dev/sda -p 1". Als Name/Titel (-L) kannst Du verwenden, was Dir in den Sinn kommt (sollte nur nicht zu lang sein; das ist nämlich der Titel den Du dann später im UEFI-BIOS-Bootauswahlmenü finden/sehen wirst). Alles hinter dem Parm -l muß in der richtigen Groß-/Kleinschreibung sein und auch die Backslashe statt unsere Linux-Forslashe müssen so sein (mieses Deutsch) (JA, da steht KEIN \boot\EFI\Boot\bzImage.efi. Es ist so wie es hier unten steht schon definitiv so richtig). Überprüfe gleich danach noch einmal die Boot-Einträge !
Hinweis zum Verständnis: Der efibootmgr installiert gar nichts; er redet nur mit Deinem UEFI-BIOS (über das vom Linux Kernel bereitgestellte efivarfs) und bittet um einen neuen Boot-Eintrag in Deinem UEFI-BIOS (außerdem soll dieser neue Eintrag auch gleich der erste in der Boot-Reihenfolge sein).
| Code: | # efibootmgr -c -d /dev/sdX -p Y -L "SECLINUX" -l '\EFI\Boot\bzImage.efi'
# efibootmgr -v |
5. Boote jetzt mal durch und prüfe, ob der Grub noch erscheint oder das BIOS gleich den Kernel startet. Falls gar nicht gebootet wird, muss Du ins BIOS rein und die Reihenfolge zurück ändern (auf Grub-Boot) und den Fehler suchen. Ach ja, der Link dazu:
https://wiki.gentoo.org/wiki/Efibootmgr
Wenn Du mich jetzt fragst, was das sicherheitstechnisch bringt, muß ich Dich enttäuschen. Nichts. Wir sparen uns nur die Verwendung vom Grub. Allerdings ist dies VORAUSSETZUNG für SecureBoot, welches ich in B.3 beschreibe. Falls Du kein SecureBoot benötigst und den Grub magst, gibt es keinen Grund das zu machen. Ein letzter Hinweis: Keine Sorge, Grub startet auch einen Stub-Kernel wie einen normalen. Das bedeutet, Du kannst - als Fallback - weiterhin so einen Stub-Kernel (zusätzlich) mit "make install + grub-mkconfig" installieren. Ich mache das sogar auch so:
Wenn ein neuer Kernel kommt, wird der nach folgendem Cheat Sheet installiert. Wenn der Bootvorgang erfolgreich war, lasse ich ihn dann auch für den Grub zu. Falls der neue Kernel nicht bootet, gehe ich in das BIOS stelle die Boot-Reihenfolge zurück auf den Grub und boote damit den letzten erfolgreichen Kernel. Mein Cheat Sheet dafür:
| Code: | Neue Kernel-Version:
--------------------
# emerge -1uvDp gentoo-sources
# mount /boot
# cd /usr/src/linux-X.Y.Z-gentoo
# cp /usr/src/linux/.config .
# make oldconfig
# make -j 8
# cp arch/x86/boot/bzImage /boot/EFI/Boot/bzImage.efi
(# make modules_install)
# cp .config /etc/MY/config-X-Y-Z
# eselect kernel list
# eselect kernel set
# umount /boot
Änderung der Konfiguration des bestehenden Kernels:
---------------------------------------------------
# mount /boot
# cd /usr/src/linux
# make menuconfig
# make -j 8
# cp arch/x86/boot/bzImage /boot/EFI/Boot/bzImage.efi
(# make modules_install)
# cp .config /etc/MY/config-X-Y-Z-revA
# umount /boot
Nach erfolgreichem Boot eines neuen Kernels:
--------------------------------------------
# mount /boot
# cd /usr/src/linux
# make install
# grub-mkconfig -o /boot/grub/grub.cfg
# umount /boot |
P.S.: Vergiss nicht, ab und zu mal wieder alte Kernels aus Deinem /boot-Verzeichnis zu löschen ... und falls Du wirklich noch mit Modulen arbeiten solltest, schau auch mal in /lib/modules/ rein ...
.
_________________
https://wiki.gentoo.org/wiki/User:Pietinger
Last edited by pietinger on Fri Apr 26, 2024 11:24 pm; edited 51 times in total |
|
| Back to top |
|
 |
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Sun Jul 12, 2020 2:52 pm Post subject: Hardened Kernel II. |
|
|
Hardened Kernel II.
Dank eines Beitrags von @maxxim (5. Post) in diesem Thread:
https://forums.gentoo.org/viewtopic-t-1095744-highlight-.html
kopiere ich mal die zwei wichtigsten Links daraus hierher.
Eine weitere Quelle zum Härten des Kernels ist eine französiche Linux-Distribution:
https://docs.clip-os.org/clipos/kernel.html#configuration
(Versuche aber nicht alles von dort umzusetzen - das geht nicht. Lies vorher den o.g. Thread)
... aaaber noch viel besser ... ein Skript welches die diversen Empfehlungen zusammenfasst und gegen Deine .config prüft:
( https://github.com/a13xp0p0v/kconfig-hardened-check )
Edit 2023-10-19: Seit heute kann man das Tool nun auch emergen; es hat aber schon den neuen Namen:
| Code: | | # ACCEPT_KEYWORDS="~amd64" emerge -pv kernel-hardening-checker |
Aufruf erfolgt - noch - mit dem alten Namen:
| Code: | | # kconfig-hardened-check -c /usr/src/linux/.config |
und die Ausgabe sieht bei mir so aus:
| Code: | [+] Kconfig file to check: /usr/src/linux/.config
[+] Detected architecture: X86_64
[+] Detected kernel version: 6.1
[+] Detected compiler: GCC 130201
=========================================================================================================================
option name | type |desired val | decision | reason | check result
=========================================================================================================================
CONFIG_BUG |kconfig| y |defconfig | self_protection | OK
CONFIG_SLUB_DEBUG |kconfig| y |defconfig | self_protection | OK
CONFIG_THREAD_INFO_IN_TASK |kconfig| y |defconfig | self_protection | OK
CONFIG_GCC_PLUGINS |kconfig| y |defconfig | self_protection | OK
CONFIG_IOMMU_SUPPORT |kconfig| y |defconfig | self_protection | OK
CONFIG_STACKPROTECTOR |kconfig| y |defconfig | self_protection | OK
CONFIG_STACKPROTECTOR_STRONG |kconfig| y |defconfig | self_protection | OK
CONFIG_STRICT_KERNEL_RWX |kconfig| y |defconfig | self_protection | OK
CONFIG_STRICT_MODULE_RWX |kconfig| y |defconfig | self_protection | OK: CONFIG_MODULES is "is not set"
CONFIG_REFCOUNT_FULL |kconfig| y |defconfig | self_protection | OK: version >= 5.5
CONFIG_RANDOMIZE_BASE |kconfig| y |defconfig | self_protection | OK
CONFIG_VMAP_STACK |kconfig| y |defconfig | self_protection | OK
CONFIG_DEBUG_WX |kconfig| y |defconfig | self_protection | OK
CONFIG_WERROR |kconfig| y |defconfig | self_protection | OK
CONFIG_X86_MCE |kconfig| y |defconfig | self_protection | OK
CONFIG_X86_MCE_INTEL |kconfig| y |defconfig | self_protection | OK
CONFIG_X86_MCE_AMD |kconfig| y |defconfig | self_protection | FAIL: is not found
CONFIG_MICROCODE |kconfig| y |defconfig | self_protection | OK
CONFIG_RETPOLINE |kconfig| y |defconfig | self_protection | OK
CONFIG_SYN_COOKIES |kconfig| y |defconfig | self_protection | OK
CONFIG_X86_SMAP |kconfig| y |defconfig | self_protection | OK: version >= 5.19
CONFIG_X86_UMIP |kconfig| y |defconfig | self_protection | OK
CONFIG_PAGE_TABLE_ISOLATION |kconfig| y |defconfig | self_protection | OK
CONFIG_RANDOMIZE_MEMORY |kconfig| y |defconfig | self_protection | OK
CONFIG_INTEL_IOMMU |kconfig| y |defconfig | self_protection | OK
CONFIG_AMD_IOMMU |kconfig| y |defconfig | self_protection | FAIL: "is not set"
CONFIG_BUG_ON_DATA_CORRUPTION |kconfig| y | kspp | self_protection | OK
CONFIG_SCHED_STACK_END_CHECK |kconfig| y | kspp | self_protection | OK
CONFIG_SLAB_FREELIST_HARDENED |kconfig| y | kspp | self_protection | OK
CONFIG_SLAB_FREELIST_RANDOM |kconfig| y | kspp | self_protection | OK
CONFIG_SHUFFLE_PAGE_ALLOCATOR |kconfig| y | kspp | self_protection | OK
CONFIG_FORTIFY_SOURCE |kconfig| y | kspp | self_protection | OK
CONFIG_DEBUG_LIST |kconfig| y | kspp | self_protection | OK
CONFIG_DEBUG_VIRTUAL |kconfig| y | kspp | self_protection | OK
CONFIG_DEBUG_SG |kconfig| y | kspp | self_protection | OK
CONFIG_DEBUG_CREDENTIALS |kconfig| y | kspp | self_protection | OK
CONFIG_DEBUG_NOTIFIERS |kconfig| y | kspp | self_protection | OK
CONFIG_INIT_ON_ALLOC_DEFAULT_ON |kconfig| y | kspp | self_protection | OK
CONFIG_KFENCE |kconfig| y | kspp | self_protection | OK
CONFIG_ZERO_CALL_USED_REGS |kconfig| y | kspp | self_protection | OK
[...] |
Ein MUST HAVE !
Last edited by pietinger on Thu Oct 19, 2023 3:40 am; edited 1 time in total |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Wed Jul 07, 2021 10:11 pm Post subject: Neue Kernel-Parameter zum Setzen der KSPP-Empfehlungen |
|
|
Neue Kernel-Parameter zum Setzen der KSPP-Empfehlungen
Seit 5.10.48-r1 (respektive die äquivalenten Versionen aus den höheren Serien) haben wir in der "make menuconfig" in der Sektion "Gentoo Linux" zwei neue Optionen, die uns einiges an Arbeit abnehmen. Diese erscheinen aber erst, wenn gewisse Optionen DISABLED sind. Meine Empfehlung zur Vorgehensweise:
1. Drucke Dir den Inhalt von https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings aus (oder kopiere alles in eine Text-Datei).
2. Mache als erstes alle Optionen die DISABLED werden sollen. Das musst Du halt noch selbst machen; aber es sind hauptsächlich Überprüfungen, da die meisten Optionen entweder bereits von Haus auf disabled sind, oder schon von uns disabled wurden, wie z.B. 32-bit-Unterstützung oder Hibernation (haben wir bereits in A.2 gemacht). Streiche diese dann auf Deinem Ausdruck durch (oder lösche die Zeilen in Deiner Text-Datei)
Warum erscheinen die neuen Optionen erst dann ? Weil diese in der Kernel-Konfiguration abgesichert wurden über:
| Code: | | Depends on: GENTOO_LINUX [=y] && !ACPI_CUSTOM_METHOD [=n] && !COMPAT_BRK [=n] && !DEVKMEM [=n] && !PROC_KCORE [=n] && !COMPAT_VDSO [=n] && !KEXEC [=n] && !HIBERNATION [=n] && !LEGACY_PTYS [=n] && !X86_X32 [=n] && !MODIFY_LDT_SYSCALL [=n] |
Anders herum wird auch ein Schuh daraus: Solltest Du die beiden neuen Optionen bereits sehen, weisst Du jetzt natürlich auch schon, dass bereits alle diese Optionen disabled sind, und Du diese nicht mehr überprüfen musst, sondern gleich auf Deinem Ausdruck streichen kannst.
Edit 2022-12-29: Falls Du Probleme hast diese "Depends"-Zeile zu interpretieren, schau doch einfach mal das an:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Kernel_Hardening_with_KSPP#Minimum_kernel_configuration_to_get_both_KSPP_options
Ein weiterer Grund warum Du Dir den Inhalt dieser KSPP-Webseite sichern solltest ist, damit Du einen Diff machen kannst, wenn diese wieder mal aktualisiert wird (damit Du dann siehst was dazu gekommen ist). Ich habe inzwischen 7 Versionen dieser Seite
Achtung: Das sind nicht alle; da ist noch mehr zum disabeln da; disable wirklich alles - auch CONFIG_DEVMEM (ohne "K")!
3. Jetzt gehst Du in die neue Option und enablest diese beiden:
| Code: | Gentoo Linux --->
[*] Kernel Self Protection Project --->
[*] Enable Kernel Self Protection Project Recommendations
[*] X86_64 KSPP Settings |
4. Schaue in den Hilfe-Text von beiden Optionen. Du siehst dort, was wir gerade automatisch alles enabled haben. Es ist unübersichtlich ...
5. Schaue Dir dann diese Datei an:
| Code: | ! Du bist ja gerade in /usr/src/linux oder in /usr/src/linux-5.XX.YY
# cd distro
# less Kconfig |
Das letzte Drittel dieser Datei hat (Stand:heute) folgenden Inhalt:
| Code: | [...]
menu "Enable Kernel Self Protection Project Recommendations"
visible if GENTOO_LINUX
config GENTOO_KERNEL_SELF_PROTECTION
bool "Architecture Independant Kernel Self Protection Project Recommendations"
depends on GENTOO_LINUX && !ACPI_CUSTOM_METHOD && !COMPAT_BRK && !DEVKMEM && !PROC_KCORE && !COMPAT_VDSO && !KEXEC && !HIBERNATION && !LEGACY_PTYS && !X86_X32 && !MODIFY_LDT_SYSCALL
select BUG
select STRICT_KERNEL_RWX
select DEBUG_WX
select STACKPROTECTOR
select STACKPROTECTOR_STRONG
select STRICT_DEVMEM if DEVMEM=y
select IO_STRICT_DEVMEM if DEVMEM=y
select SYN_COOKIES
select DEBUG_CREDENTIALS
select DEBUG_NOTIFIERS
select DEBUG_LIST
select DEBUG_SG
select BUG_ON_DATA_CORRUPTION
select SCHED_STACK_END_CHECK
select SECCOMP
select SECCOMP_FILTER
select SECURITY_YAMA
select SLAB_FREELIST_RANDOM
select SLAB_FREELIST_HARDENED
select SHUFFLE_PAGE_ALLOCATOR
select SLUB_DEBUG
select PAGE_POISONING
select PAGE_POISONING_NO_SANITY
select PAGE_POISONING_ZERO
select INIT_ON_ALLOC_DEFAULT_ON
select INIT_ON_FREE_DEFAULT_ON
select VMAP_STACK
select REFCOUNT_FULL
select FORTIFY_SOURCE
select SECURITY_DMESG_RESTRICT
select PANIC_ON_OOPS
select CONFIG_GCC_PLUGINS
select GCC_PLUGIN_LATENT_ENTROPY
select GCC_PLUGIN_STRUCTLEAK
select GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
select GCC_PLUGIN_STACKLEAK
select GCC_PLUGIN_RANDSTRUCT
select GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
help
Recommended Kernel settings based on the suggestions from the Kernel Self Protection Project
See: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
Note, there may be additional settings for which the CONFIG_ setting is invisible in menuconfig due
to unmet dependencies. Search for GENTOO_KERNEL_SELF_PROTECTION_{X86_64, ARM64, X86_32, ARM} for
dependency information on your specific architecture.
Note 2: Please see the URL above for numeric settings, e.g. CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
for X86_64
menu "Architecture Specific Self Protection Project Recommendations"
config GENTOO_KERNEL_SELF_PROTECTION_X86_64
bool "X86_64 KSPP Settings"
depends on !X86_MSR && X86_64
default n
select RANDOMIZE_BASE
select RANDOMIZE_MEMORY
select LEGACY_VSYSCALL_NONE
select PAGE_TABLE_ISOLATION
config GENTOO_KERNEL_SELF_PROTECTION_ARM64
bool "ARM64 KSPP Settings"
depends on ARM64
default n
select RANDOMIZE_BASE
select ARM64_SW_TTBR0_PAN
select CONFIG_UNMAP_KERNEL_AT_EL0
config GENTOO_KERNEL_SELF_PROTECTION_X86_32
bool "X86_32 KSPP Settings"
depends on !X86_MSR && !MODIFY_LDT_SYSCALL && !M486 && X86_32
default n
select HIGHMEM64G
select X86_PAE
select RANDOMIZE_BASE
select PAGE_TABLE_ISOLATION
config GENTOO_KERNEL_SELF_PROTECTION_ARM
bool "ARM KSPP Settings"
depends on !OABI_COMPAT && ARM
default n
select VMSPLIT_3G
select STRICT_MEMORY_RWX
select CPU_SW_DOMAIN_PAN
endmenu
endmenu
endmenu |
Du erkennst die Gemeinsamkeiten zu den Informationen in der Hilfe und siehst nun alle SELECTS übersichtlich. Alle diese haben wir soeben auf einen Streich enabled. Streiche alle diese auf Deinem Ausdruck weg und prüfe was übrig bleibt. Dies ist (Stand:heute) nur noch:
| Code: | | CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 |
6. Alle Übriggebliebenen musst Du nun ebenfalls wieder selbst in Deiner "make menuconfig" setzen. Zum Beispiel:
| Code: | Memory Management options --->
(65536) Low address space to protect from user allocation |
Edit 2023-01-23: Bevor Du dies machst, lese bitte alle nachfolgenden Posts, denn es ist inzwischen einiges dazu gekommen, was nun doch nicht automatisch durch unser Gentoo KSPP gesetzt wird. Falls Du noch keinen monolithischen Kernel hast, enable erstmal NICHT den LOCKDOWN ! (Lese einfach C.2 hierzu).
7. Fertig ! Nachdem Du den Kernel compiliert, installiert und per Reboot aktiviert hast, hast Du nun einen gehärteten Kernel. Vergiss aber nicht vorher noch die Kernel Parameter zu setzen, die über sysctls geladen werden sollen (siehe ersten Post) !
8. Falls Du meiner Emfehlung in A.3, den "spectre-meltdown-checker" zu installieren, gefolgt bist, kannst Du diesen gleich mal wieder anwerfen und prüfen ob es jetzt etwas "grüner" bei Dir aussieht
.
Last edited by pietinger on Mon Jan 23, 2023 9:09 pm; edited 5 times in total |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Wed Mar 30, 2022 11:13 pm Post subject: Neue Empfehlungen in KSPP |
|
|
Neue Empfehlungen in KSPP
Heute wurden die KSPP-Empfehlungen von Kees Cook aktualisiert und sind nun für alle Kernel der Serie 5.15.x aktuell. Ich fragte ihn auch, ob er die beiden Optionen wo ich mir unsicher war empfehlen kann:
| Code: | # CONFIG_SCHED_CORE is not set
# CONFIG_KFENCE is not set |
... und die Antwort war: "This looks reasonable to add as well, though it requires programs actually make use of it. Added!" (zu CONFIG_SCHED_CORE) und "Yeah, good idea. Added!" (zu CONFIG_KFENCE).
Edit 2022-05-12: Mit der heutigen Version 5.15.39 wurden alle neuen Empfehlungen eingearbeitet, außer "CONFIG_WERROR=y". Das muß man also immer noch selbst enabeln - falls es nicht bereits aufgrund meiner Empfehlungen im 1.Post von A.1 gemacht wurde (den ich zwischenzeitlich erweitert habe) Unsere Entwickler befürchten (zurecht) eine mögliche Inkompatibilität bei bestimmten Architekturen (Details siehe hier: https://bugs.gentoo.org/show_bug.cgi?id=841488 ):
| Code: | General setup --->
[*] Compile the kernel with warnings as errors |
Beim "make oldconfig" erscheint eine Frage die mit "Y" als default vorgegeben ist, die jedoch mit "n" beantwortet werden muß (dieser Fallback ist sicherheitskritisch und wird so gut wie nie benötigt):
| Quote: | | Allow usercopy whitelist violations to fallback to object size (HARDENED_USERCOPY_FALLBACK) [Y/n/?] (NEW) n |
Ich lasse meine ursprüngliche Info mal ausgegraut hier, falls es u.U. noch benötigt wird:
Wer nicht warten will, bis unsere Gentoo Developer die Datei /usr/src/linux/distro/Kconfig aktualisiert haben, kann diesen DIFF zur alten Version vom 15.09.2021 nutzen:
| Code: | # Randomize kernel stack offset on syscall entry (since v5.13).
CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y
# Enable sampling-based overflow detection. This is similar to KASAN coverage, but with almost zero runtime overhead.
CONFIG_KFENCE=y
# Do not ignore compile-time warnings (since v5.15)
CONFIG_WERROR=y
# 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_DEFAULT_DMA_STRICT=y
# Make scheduler aware of SMT Cores. Program needs to opt-in to using this feature with prctl(PR_SCHED_CORE).
CONFIG_SCHED_CORE=y
# Wipe all caller-used registers on exit from the function (reduces available ROP gadgets and minimizes stale data in registers)
CONFIG_ZERO_CALL_USED_REGS=y |
Ich habe ja bereits in einem Post in A.2 ("Update von 5.10.x auf 5.15.x") 4 dieser 6 Änderungen empfohlen; es bleiben also eigentlich nur die beiden obengenannten wo ich mir unsicher war.
P.S.: Ich habe gerade noch einmal die Optionen zwischen KSPP und unserer Gentoo Einstellung verglichen und musste feststellen, dass eine Option fehlt (die ich nur deshalb bei mir enabled habe, weil ich ja alle Optionen von KSPP bereits damals aktivierte als es noch gar nicht unsere Gentoo Optionen gab): Dies ist also auch noch manuell zu enablen:
| Code: | | CONFIG_HARDENED_USERCOPY=y |
P.P.S: Falls Du verzweifelt CONFIG_DEVKMEM suchst, um es zu disabeln ... das wirst Du mit 5.15 nicht mehr finden, da die Kernel Entwickler es komplett rausgeschmissen haben (die KSPP Settings gelten ja auch noch für ältere Versionen und ist deshalb noch drin).
Edit 2022-09-29: Mehr information über Kfence: https://docs.kernel.org/next/dev-tools/kfence.html
Last edited by pietinger on Thu Sep 29, 2022 1:16 pm; edited 1 time in total |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Fri Jun 10, 2022 9:41 pm Post subject: |
|
|
Kernel 5.15.46 (oder auch äquivalente Version der höheren Serien)
Wir haben wieder eine neue Kernel Option bezüglich der Sicherheit. Bei einem Update auf 5.15.46 erscheint bei "make oldconfig" diese Frage und sollte mit "y" beantwortet werden (default ist leider No).
| Code: | | Mitigate Straight-Line-Speculation (SLS) [N/y/?] (NEW) y |
In "make menuconfig" ist es hier zu finden:
| Code: | Processor type and features --->
[*] Mitigate Straight-Line-Speculation |
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Mon Aug 01, 2022 9:29 am Post subject: |
|
|
Update auf Kernel 5.15.58 (oder auch äquivalente Version der höheren Serien)
Vermutlich ist dieser Post gar nicht nötig, da alle neuen Optionen die beim "make oldconfig" abgefragt werden, bereits mit "Y" vorbelegt sind und einfach mit <return> übernommen werden können - und natürlich übernommen werden sollen
Wir haben nun einen ganz neuen Eintrag im Hauptmenü (=so sollte es bei Dir aussehen):
| Code: | [*] Mitigations for speculative execution vulnerabilities --->
-*- Remove the kernel mapping in user mode
[*] Avoid speculative indirect branches in kernel
[*] Enable return-thunks
[*] Enable IBRS on kernel entry
[*] Mitigate Straight-Line-Speculation |
(Der erste ist bei mir wegen Gentoo/KSPP schon hard enabled)
Dadurch ist die Lokation von "Mitigate Straight-Line-Speculation" nicht mehr in "Processor type and features" (wie noch im vorherigen Post beschrieben). |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Mon Aug 29, 2022 10:26 pm Post subject: |
|
|
Neue Empfehlung in KSPP
Es ist zwar schon ein paar Tage her, aber ich wollte erstmal sehen welche Auswirkungen es hat. Die einzige Neuerung die am 19.08.2022 in den KSPP Empfehlungen hinzukam war "landlock". Es gibt dazu auch einen Bug Eintrag:
https://bugs.gentoo.org/show_bug.cgi?id=865685
und es wurde schon für die 5.19-Serie in unseren Gentoo KSPP Einstellungen hinzugefügt. Vermutlich dürfte es demnächst auch für unser stable 5.15 hinzukommen. Wer nicht warten will:
| Code: | Security options --->
[*] Landlock support
(landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,bpf) Ordered list of enabled LSMs |
Die letzte Zeile ist speziell für eine Installation mit diesem Guide (ja, man könnte einiges weglassen, da nicht konfiguriert; ich möchte es aber als "Merker" drinlassen).
Es wurde empfohlen es als erstes in dieser Init Reihenfolge zu setzen.
Geben tut es das Teil schon seit 5.13 ... aber es muß halt auch vom jeweiligen Anwendungs-Programm unterstützt werden. Fragt mich jetzt bitte nicht, welche Applikation das schon nutzt. Ich vermute aber, dass alle Web-Browser sich das ganz schnell aneignen werden. Was die Performance betrifft konnte ich keine Verschlechterung feststellen. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Wed Oct 12, 2022 7:47 pm Post subject: |
|
|
Neue Empfehlungen in KSPP vom 11.10.2022
Seit gestern haben wir wieder neue Emfehlungen von KSPP. Diesmal etwas umfangreicher. Statt hier einen Diff reinzustellen, gehe ich auf die neuen Punkte einzeln ein.
1. Wir haben kein SELinux aktiviert, also benötigen wir die drei Einstellungen unter dem Menüpunkt "# Make sure SELinux cannot be disabled trivially." überhaupt nicht !
2. Den Lockdown haben wir bereits mit exakt den gleichen Einstellungen in C.2 gemacht. Wir können also den Menüpunkt "# Enable "lockdown" LSM for bright line between the root user and kernel memory." ebenso abhaken.
3. UBSAN ist neu hinzugekommen. Enable also alles folgende:
| Code: | Kernel hacking --->
Generic Kernel Debugging Instruments --->
[*] Undefined behaviour sanity checker ---> |
Hier war bei mir schon einiges aktiviert, was aber - laut KSPP - gar nicht nötig ist. So soll es aussehen wenn fertig:
| Code: | --- Undefined behaviour sanity checker
[*] On Sanitizer warnings, abort the running kernel code
[*] Perform array index bounds checking
[ ] Perform checking for bit-shift overflows
[ ] Perform checking for integer divide-by-zero
[ ] Perform checking for non-boolean values used as boolean
[ ] Perform checking for out of bounds enum values
[*] Enable instrumentation for the entire kernel |
4. IOMMU haben wir bereits in A.2 aktiviert - eine Überprüfung ist aber nicht verkehrt:
| Quote: | # Enable chip-specific IOMMU support.
CONFIG_INTEL_IOMMU=y
CONFIG_INTEL_IOMMU_DEFAULT_ON=y
CONFIG_INTEL_IOMMU_SVM=y
CONFIG_IOMMU_SUPPORT=y
CONFIG_IOMMU_DEFAULT_DMA_STRICT=y |
5. Diese beiden Optionen für EFI waren bei mir schon lange enabled ... es könnte aber sein, dass ich das nirgends erwähnt habe ...  ... Dank KSPP ist es nun auch amtlich
| Code: | Device Drivers --->
Firmware Drivers --->
EFI (Extensible Firmware Interface) Support --->
[*] Reset memory attack mitigation
[*] Clear Busmaster bit on PCI bridges during ExitBootServices() |
6. Folgendes wird für unsere Konfiguration eigentlich nicht benötigt ... Entscheide selbst, ob Du es willst:
| Quote: | # Enable feeding RNG entropy from TPM, if available.
CONFIG_HW_RANDOM_TPM=y
# Get as much entropy as possible from external sources. The Chacha mixer isn't vulnerable to injected entropy, so even
# malicious sources should not cause problems.
CONFIG_RANDOM_TRUST_BOOTLOADER=y
CONFIG_RANDOM_TRUST_CPU=y |
7. Dieses hier habe ich bereits im vorletzten (eigentlich noch einen davor) Post emfohlen - nun ist das auch amtlich
| Quote: | # Straight-Line-Speculation
CONFIG_SLS=y |
(Die Erweiterungen für ARM Geräte benötige ich natürlich nicht, möchte aber darauf hinweisen, falls Du so einen hast.) |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Sun Oct 16, 2022 9:32 am Post subject: |
|
|
Neue Empfehlungen in KSPP vom 15.10.2022
Schon wieder Neues ... oder vielleicht auch Altes ?
1. Folgende Option ist neu hinzugekommen, hatte ich aber schon seit Urzeiten in meiner Konfig. Könnte also sein, dass dies schon mal empfohlen war und dann mal rausfiel ...
| Quote: | | CONFIG_DEBUG_VIRTUAL=y |
Bei der Gelegenheit habe ich alle meine DEBUGs überprüft und habe noch diese zwei gefunden - Könnte sein, dass diese auch mal empfohlen waren (wo sollen sie sonst herkommen?):
| Quote: | CONFIG_SCHED_DEBUG=y
CONFIG_X86_DEBUG_FPU=y |
Aktivierung auf eigene Gefahr ...
2. Folgendes ist freundlicherweise defaultmäßig deaktiviert - musste also nur überprüft werden:
| Quote: | | # CONFIG_LDISC_AUTOLOAD is not set |
3. Und hier ist schon wieder etwas, was wir seit langem haben und bereits in C.2.1 beschrieben ist. Wichtig ist hierbei, dass der Pfad unbedingt leer sein muß:
Bereits seit 31.10.2020 in C.2.1:
| Code: | Security options --->
[*] Force all usermode helper calls through a single binary
() Path to the static usermode helper binary |
Und folgendes behalten wir mal im Hinterkopf für die nächste LTS-Serie - voraussichtlich 6.1 - und falls wir irgendwann mal CLANG einsetzen ...
| Quote: | # Enable Control Flow Integrity (since v6.1)
CONFIG_CFI_CLANG=y
# CONFIG_CFI_PERMISSIVE is not set |
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Mon Jun 19, 2023 9:49 am Post subject: IO_uring |
|
|
IO_uring
Nachdem ich das gelesen hatte:
https://www.phoronix.com/news/Google-Restricting-IO_uring
überprüfte ich sofort dies:
| Code: | General setup --->
[*] Configure standard kernel features (expert users) --->
[ ] Enable IO uring support |
Erfreulicherweise habe ich keinen Performance-Verlust beim Zugriff auf meine HD und SSD's festgestellt - es wird also vermutlich noch einige Zeit ausgeschaltet bleiben. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Thu Jul 20, 2023 5:14 pm Post subject: X86_kernel_ibt |
|
|
Eine Abfrage meiner CPU mit cpuid ergab:
| Quote: | | IBRS/IBPB: indirect branch restrictions = true |
und deshalb habe ich X86_KERNEL_IBT nun aktiviert, da es auch in vielen Standard-Konfigurationen enabled ist - auch wenn KSPP es (noch) nicht empfiehlt:
| Code: | Processor type and features --->
[*] Indirect Branch Tracking |
Im Systemlog erscheint nun zusätzlich:
| Code: | | CET detected: Indirect Branch Tracking enabled |
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Tue Oct 03, 2023 9:38 pm Post subject: Neue Empfehlungen in KSPP vom 30.09.2023 |
|
|
Neue Empfehlungen in KSPP vom 30.09.2023
Fast genau 11 Monate war es still, nun haben wir seit dem 30.09.2023 eine neue Version. Ich habe natürlich gleich mal einen Diff gemacht (zur lezten alten Version vom 2022-11-01) und musste feststellen, dass es nur sehr wenige Neuerungen oder Änderungen gab.
Eine einzige Ergänzung für die Kernel Konfiguration ... die meines Wissens eh' bereits per default disabled ist:
| Code: | Processor type and features --->
[ ] Enable vsyscall emulation |
Bei den Kernel Command Line Optionen sind alle vier neu hinzugekommenen eher ... unnötig. Weil drei davon ja schon in der Kernel Konfiguration abgehandelt wurden. Bei "mitigations=" will ich SMT NICHT ausschalten, und "auto" brauche ich auch nicht, weil ich ja bereits alle in der Kernel Konfiguration enabled habe.
| Code: | # Make sure CONFIG_HARDENED_USERCOPY stays enabled.
hardened_usercopy=1
# Randomize page allocator (for when CONFIG_SHUFFLE_PAGE_ALLOCATOR isn't already enabled).
page_alloc.shuffle=1
# Mitigates all known CPU vulnerabilities, disabling SMT *if needed*.
mitigations=auto,nosmt
# Make sure COMPAT_VDSO stays disabled
vdso32=0 |
Was die Einstellungen für sysctl betrifft, bleibe ich bei meiner alten Empfehlung: Alles kopieren und in die /etc/syctl.conf einfügen. Das hier kam neu hinzu:
| Code: | # Try to keep kernel address exposures out of various /proc files (kallsyms, modules, etc). (There is no CONFIG for the changing the initial value.) If root absolutely needs values from /proc, use value "1".
kernel.kptr_restrict = 2
# Make sure the expected default is enabled to enable full ASLR in userpsace.
kernel.randomize_va_space = 2
# Block all PTRACE_ATTACH. If you need ptrace to work, then avoid non-ancestor ptrace access to running processes and their credentials, and use value "1".
kernel.yama.ptrace_scope = 3
# Disable TIOCSTI which is used to inject keypresses. (This will, however, break screen readers.)
dev.tty.legacy_tiocsti = 0
# Disable userfaultfd for unprivileged processes.
vm.unprivileged_userfaultfd = 0
# Disable POSIX symlink and hardlink corner cases that lead to lots of filesystem confusion attacks.
fs.protected_symlinks = 1
fs.protected_hardlinks = 1
# Disable POSIX corner cases with creating files and fifos unless the directory owner matches. Check your workloads!
fs.protected_fifos = 2
fs.protected_regular = 2
# Make sure the default process dumpability is set (processes that changed privileges aren't dumpable).
fs.suid_dumpable = 0 |
Ich glaube dass wir bei Gentoo bereits die vier fs.protected* defaultmäßig so eingestellt haben. Macht aber nix, wenn wir es nochmal machen. Wie gesagt: Copy and Paste.
Das einzige was evtl. Probleme machen könnte ist: dev.tty.legacy_tiocsti = 0 Aber Ausprobieren hat noch nie geschadet. |
|
| Back to top |
|
|
disquz
n00b
Joined: 09 Feb 2019
Posts: 20
|
| Posted: Thu Feb 22, 2024 2:45 pm Post subject: |
|
|
Hi,
KSPP ist ne super Sache und ich versuche auch alles soweit umzusetzen aber das Abschalten von DEVMEM und X86_MSR ist ein großes Problem für mich.
Mein Laptop (Lenovo) throttled bereits bei 70°C und auf einer Kiste die öfter mal Packages bauen muss, spürt man das schon gewaltig...
Dagegen gibt es ein Tool welches "throttled" heißt und in Abständen von 5 Sekunden in ein CPU Register schreibt und das Throttling unterbindet (und zudem noch etwas Undervolting macht).
Wenn ich jetzt aber DEVMEM und X86_MSR deaktiviere, dann funktioniert dieses Tool nicht mehr. Lasse ich es drinn, habe ich die zweite Option "X86_64 KSPP Settings" nicht in der KSPP Auswahl...
Wie würdest Du hier vorgehen? Was empfiehlst Du?
Danke vorab!
disquz |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Thu Feb 22, 2024 3:39 pm Post subject: |
|
|
| disquz wrote: | | Wie würdest Du hier vorgehen? Was empfiehlst Du? |
Ich empfehle Dir das gleiche zu machen wie ich: Konfiguriere alles selbst ohne unsere Gentoo Option zu verwenden.
Ich habe nämlich ein ähnliches Problem: Ich möchte/habe CONFIG_RANDSTRUCT_FULL statt CONFIG_RANDSTRUCT_PERFORMANCE, was aber leider auch geprüft wird:
| Code: | | Depends on: GENTOO_KERNEL_SELF_PROTECTION [=y] && GENTOO_LINUX [=y] && ... && RANDSTRUCT_PERFORMANCE [=y] |
Dadurch kann ich es auch nicht nutzen und habe alle Einstellungen selbst vorgenommen. Du findest diese ganz übersichtlich in der Datei /usr/src/linux/distro/Kconfig
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
disquz
n00b
Joined: 09 Feb 2019
Posts: 20
|
| Posted: Thu Feb 22, 2024 6:40 pm Post subject: |
|
|
| pietinger wrote: |
Ich habe nämlich ein ähnliches Problem: Ich möchte/habe CONFIG_RANDSTRUCT_FULL statt CONFIG_RANDSTRUCT_PERFORMANCE, was aber leider auch geprüft wird:
| Code: | | Depends on: GENTOO_KERNEL_SELF_PROTECTION [=y] && GENTOO_LINUX [=y] && ... && RANDSTRUCT_PERFORMANCE [=y] |
Dadurch kann ich es auch nicht nutzen und habe alle Einstellungen selbst vorgenommen. Du findest diese ganz übersichtlich in der Datei /usr/src/linux/distro/Kconfig |
Ok, dann werde ich
| Code: | | [*] Kernel Self Protection Project ---> |
deaktivieren und die Sachen händisch aus der Kconfig umsetzen.
Darf ich fragen warum Du CONFIG_RANDSTRUCT_FULL statt _PERFORMANCE aktivieren willst?
Ich bin da etwas unentschlossen, weil es laut Hilfe einen ziemlichen Performance Hit haben soll...
Edit:
Was mir noch nicht ganz klar ist: Die Kconfig scheint ja nicht alles zu beinhalten, was auf der KSPP Website steht. Ist es da nicht besser ich setze gleich alles auf der Website um statt mich zusätzlich durch Kconfig zu arbeiten?
Edit:
Mir ist gerade aufgefallen, dass ich z.B. CONFIG_DEBUG_CREDENTIALS=y nicht setzen kann, wenn ich das hier deaktiviert habe:
| Code: | | [*] Kernel Self Protection Project ---> |
Last edited by disquz on Thu Feb 22, 2024 7:05 pm; edited 1 time in total |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
|
| Back to top |
|
|
disquz
n00b
Joined: 09 Feb 2019
Posts: 20
|
| Posted: Fri Feb 23, 2024 9:22 am Post subject: |
|
|
| Quote: | | Ja, hat es ... ich kann es mir aber mit meiner neuen Kiste leisten ... i9-13900K ... |
Oh ja, das wäre mal cool wenn ich so einen Boliden hätte, da wären mir Performance-Hits auch egal
Leider hab ich nur einen i7-8550U @1.80GHz...
Alles klar. Dann mache ich es auch so...
Ich bin allerdings noch ein kleines bisschen verwirrt über den "Pfad" durch dieses Tutorial.
Was hat Priorität, die Wiki-Seiten wie: https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Kernel_Hardening_with_KSPP
oder die Threads hier im Tutorial (Forum)?
Durch die Edits verschwimmt das ganze ein wenig und ich bin mir nicht sicher wie ich am besten von A nach D komme...
Kannst Du da evtl. eine Empfehlung dazu machen? |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Fri Feb 23, 2024 10:13 am Post subject: |
|
|
| disquz wrote: | [...]
Durch die Edits verschwimmt das ganze ein wenig und ich bin mir nicht sicher wie ich am besten von A nach D komme...
Kannst Du da evtl. eine Empfehlung dazu machen? |
Das einzige was mir da einfällt wäre das was ich selbst machen würde: Alles vorher lesen und dann planen ...
... ich habe z.B. letztes Jahr meine Vorgehensweise für den ersten Tag der Installation meiner neuen Kiste bereits vorher in ein Text-file geschrieben in dem ich jeden einzelnen Schritt festhielt (war einfach, da ich bereits ältere Files für meine alten Kisten hatte): https://wiki.gentoo.org/wiki/User:Pietinger/temp/delete_me
Ja, das sieht so ähnlich aus wie hier in A.1 und A.3 beschrieben ... weil ich mich ja eigentlich strikt nach unserem https://wiki.gentoo.org/wiki/Handbook:AMD64 halte.
Ein Unterschied ist z.B.: Ich machte die Abfragen für den Kernel - lspci - gleich mit der BootCD (bevor ich chroote) weil hier das lspci vorhanden ist; so brauche ich es später nicht erst mit emerge holen (ganz später wird es automatisch durch eine Abhängigkeit installiert). Das sind aber Kleinigkeiten die keinen Unterschied im Ergebnis machen.
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Fri Feb 23, 2024 10:23 am Post subject: |
|
|
Alles was den Kernel betrifft ist im Wiki aktuell.
(Ich habe ja in A.2 den Link auf das Wiki rein editiert.)
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Fri Apr 26, 2024 11:28 pm Post subject: Neue Empfehlungen in KSPP vom 26.04.2024 |
|
|
Neue Empfehlungen in KSPP vom 26.04.2024
Ich habe wieder einen Diff zur vorhergehenden Version vom 20.10.2023 gemacht und stelle diesen hier relativ unkommentiert rein ... weil ... ich diesen Thread langsam etwas unübersichtlich finde ... und ... ich vorhabe das zukünftig nur noch im Gentoo Wiki zu aktualisieren. Dies ist der Link:
https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/Kernel_Hardening_with_KSPP
(Ich habe im ersten Posts dieses Threads nun auch einen Hinweis auf das Wiki eingefügt.)
| Code: | 1.
LIST_HARDENED=y
2. seit 6.6
6.6. RANDOM_KMALLOC_CACHES=y
3.
SLAB_MERGE_DEFAULT is not set
4. seit 6.6
PAGE_TABLE_CHECK=y
PAGE_TABLE_CHECK_ENFORCED=Y
5.
KFENCE_SAMPLE_INTERVAL=100
6.
CONFIG_MAGIC_SYSREQ_DEFAULT_ENABLE=176
7.
CONFIG_MODULE_FORCE_LOAD is not set
8.
CONFIG_X86_KERNEL_IBT=y
9. seit 6.6
CONFIG_X86_USER_SHADOW_STACK=y
10.
CONFIG_FINEIBT is not set |
1. Diese Option wird automatisch enabled durch andere Optionen die wir bereits enabled haben: BUG_ON_DATA_CORRUPTION [=y] und DEBUG_LIST [=y] && DEBUG_KERNEL [=y]
2. Habe ich bereits in der Wiki-Seite empfohlen.
3. War bis jetzt nur als KernelCommandLineParameter empfohlen; man kann es aber auch direkt in der Kernel Config disablen:
| Code: | Memory Management options --->
SLAB allocator options --->
[ ] Allow slab caches to be merged |
4. Habe ich bereits in der Wiki-Seite empfohlen.
5. Dies scheint der Default zu sein und ich musste es nicht ändern.
6. Ist bei mir komplett deaktiviert (brauche ich nicht). Deine Entscheidung.
7. Ist bei mir auch nicht möglich, weil ich halt gar keinen Modul-Support habe (Monolithischer Kernel; siehe 1. Post dieses Threads)
8. Wenn eine Abfrage mit "cpuid" folgendes ergibt: "IBRS/IBPB: indirect branch restrictions = true" dann enable das.
| Code: | Processor type and features --->
[*] Indirect Branch Tracking |
9. Habe ich bereits in der Wiki-Seite empfohlen.
10. Nur wenn Du den Kernel mit clang kompilierst (Ich nutze den GCC und habe deswegen diese Option gar nicht).
Dies ist nun mein letztes Update zu KSPP in diesem Thread. Zukünftige Updates sind im Wiki zu finden. (Falls gewünscht kann ich aber hier einen Hinweis geben, dass ein Update stattgefunden hat)
.
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German) 
