Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
B2 Manuelle Konfiguration des Kernels II
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Deutsche Dokumentation
View previous topic :: View next topic  
Author Message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 1698
Location: Bavaria

PostPosted: Sun May 10, 2020 7:45 pm    Post subject: B2 Manuelle Konfiguration des Kernels II Reply with quote

(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 ;-)



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

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 grub2 (="grubx64.efi") erscheinen mit dem Titel "gentoo" (diesen Titel darfst Du deshalb im nächsten Schritt nicht nochmal verwenden).
Code:
# efibootmgr -v

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 ... ;-)
.


Last edited by pietinger on Wed Oct 27, 2021 1:00 pm; edited 46 times in total
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 1698
Location: Bavaria

PostPosted: Sun Jul 12, 2020 2:52 pm    Post subject: Hardened Kernel II. Reply with quote

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

Aufruf erfolgt via
Code:
./kconfig-hardened-check  -p X86_64 -c /usr/src/linux/.config

und die Ausgabe sieht bei mir so aus:
Code:
[+] Trying to detect architecture in "/usr/src/linux/.config"...
[+] Detected architecture: X86_64
[+] Trying to detect kernel version in "/usr/src/linux/.config"...
[+] Found version line: "# Linux/x86 5.7.8-gentoo Kernel Configuration"
[+] Detected kernel version: 5.7
[+] Checking "/usr/src/linux/.config" against X86_64 hardening preferences...
=========================================================================================================================
                 option name                 | desired val | decision |       reason       |   check result
=========================================================================================================================
CONFIG_BUG                                   |      y      |defconfig |  self_protection   |   OK
CONFIG_SLUB_DEBUG                            |      y      |defconfig |  self_protection   |   OK
CONFIG_GCC_PLUGINS                           |      y      |defconfig |  self_protection   |   OK
CONFIG_STACKPROTECTOR_STRONG                 |      y      |defconfig |  self_protection   |   OK
CONFIG_STRICT_KERNEL_RWX                     |      y      |defconfig |  self_protection   |   OK
CONFIG_STRICT_MODULE_RWX                     |      y      |defconfig |  self_protection   |   OK: CONFIG_MODULES "is not set"
CONFIG_REFCOUNT_FULL                         |      y      |defconfig |  self_protection   |   OK: version >= 5.5
CONFIG_IOMMU_SUPPORT                         |      y      |defconfig |  self_protection   |   OK
CONFIG_MICROCODE                             |      y      |defconfig |  self_protection   |   OK
CONFIG_RETPOLINE                             |      y      |defconfig |  self_protection   |   OK
CONFIG_X86_SMAP                              |      y      |defconfig |  self_protection   |   OK
CONFIG_SYN_COOKIES                           |      y      |defconfig |  self_protection   |   OK
CONFIG_X86_UMIP                              |      y      |defconfig |  self_protection   |   OK
CONFIG_PAGE_TABLE_ISOLATION                  |      y      |defconfig |  self_protection   |   OK
CONFIG_RANDOMIZE_MEMORY                      |      y      |defconfig |  self_protection   |   OK
CONFIG_INTEL_IOMMU                           |      y      |defconfig |  self_protection   |   OK
CONFIG_AMD_IOMMU                             |      y      |defconfig |  self_protection   |   OK
CONFIG_VMAP_STACK                            |      y      |defconfig |  self_protection   |   OK
CONFIG_RANDOMIZE_BASE                        |      y      |defconfig |  self_protection   |   OK
CONFIG_THREAD_INFO_IN_TASK                   |      y      |defconfig |  self_protection   |   OK
CONFIG_BUG_ON_DATA_CORRUPTION                |      y      |   kspp   |  self_protection   |   OK
CONFIG_DEBUG_WX                              |      y      |   kspp   |  self_protection   |   OK
CONFIG_SCHED_STACK_END_CHECK                 |      y      |   kspp   |  self_protection   |   OK
CONFIG_SLAB_FREELIST_HARDENED                |      y      |   kspp   |  self_protection   |   OK
CONFIG_SLAB_FREELIST_RANDOM                  |      y      |   kspp   |  self_protection   |   OK
CONFIG_SHUFFLE_PAGE_ALLOCATOR                |      y      |   kspp   |  self_protection   |   OK
CONFIG_FORTIFY_SOURCE                        |      y      |   kspp   |  self_protection   |   OK
CONFIG_DEBUG_LIST                            |      y      |   kspp   |  self_protection   |   OK
CONFIG_DEBUG_SG                              |      y      |   kspp   |  self_protection   |   OK
CONFIG_DEBUG_CREDENTIALS                     |      y      |   kspp   |  self_protection   |   OK
CONFIG_DEBUG_NOTIFIERS                       |      y      |   kspp   |  self_protection   |   OK
CONFIG_INIT_ON_ALLOC_DEFAULT_ON              |      y      |   kspp   |  self_protection   |   OK
CONFIG_GCC_PLUGIN_LATENT_ENTROPY             |      y      |   kspp   |  self_protection   |   FAIL: "is not set"
CONFIG_GCC_PLUGIN_RANDSTRUCT                 |      y      |   kspp   |  self_protection   |   OK
CONFIG_HARDENED_USERCOPY                     |      y      |   kspp   |  self_protection   |   OK
CONFIG_HARDENED_USERCOPY_FALLBACK            | is not set  |   kspp   |  self_protection   |   OK
CONFIG_MODULE_SIG                            |      y      |   kspp   |  self_protection   |   OK: CONFIG_MODULES "is not set"
CONFIG_MODULE_SIG_ALL                        |      y      |   kspp   |  self_protection   |   OK: CONFIG_MODULES "is not set"
[...]


