neue Gentoo-Version 2004.0 / hardened

[andreask2]

Hallo!

Die meisten werden es sicher schon mitbekommen haben, vor kurzem wurde die neuste Version der Gentoo-Distribution released: Gentoo 2004.0.

Alles wissenswerte findet Ihr hier:
http://www.gentoo.org/proj/en/releng/
http://gentoo.de/


Ist also eine gute Gelegenheit ein Stage-Archiv auf dern Root-Server zu laden und zu installieren, so hat man ein schön aktuelles System und muss fast nichts anpassen nach einem "emerge --update world" im Gegensatz zu einem 6 Monate alten Paket :)

Das ist auch die Gelegenheit die ich ergreifen werde, und ich hatte mir inzwischen auch einige Gedanken gemacht.
Eigentlich hatte ich geplant den grsec-kernel von gentoo mit der evtl. leicht angepassten Konfig auf Grundlage der des Captain(danke hierfür!) zu verwenden, aber scheint bei gentoo das "hardened" Projekt ( http://www.gentoo.org/proj/en/hardened/ ) soweit fertig und stabil zu sein, was ja noch zusätzliche Sicherheit gegenüber grsec alleine versprichet, wie z.B. ein hardened-gcc (mit PAX,SSP)..., entsprechend gibt es auch hardened-stages... und das ganze funktioniert sowohl mit grsec-sources als auch mit selinux-sources, wobei ich mich schon definitiv für grsec entschieden habe.

Naja, Gentoo-Hardened hat schon noch ein paar Vorteile gegenüber grsec alleine, wie wichtig würdet Ihr z.B. einen mit pax und ssp kompilierten gcc bewerten, oder dass andere Pakete alle mit ssp... kompiliert werden?

Hat da jemand Erfahrung mit (vielleicht sogar gentoo-spezifisch)? Mich würde besonders interessieren wie stabil sowas im Alltag (Server vor allem mit Apache und PostgreSQL) ist, und was man da so für Probleme zu erwarten hat...

In Gentoo gibt es ja wie gesagt fertige hardened-stages und auch einen hardened-kernel, in dem die ganzen nützlichen Patches vorhanden sind( http://www.gentoo.org/proj/en/hardened/#doc_chap4 ), auf der anderen Seite ist das halt alles noch viel weniger erprobt als grsec z.B.


Viele Grüße
Andreas

[captaincrunch]

Zu Gentoo-Hardened kann ich dir relativ wenig sagen. Im Falle von Adamantix ist der Kernel (u.a.), sowie der gcc mit PaX und SSP gepatcht, und bis auf Java-Schrunz und schlecht programmierte Software macht diese Kombination eigentlich keine Probleme.

Btw.: Adamantix 1.0.3 ist auch ganz frisch draußen. ;)

[andreask2]

Ich habe diese Security-Sonderausgabe des Linux-Magazins gelesen. SSP scheint ja ein durchaus sinnvolles Patch zu sein.

Vielleicht verwende ich für den Anfang einfach grsec-sources und den hardened-gcc mit SSP.

Wie siehst Du das in der Praxis, würde SSP überhaupt viele bekannte Angriffe vereiteln, die bei grsec/Pax... noch funktionieren würde, oder ist das ganze noch eher theoretisch?

Grüße
Andreas

[captaincrunch]

Vielleicht verwende ich für den Anfang einfach grsec-sources und den hardened-gcc mit SSP.

Da GRSecurity den Kernelseitigen PaX-Patch bereits enthält, kannst du dem ganzen System auch direkt etwas gutes damit tun. ;)

Was SSP angeht, gehen die Meinungen z.T. ziemlich auseinander, da das ganze zwar relativ theoretisch ist, es dafür aber erstaunlich gut funktioniert. ;) Was die Performance angeht, kann ich dir aber leider keine großartigen Vergleichswerte zwischen gepatchten und ungepatchten Systemen sagen, nur, dass der Unterschied nach allem, was ich bisher dazu gelesen hatte nicht allzu groß ist.

[phantom]

und bis auf Java-Schrunz

Du bist mit dieser Aussage immer wieder amüsant, CC. :roll:

[phantom]

Nebenbei: Dir Mirrors sind bei weitem noch nicht vollständig.
Insbesondere fehlt bei den meisten noch die PowerPC und die Alpha Release.

