Moin. Ich betreibe seit einigen Jahren meinen eigenen Debian Server, den ich immer mit einem aktuellen Kernel versorge, welchen ich wiederum mit grsec patche. Das läuft alles sehr schmerzfrei mit den Debian Bordmitteln und die Kernelpakete sind ruckzuck erstellt. Nun will ich aber gerne zu CentOS wechseln und versuche gerade, mich in das Kernel Hardening dort einzuarbeiten. Hier wird allerdings schon grundsätzlich davor gewarnt, eigene Kernel zu bauen und überhaupt scheint mir das im Vergleich recht haarig zu sein. Nun baue ich seit 20 Jahren ohne Schmerzen eigene Kernel, benutze dabei aber immer gerne die Bordmittel (und vor allem die Paketverwaltung) der Distribution.
Daher die Frage: hat jemand Erfahrung mit dem Betrieb neuester Kernel mit grsec-Patch unter einem aktuellen CentOS? Lohnt es sich überhaupt, den Weg zu gehen oder gibt es da zu viele Hürden?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 03/28/2015 10:00 PM, Kai Bojens wrote:
Moin.
Moin,
Ich betreibe seit einigen Jahren meinen eigenen Debian Server, den ich immer mit einem aktuellen Kernel versorge, welchen ich wiederum mit grsec patche. Das läuft alles sehr schmerzfrei mit den Debian Bordmitteln und die Kernelpakete sind ruckzuck erstellt. Nun will ich aber gerne zu CentOS wechseln und versuche gerade, mich in das Kernel Hardening dort einzuarbeiten. Hier wird allerdings schon grundsätzlich davor gewarnt, eigene Kernel zu bauen und überhaupt scheint mir das im Vergleich recht haarig zu sein.
!!
Nun baue ich seit 20 Jahren ohne Schmerzen eigene Kernel, benutze dabei aber immer gerne die Bordmittel (und vor allem die Paketverwaltung) der Distribution.
Daher die Frage: hat jemand Erfahrung mit dem Betrieb neuester Kernel mit grsec-Patch unter einem aktuellen CentOS? Lohnt es sich überhaupt, den Weg zu gehen oder gibt es da zu viele Hürden?
Eine "Erklärung" für das von Dir genannte "haarig sein" der Prozedur (ja, das stimmt, been there, done that -- nicht wegen grsec, sondern anderer Gründe) wird sicher sein, daß -- wie von Dir oben erwähnt -- es "nicht vorgesehen" ist, einen eigenen Kernel zu bauen und zu fahren. CentOS, Scientific Linux und Freunde als Ablager von RHEL machen da wenige Ausnahmen, sich an das Credo von Upstream zu halten. Eine Ausnahme wäre das Xen4-Projekt bei CentOS, vermutlich war da der Leidensdruck groß genug, ausreichend Manpower hier investiert zu sehen (im Unterschied etwa dazu, eigene Kernel "streamlined" zu bauen).
Auf einem RHEL-System wirst Du bei einem zurechnungsfähigen Admin niemals einen inoffiziellen Kernel sehen, denn damit wäre der Support weg. Die sind da genauso strikt wie Theo (de Raadt), wenn man unter OpenBSD eigene Kernel baut -- was im Unterschied extrem leicht ist und brillant dokumentiert. Support gibt es trotzdem keinen.
Ob es sich lohnt? Gegenfrage: Reicht Dir nicht eine Zertifizierung nach EAL4 (e.g.), die CentOS ja quasi "erbt"?
Beste Grüße,
Timo
Am 29.03.2015 um 10:56 schrieb Timo Schöler:
Eine "Erklärung" für das von Dir genannte "haarig sein" der Prozedur (ja, das stimmt, been there, done that -- nicht wegen grsec, sondern anderer Gründe) wird sicher sein, daß -- wie von Dir oben erwähnt -- es "nicht vorgesehen" ist, einen eigenen Kernel zu bauen und zu fahren.
Ich kann das durchaus nachvollziehen. Gerade die Enterprise Distributionen sollen natürlich so lange wie möglich laufen und nicht alle paar Wochen neue Kernel spendiert bekommen. Das ist schon klar.
Ob es sich lohnt? Gegenfrage: Reicht Dir nicht eine Zertifizierung nach EAL4 (e.g.), die CentOS ja quasi "erbt"?
grsec geht einen Schritt weiter und patcht den Kernel mit einigen netten Sicherheitsfeatures. Mir geht es dabei gar nicht um das Arbeiten zur Laufzeit – dafür würde ich auch SELinux nutzen, weil das RBAC des grsec schon recht komplex ist. Nur bietet SELinux eben nicht die verbesserten Kernel Eigenschaften an. Das kann man ganz hübsch in dieser Tabelle sehen (die natürlich auch von grsec stammt und deswegen durch deren Brille gesehen werden muss):
https://grsecurity.net/compare.php
Im Kern geht es mir bei grsec mehr um den Schutz vor bösartiger (oder fehlerhafter) Software, als vor Angriffen. Aber letztlich ist das auch kein Ausschlusskriterium. Ich habe auch kein Problem damit, CentOS mit dem Standardkernel zu betreiben.
-
Kai Bojens -
Timo Schöler