debian,linux,wolne oprogramowanie,grsecurity,rekompilacja

grsecurity + patchowanie i ponowna rekompilacja jądra

Autorzy prac i dokumentu:

Tomasz Berus tomasz_bb@tlen.pl
Krzysztof Napierała krzysztofnpl@poczta.onet.pl
Ostatnia aktualizacja: 2005.01.19

Spis treści

Stan początkowy
Drobne uwagi na wstępie
Ogólne cele
Ogólnie czym jest ten cały grsecurity
No! a teraz czas na męczące szczególiki.
STEP1: Ściągnięcie grsecurity.
STEP2: Instalacja patch'a.
STEP3: Parametryzacja jądra.
DUŻA dygresja na temat planu Naszego działania.
STEP4: Rekompilacja i instalacja jądra.

Stan początkowy

Nie ma się co w tym miejscu za dużo rozpisywać, ponieważ jest to trzeci z kolei mini-HowTo. Tak więc w skrócie co mamy:

1.System Debian 3.0r0 (woody) zrekompilowanym jądrem 2.4.28.

2.Jest dostęp do Net'u.

To się nazywa skrót.

Generalnie przyjęliśmy zasadę, że jeżeli chcecie ten opis przetrawić i zastosować, to powinniście najpierw zapoznać się z Naszym mini HowTO(1) Upgrade systemu + Rekompilacja jądra

Drobne uwagi na wstępie

Już tradycyjna formułka

Podczas wszystkich działań używana będzie powłoka bash. Generalnie, przy innych powłokach, czynności będą wyglądać tak samo. Jeżeli jednak używamy innej powłoki, to należy wziąć pod uwagę na przykład różnice w sposobie ustawiania zmiennych środowiskowych (environment vairables).

W przykładach, gdzie występują polecenia wprowadzane do powłoki, będzie używana notacja, która sugeruje od razu, czy wykonujemy czynność jako root, czy jako zwykły user:

$export .....// polecenie wydane jako zwykły user.

#export .....// polecenie wydane jako root.

Dodatkowe komentarze do poszczególnych komend zaczynają się w tej samej linii i oddzielone są dwoma znakami '//' (tak jak w powyższym przykładzie).

Ogólne cele

1.Ściągnięcie z net'u grsecurity z zachowaniem zasad autoryzacji pobranego materiału.

2.Instalacja patch'a.

3.Konfiguracja jądra opcji związanych z grsecurity.

