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
Guru
Guru


Joined: 17 Oct 2006
Posts: 414
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.

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

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
P.S.: Diesen link darf man öfter mal besuchen - zumindest nach größeren Kernel-Versions-Änderungen - die halten das ziemlich aktuell.

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, wenn man NICHT dem Gentoo Wiki Eintrag folgt (ich bin da nämlich auf die Nase gefallen, weil ich das Beispiel dort verwendet habe: Ohne Parameter -d und -p !)
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/sda4" noch ein "ro" (für read-only) angegeben. Das habe ich dann auch mal so unverändert bei mir in den Kernel rein:
Code:
[*] Built-in kernel command line
(root=/dev/sda4 ro)

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. Für sdX musst Du Deine Bootplatte und für Y Deine Boot-Partition verwenden (wäre nach einer Grundinstallation nach (A) also: -d /dev/sda -p 2). Als Name (-L) kannst Du verwenden, was Dir in den Sinn kommt. 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).
Code:
# efibootmgr -c -d /dev/sdX -p Y -L "SECLINUX" -l '\EFI\Boot\bzImage.efi'

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


Last edited by pietinger on Thu Oct 15, 2020 12:49 pm; edited 2 times in total
Back to top
View user's profile Send private message
pietinger
Guru
Guru


Joined: 17 Oct 2006
Posts: 414
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

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