[Joe User]

Der SSP ist erst dann voll funktionsfähig, sobald das komplette System mit den entsprechenden Flags/Patches kompiliert wurde. Das heisst, dass das nachträgliche installieren eines mit SSP kompiliertem Programmes keine zusätzliche Sicherheit bietet. Ergo solltest Du mit einem Stage1 beginnen und Dein Gentoo anschliessend komplett rekompilieren, um sicherstellen zu können, dass der SSP, wie vorgesehen, arbeiten kann. Einbussen bei der Performance sind mir bisher nicht bekannt. Interessannt wird der SSP allerdings erst in Kombination mit PIE (Position Independent Executables), dem Nachfolger von PIC (Position Independent Code), welches ab gcc-3.3.1 per Backport und ab gcc-3.4 OOTB verfügbar ist...

Ein paar Links zum Thema:
http://www.research.ibm.com/trl/projects/security/ssp/
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00140.html
https://twocents.mooo.com/hints/downloads/files/ssp.txt
https://twocents.mooo.com/hints/downloa ... winter.txt
https://twocents.mooo.com/hlfs/download ... 4/ssp.html
https://twocents.mooo.com/hlfs/download ... 4/pie.html

[oxygen]

Also ich hab bei mir Zuhause ein emerge -u world gemacht, hat sich aber bei MySQL verhackt. Erst hat er sich wegen der USE Kombi "static openssl" beschwert und jetzt kompiliert es gar nicht mehr. Muss ich mal sehen was daraus wird... habe gerade wenig Zeit.

[andreask2]

Vielen Dank für die Infos/Links!

Den Namen der Stage-Archive nach zu urteilen ist das sicherlich bedacht worden: http://gentoo.oregonstate.edu/releases/ ... /pentium3/ ;-)

Das schöne ist ja, dass man bei der hardened-Version von Gentoo einiges an Arbeit abgenommen bekommt. Darüber hinaus wird das ganze besser getestet als ich das je könnte wenn ich es alleine zusammenbastel, aber mal sehen ob ich da jetzt schon mitgehe, oder bis April warte und solange erstmal nur grsec verwende. Ist ja noch ganz neu und da werden sicher noch Probleme mit verbunden sein.

Und wenn da bald noch "emerge --update security" kommt bin ich höchst zufrieden mit gentoo ;-)

Leider haben die Gentoo-Jungs igendwelche techn. Probleme mit dem Mirror-System, so dass noch einige Dateien fehlern, wie z.B. die nicht-hardened Stage-Archive und einige Live-CDs, siehe http://www.gentoo.org.

Grüße,
Andreas

[andreask2]

Also ich hab bei mir Zuhause ein emerge -u world gemacht, hat sich aber bei MySQL verhackt. Erst hat er sich wegen der USE Kombi "static openssl" beschwert und jetzt kompiliert es gar nicht mehr. Muss ich mal sehen was daraus wird... habe gerade wenig Zeit.

"emerge -u world" ist IMHO auch aus eben diesem Grund nichts für einen Server. Ich mache das einmal am Anfang, und aktualisiere dann nur noch spezielle Pakete. Man kann ja mit "-p" gucken was so nötig wäre, falls man doch mal ein Announcement verpasst.

[netsoul]

Hallo,

da ich ja vor ein paar Wochen schon schrieb, das Gentoo auch für mich interessant wäre schreib ich hier doch gleich mal ein paar Erfahrungen nieder.

Die Installation war relativ einfach und nach den Vorgaben die hier im Forum stehen zu bewältigen. Nach ca. 2 Stunden konnte ich das erste mal ins das System booten.

Seitdem läuft das Gerät mit Mail- und Web Service. Updates waren bis auf den Kernel Bug relativ trivial, so das es keine Probleme gab. Die Kernel Konfig habe ich auf Basis der Strato Config gemacht und dann alles rausgehauen, so das ein schlanker monolithischer Kernel dabei herausgekommen ist. Die grsecurity Patches sind auch mit drin und mittlerweile sind auch die ACL's für gradm fast soweit, dass ich die Konfiguration "locken" kann. Habe auch schon ein paar Tests gemacht. Zum einen eher aus Interesse einen Nessus Scan zum anderen aber auch mit ein paar Kollegen direkt auf der Konsole. (Vorher Image gezogen und die dann machen lassen was sie wollten ;)