4.Rekompilacja i instalacja nowego jądra (chociaż to raczej w jednym zdaniu poniważ rozpisaliśmy się na ten temat w mini-HowTo(1) Upgrade systemu i rekompilacja jądra

Ogólnie czym jest ten cały grsecurity

Fizycznie grsecurity to zwykła łata na dany kod jądra. Będziemy jednak unikać określenia łata, ponieważ źle się to kojarzy. Grsecurity nie naprawia kodu, ono raczej dodaje do jądra nowe funkcjonalności, ściśle związane z podniesieniem poziomu bezpieczeństwa systemu. Dlatego w dalszej części będziemy używać angielskiego słowa patch - niby to to samo, ale bez mylących skojarzeń.

No! a teraz czas na męczące szczególiki.

STEP1: Ściągnięcie grsecurity.

Proces ściągania, to przysłowiowa bułka z masłem. Wystarczy wiec wam adres http://www.grsecurity.net/download.php i na tym koniec. Trochę jednak zabawy czeka nas ze sprawdzeniem, czy aby ta bułka nie jest pełna robali (Ble!! Na samą myśl ciarki przechodzą). Musimy więc przeprowadzić kontrolę autentyczności ściągniętego materiału.

No to do dzieła, na początek ściągamy z jednego z mirrorów (nie z tego samego źródła co grsecurity) podpis cyfrowy.Dla przykładu z:

http://mirror.alldas.org/www.grsecurity.net/download.php

Nie zapominajcie o standardowo zainstalowanej przeglądarce lynx, przyda się.

Mamy więc teraz dwa pliki:

grsecurity-2.1.0-2.4.28-200501051112.patch

grsecurity-2.1.0-2.4.28-200501051112.patch.sign

, ściągnięte z dwóch różnych źródeł

Sprawdźmy więc co da nam pierwsze podejście do weryfikacji:

$gpg --verify grsecurity-2.1.0-2.4.28-200501051112.patch.sign grsecurity-2.1.0-2.4.28-200501051112.patch

gpg: /home/tomekb/.gnupg: directory created

gpg: /home/tomekb/.gnupg/options: new options file created

gpg: you have to start GnuPG again, so it can read the new options file

I klops, nic z tego nie wyszło. Nie należy się tym przejmować, ponieważ taki komunikat dostaniemy jeżeli pod Debian'em odpalimy gpg po raz pierwszy. Wystarczy zgodnie ze wskazaniami uruchomić jeszcze raz.

$gpg --verify grsecurity-2.1.0-2.4.28-200501051112.patch.sign grsecurity-2.1.0-2.4.28-200501051112.patch

gpg: /home/tomekb/.gnupg/secring.gpg: keyring created

gpg: /home/tomekb/.gnupg/pubring.gpg: keyring created

gpg: Signature made Fri Jan 7 17:54:48 2005 CET using DSA key ID 4245D46A

gpg: Can't check signature: public key not found

Widać, że brakuje nam klucza publicznego wydawcy patch'a klucza o ID 0x4245D46A.

Potrzebny klucz ściągamy z keyserver'a:

$gpg --keyserver wwwkeys.pgp.net --recv-keys 0x4245D46A

gpg: requesting key 4245D46A from wwwkeys.pgp.net ...

gpg: key 4245D46A: public key imported

gpg: /home/tomekb/.gnupg/trustdb.gpg: trustdb created

gpg: Total number processed: 1

gpg: imported: 1

OK, klucz publiczny już jest. Teraz możemy ponownie spróbować weryfikacji:

$gpg --verify grsecurity-2.1.0-2.4.28-200501051112.patch.sign grsecurity-2.1.0-2.4.28-200501051112.patch

gpg: Signature made Fri Jan 7 17:54:48 2005 CET using DSA key ID 4245D46A

gpg: Good signature from "Bradley Spengler (spender) <spender@grsecurity.net>"

Could not find a valid trust path to the key.Let's see whether we

can assign some missing owner trust values.

No path leading to one of our keys found.

gpg: WARNING: This key is not certified with a trusted signature!

gpg:There is no indication that the signature belongs to the owner.

gpg: Fingerprint: 9F74 393D 7E7F FF3C 6500E778 9879 B649 4245 D46A

Cyfrowy podpis zgadza się z oryginałem, tak więc pozostaje tylko sprawdzić odcisk publicznego klucza Wydawcy. W tym celu odwiedzamy stronę http://keyserver.noreply.org/(jeszcze raz lynx'em) i podajemy ID klucza 0x4245D46A. W odpowiedzi dostaniemy:

Search results for '0x4245d46a'

Type bits/keyID Date User ID

_________________________________________________________________

pub style="mso-spacerun: yes"> 1024D/4245D46A 2002-12-02 Bradley Spengler (spender) <spender@grsecurity.net>

Fingerprint=9F74 393D 7E7F FF3C 6500 E778 9879 B649 4245 D46A

Odcisk na stronie i ten podany przez gpg są identyczne, a wiec weryfikacja zakończona pomyślnie.

Zobacz także:http://www.linuxpub.pl/man/gnu_privacy/ (polecamy tym, którzy są zainteresowani dobrym wprowadzeniem w zagadnienia gpg). Ewentualnie, w oryginale, jest pod http://www.gnupg.org/gph/en/manual.html

STEP2: Instalacja patch'a.

1. Umieszczamy ściągniętą paczkę w katalogu /usr/src/. Patch jest rozpowszechniany w formie zwykłego pliku tekstowego (a dokładniej jest to plik różnicowy diff)

2.Zakładając, że w katalogu /usr/src/ mamy podkatalog linux-2.4.28/, zaczynamy patcho'wanie (czytaj paczowanie) kodu jądra.

#cat grsecurity-2.1.0-2.4.28-200501051112.patch | patch -p0

patching file ...//zobaczymy listę zmienionych plików.

3.Na tym koniec instalacji.

Drobna tylko jeszcze uwaga związana z procedurą patch'owania. Jeżeli zamiast patching file ... otrzymamy coś takiego:

patching file Documentation/Configure.help

Hunk #1 succeeded at 2913 (offset 14 lines).

Hunk #2 succeeded at 24464 with fuzz 2 (offset 953 lines).

patching file Makefile

Reversed (or previously applied) patch detected! Assume -R? [n]

To najpewniej próbujemy po raz drugi zainstalować to samo.

Natomiast komunikat:

missing header for unified diff at line 4 of patch

can't find file to patch at input line 4

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

--------------------------

|diff -urNp linux-2.4.28/Documentation/Configure.help linux (...)

|--- linux-2.4.28/Documentation/Configure.help2004-11-17 06:54:20 -0500

|+++ linux-2.4.28/Documentation/Configure.help 2005-01-05 11:05:03 -0500

--------------------------

File to patch:

Oznacza, że mamy problem z lokalizację plikugrsecurity-2.1.0-2.4.28-200501051112.patch względem plików z kodem jądra. Warto wówczas wykonać polecenie:

#cat grsecurity-2.1.0-2.4.28-200501051112.patch | grep diff | head

diff -urNp linux-2.4.28/Documentation/Configure.help(...)//widać w ten sposób, gdzie będą szukane pliki z kodem jądra lokalizacja względem położenia pliku z patch'em grsec...

STEP3:Parametryzacja jądra.

1.Na początek tradycyjnie:

#cd /usr/src/linux

#make menuconfig

2.W głównym menu zobaczymy, na końcu, nową pozycję Grsecurity. Standardowo będzie wyłączona.

---

DUŻA dygresja na temat planu Naszego działania

Jakie mamy możliwości?

Grsecurity posiada cztery poziomy zabezpieczeń: Low, Medium, High oraz Customized. Wybór trzech pierwszych włącza predefiniowane zestawy zawierające określone funkcje ochrony. Dokładną ich rozpiskę można znaleźć pod adresem http://www.grsecurity.net/confighelp.php. (znajdziemy tam opis poziomów). Ostani wariant (Customized) pozwala nam na ręczne włączanie poszczególnych funkcji.

Jaką mamy sytuację?

Przygotowujemy właśnie kolejną wersję jądra z rozbudowanymi mechanizmami zabezpieczającymi, mającymi utruć życie zwykłym intruzom. Żeby jednak nie było za łatwo, to równocześnie kilka grup naszych kolegów w tym samym czasie konfiguruje, na tym samym serwerze, szereg innych usług (tj. Apache, Samba, Firewall, Ftp, DHCP server itd.).

Do tego wszystkiego należy dodać drobny, ale jakże ciekawy fakt, że bawimy się z grsecurity po raz pierwszy i nie znamy do końca skutków ubocznych włączenia poszczególnych gotowych poziomów zabezpieczeń lub wybranych ręcznie funkcji.

Nasz plan działania

Wychodząc z założenia, że lepiej nie dorzucać kolejnych zmian, które mogą uniemożliwić innym grupom konfigurowanie poszczególnych usług, zakładamy następujące etapy działania:

Etap 1:

Nie uaktywniamy grsecurity, ale rekompilujemy jądro i instalujemy je (teoretycznie, wg opisu, na tym etapie moglibyśmy włączyć poziom Low - ale z teorią i opisami różnie bywa).

Etap 2:

Czekamy, aż pozostałe grupy zakończą konfigurowanie poszczególnych usług.

Etap 3:

Rozpoczynamy mając za punkt odniesienia działające prawidłowo poszczególne usługi.

Ustawiamy (co oznacza oczywiście rekompilację i instalację kolejnego jądra) poziom Medium i po restarcie systemu sprawdzamy, czy wszystkie usługi pracują prawidłowo. W kolejnym kroku można spróbować co będzie na poziomie High lub przejść od razu do ręcznego ustawiania.

Wybieramy poziom Customized i zaczynamy ręczną zabawę z ustawieniami:

[*] Grsecurity (NEW)

(Customized)Security level

PaXControl--->

[ ] Support soft mode

[ ] Use legacy ELF header marking

[ ] Use ELF program header marking

(direct) MAC system integration

( ) none

(X)direct //default

( ) hook

Address Space Protection--->

[ ] Enforce Non-executable pages

[ ] Paging based non-executable pages

[ ] Segmentation based non-executable pages

[ ] Emulate trampolines style="mso-spacerun: yes">

[ ] Restrict mprotect() style="mso-spacerun: yes">

[ ] Address Space Layout Randomization

[ ] Randomize kernel stack base style="mso-spacerun: yes">

[ ] Randomize user stack base style="mso-spacerun: yes">

[ ] Randomize mmap() base style="mso-spacerun: yes">

[ ] Deny writing to /dev/kmem, /dev/mem, and /dev/port

[ ] Disable privileged I/O

[ ] Emulate trampolines style="mso-spacerun: yes">

[ ] Restrict mprotect() style="mso-spacerun: yes">

[ ] Address Space LayoutRandomization

[ ] Randomize kernel stack base style="mso-spacerun: yes">

[ ] Randomize user stack base style="mso-spacerun: yes">

[ ] Randomize mmap() base

[ ] Deny writing to /dev/kmem,/dev/mem, and /dev/port

[ ] Disable privileged I/O

[ ] Remove addresses from/proc/pid/[maps|stat]

[ ] Deter exploit bruteforcing

[ ] Hide kernel symbols

Role BasedAccess Control Options--->

[ ] Hide kernel processes

(3) Maximum tries before password lockout

(30) Time to wait after max password tries, in seconds

Filesystem Protections--->

[*] Proc restrictions

[ ] Restrict to user only (NEW)

[ ] Allow special group

(1001) GID for special group (NEW)

[ ] Additional restrictions

[*] Linking restrictions

[*] FIFO restrictions

[*] Chroot jail restrictions (NEW)

[*] Deny mounts

[*] Deny double-chroots

[ ] Deny pivot_root in chroot (NEW)

[*] Enforce chdir("/") on all chroots (NEW)

[*] Deny (f)chmod +s (NEW)

[ ] Deny fchdir out of chroot (NEW)

[*] Deny mknod (NEW)

[ ] Deny shmat() out of chroot (NEW)

[ ] Deny access to abstract AF_UNIX sockets out of chroot (NEW)

[ ] Protect outside processes (NEW)

[*] Restrict priority changes (NEW)

[ ] Deny sysctl writes in chroot (NEW)

[*] Capability restrictions within chroot (NEW)

Kernel Auditing--->

[ ] Single group for auditing (NEW)

(1007) GID for auditing (NEW)

[ ] Exec logging (NEW)

[ ] Resource logging (NEW)

[ ] Log execs within chroot(NEW)

[ ] Chdir logging (NEW)

[*] (Un)Mount logging (NEW)

[ ] IPC logging (NEW)

[ ] Signal logging (NEW)

[ ] Fork failure logging (NEW)

[*] Time change logging (NEW)

Executable Protections--->

[*] Enforce RLIMIT_NPROC on execs (NEW)

[ ] Destroy unused shared memory (NEW)

[*] Dmesg(8) restriction (NEW)

[*] Randomized PIDs (NEW)

[ ] Trusted path execution(NEW)

[ ] Partially restrict non-root users (NEW)

(1005) GID for untrusted users: (NEW)

Network Protections--->

[ ] Larger entropy pools (NEW)

[ ] Truly random TCP ISN selection (NEW)

[*] Randomized IP IDs (NEW)

[*] Randomized TCP source ports(NEW)

[*] Randomized RPC XIDs (NEW)

[ ] Socket restrictions (NEW)

[ ] Deny any sockets to group (NEW)

(1004) GID to deny all sockets for: (NEW)

[] Deny client sockets to group (NEW)

(1003) GID to deny client sockets for: (NEW)

[ ] Deny server sockets to group (NEW)

(1002) GID to deny server sockets for: (NEW)

Sysctl support--->

[ ] Sysctl support (NEW)

[ ] Turn on features by default (NEW)

Logging options--->

(10) Seconds in between log messages (minimum) (NEW)

(4) Number of messages in a burst (maximum) (NEW)

Powyższe ustawienia wybrane zostały na podstawie artykułu:

http://www.linux.slupsk.pl/?id=article&kategoria=23&show=108#koniec

(niestety nie jest on już najaktualniejszy)

Zobacz także: http://www.gentoo.org/proj/en/hardened/grsecurity2.xml

---

STEP4: Rekompilacja i instalacja jądra.

W tym miejscu odsyłamy do style='color:black'>Naszego opisu mini-HowTO(1) Upgrade systemu + Rekompilacja jądra (FAZA I STEP 6 i 7), ponieważ zasady rekompilacji i instalacji nowego jądra są jednakowe.