Ein MUST HAVE !

8)
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 1698
Location: Bavaria

PostPosted: Fri May 21, 2021 1:52 pm    Post subject: Hardened Kernel III. Reply with quote

Hardened Kernel III.

In diesem Thread: https://forums.gentoo.org/viewtopic-t-1135602-highlight-.html
wurde die Frage gestellt, wie wir unseren Kernel härten. Darin wurde ein sehr interessanter Link gegeben:
https://github.com/anthraxx/linux-hardened/releases

Ich habe mir das angesehen und vorerst als nicht für mich anwendbar gesehen. Da ich aber zwischenzeitlich zwei andere interessante Quellen fand, will ich diese hier festhalten:

https://madaidans-insecurities.github.io/guides/linux-hardening.html

https://www.whonix.org/wiki/Hardened-kernel

Der erste Artikel hat sofort meine Liebe gewonnen, denn:
Quote:
1. Choosing the right Linux
[...]
The best distribution to use as a base for your hardened operating system would be Gentoo Linux as it allows you to configure your system exactly how you want it to be which will be extremely useful, especially when we come to more secure compilation flags later in the guide.


Versuche aber nicht alles von dort umzusetzen, denn einiges kann Portage Probleme bereiten, wie z.B. das Setzen einer sichereren umask ... :-(

Ein Link eines Gentoo-Entwicklers zum Thema "umask": https://blogs.gentoo.org/mgorny/2011/10/18/027-umask-a-compromise-between-security-and-simplicity/
und ein Forum-Beitrag: https://forums.gentoo.org/viewtopic-p-4120840.html#4120840


Mit den im Link des ersten Post beschriebenen Kernel Parameter sind wir schon auf einer sehr sicheren Seite.


.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 1698
Location: Bavaria

PostPosted: Wed Jul 07, 2021 10:11 pm    Post subject: Neue Kernel-Parameter zum Setzen der KSPP-Empfehlungen Reply with quote

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.

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


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 Fri Apr 08, 2022 8:18 pm; edited 3 times in total
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 1698
Location: Bavaria

PostPosted: Wed Mar 30, 2022 11:13 pm    Post subject: Neue Empfehlungen in KSPP Reply with quote

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

.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 1698
Location: Bavaria

PostPosted: Fri Jun 10, 2022 9:41 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Deutsche Dokumentation All times are GMT
Page 1 of 1

 
Jump to:  
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