Bisher bin ich sehr zufrieden und kann mich nicht beklagen eher im Gegenteil. Für Fragen stehe ich gerne zur Verfügung.

Die hardenend sources bzw. Gentoo hardened ist für mich nicht interessant, da der Verwaltungsaufwand unermesslich in die Höhe gestreckt wird meiner Meinung nach.
Ich habe mir lieber ein paar "Fallen" ausgedacht, die erstaunlicherweise auch sehr gut funktionieren. Durch die ACL's sieht ein User fast nichts vom System und selbst als root habe ich nur Zugriff auf Dinge die man wirklich braucht...und dann auch nur eingeschränkt. Anmerken möchte ich, dass der gradm learning Mode schrecklich ist...oder ich kann nur nicht damit umgehen. Nun ja, soweit so gut ;)

[oxygen]

Also ich hab bei mir Zuhause ein emerge -u world gemacht, hat sich aber bei MySQL verhackt. Erst hat er sich wegen der USE Kombi "static openssl" beschwert und jetzt kompiliert es gar nicht mehr. Muss ich mal sehen was daraus wird... habe gerade wenig Zeit.

"emerge -u world" ist IMHO auch aus eben diesem Grund nichts für einen Server. Ich mache das einmal am Anfang, und aktualisiere dann nur noch spezielle Pakete. Man kann ja mit "-p" gucken was so nötig wäre, falls man doch mal ein Announcement verpasst.

Das war ja auch kein Server, sondern meine Workstation zuhause... und da hat eine emerge -u world seit Monaten immer problemlos geklappt.

[floschi]

Wollte nur mal anmerken, dass sogar ich (als einer der größeren Zweifler) mittlerweile gentoo daheim teste und für die wenige Zeit, die ich bisher damit verbringen konnte, ganz zufrieden bin. ;)

[captaincrunch]

mittlerweile gentoo daheim teste und für die wenige Zeit, die ich bisher damit verbringen konnte, ganz zufrieden bin

Dass ich das noch erleben darf. ;)

[Joe User]

BTW: Welche USE-Flags sind für einen 0815-Server (Apache2/Exim/Courier/MySQL/PHP) empfehlenswert?

[andreask2]

[Das war ja auch kein Server, sondern meine Workstation zuhause... und da hat eine emerge -u world seit Monaten immer problemlos geklappt.

Ja, wollte es auch nur anmerken, denn gerade das "hat aber sonst immer problemlos geklappt" will man auf dem Server nicht unbedingt hören ;-)

*SCNR*

[t0x1c]

BTW: Welche USE-Flags sind für einen 0815-Server (Apache2/Exim/Courier/MySQL/PHP) empfehlenswert?

Kann man so nicht sagen, da es ja drauf ankommt was du brauchst.
Schau Dir am besten die möglichen USE-Flags der Pakete mit emerge -pv <paket> an, dann iss das auch auf dein System zugeschnitten. ;)

@Topic: Cool, mal ausprobieren!

[andreask2]

BTW: Welche USE-Flags sind für einen 0815-Server (Apache2/Exim/Courier/MySQL/PHP) empfehlenswert?

Tipp:

Code: Select all

emerge ufed

damit ists einfacher. Anfangs hatte ich Dinge wie perl oder mysql aktiviert, aber das ist doof da er Dir bei jeder Gelegenheit alle möglichen Module erstelllt die man doch nicht braucht. Deaktivieren kann man auf jedenfalls alles mit Grafik, Sound... etc (X, ...), ich kann meine use-flags gerade mal rauskramen...

Grüße
Andreas

[andreask2]

Also auf meinem lokalen Testsystem habe ich folgende Flags gesetzt:

Code: Select all

USE="ipv6 mysql openssh pear-db postgres sqlite -oss -arts -avi -cups 
     -encode -foomaticdb -gtk -gtk2 -kde -gnome -mad -mikmod -motif -mpeg 
     -oggvorbis -opengl -qt -quicktime -sdl -X -xmms -xv -perl"

CHOST="i686-pc-linux-gnu"

CFLAGS="-march=pentium2 -O2 -pipe -fomit-frame-pointer"

Heute würde ich noch mysql, postgresql, pear-db, IPv6, sqlite rausnehmen. Vielleicht finde ich beim nächsten mal sogar noch mehr was ich streichen kann ;-)

Jedenfalls verwende ich die globalen USE-flags lediglich dazu, bestimmte(unnötige) Abhängigkeiten/Installationen zu verhindern, "lokal", also bei einem bestimmten emerge benutze ich dann z.B. temporär andere USE-Flags über die Umgebungsvariablen, so kann ich z.B. mod_php fast genauso anpassen wie wenn ich es manuell kompiliere.

Je nachdem wenn Du noch Apache 1.3 einsetzen willst wäre es evtl. sinnvoll das entsprechend in den Flags anzugeben, da standardmäßig Apache 2 verwendet wird.

CFLAGS sind für einen älteren PC, für einen 1und1-Rootserver würde ich allerdings lediglich pentium2 gegen pentium3/4 ersetzen - je nachdem. -O3 würde ich vermutlich lassen. Oder verwendet Ihr alle -O3?

Grüße
Andreas

[Joe User]

Also auf meinem lokalen Testsystem habe ich folgende Flags gesetzt:

Danke.

-O3 würde ich vermutlich lassen. Oder verwendet Ihr alle -O3?

Da sich SSP/PIE nicht mit -O3 verträgt, sollte man auf einem entsprechendem System maximal -O2 verwenden, -Os sorgte bei meinen hardened LFS Builds ebenfalls zu vereinzelten, nicht reproduzierbaren, Problemen. Mit -O2 -pipe -march=i686 -mcpu=i686 -fomit-frame-pointer hatte ich bisher (Linux-2.4.x/2.6.x/linuxthreads/nptl glibc-2.3.3 gcc-3.3.x binutils-2.14.90.0.x SSP PIE PAX) keine (unlösbaren) Probleme.

[andreask2]

Da sich SSP/PIE nicht mit -O3 verträgt, sollte man auf einem entsprechendem System maximal -O2 verwenden, -Os sorgte bei meinen hardened LFS Builds ebenfalls zu vereinzelten, nicht reproduzierbaren, Problemen.

ah, gut zu wissen! Danke.

Mit -O2 -pipe -march=i686 -mcpu=i686 -fomit-frame-pointer hatte ich bisher (Linux-2.4.x/2.6.x/linuxthreads/nptl glibc-2.3.3 gcc-3.3.x binutils-2.14.90.0.x SSP PIE PAX) keine (unlösbaren) Probleme.

-mcpu ist AFAIK nicht nötig, denn -march impliziert -mcpu:

http://gcc.gnu.org/onlinedocs/gcc-3.3.3 ... %20Options

So wie ich das verstehe besteht der Unterschied zw. -march und -mcpu darin, dass -march Code erzeugt, der nur auf der angegebenen Architektur (z.B. pentium3) lauffähig ist, -mcpu dagegen ist abwärtskompatibel, das heißt der Code läuft auf jedem 386er System. Wobei ich den Sinn von -mcpu nicht wirklich verstehe, wird dann zur Zeit der Ausführung geprüft welche Architektur und ggfs. für die angegebene Architektur optimierter Code ausgeführt, und sonst der standard 386er Code? Würde höchstens Sinn machen wenn die Programme "zur Not" auch 1:1 auf einem anderen x86er Prozessor laufen können sollen.
Heißt dass dann dass der Unterschied ggfs. nur in der Größe der Binaries liegt?

Grüße
Andreas

[Joe User]

Ich verwende -march und -mcpu nur deshalb gemeinsam, weil es einige Programmierer gibt, so findet sich beispielsweise im Makefile von openssl noch immer -m486, welche -mcpu/-m$CPU hardcoden und somit -march aushebeln :-/

Wenn Du abwärtskompatible kompiieren möchtest, musst Du -march=$MINARCH und je nach Source zusätzlich -mcpu=$MINARCH verwenden.

BTW: -march=pentium[34] und Konsorten können bei einigen gcc-Versionen (welche Versionen dies genau sind, kann ich leider nicht mehr finden) zu unerwarteten Problemen führen, oder werden einfach ignoriert, weshalb ich generell i686 statt pentium[34] nutze.