# Entwicklungs- und Produktionssystem möglich?

## sohletz

Hi, habe vor einiger Zeit schon mal Gentoo installiert (vollständige Kompilation) und war von der Geschwindigkeit echt angetan. Fand auch die Installation von Software sehr einfach. Nun Überlege ich, ob ich Gentoo gleich auf mehreren Rechnern in verschiedenen Konfigurationen installieren soll (Heimserver, Laptop, Desktop - Konfigurationen: Server, Arbeitsstation, Surf-Rechner). Die Installation fand ich zwar aufwendig, aber die wäre aufgrund der guten Update-Möglichkeiten ja bloß eine einmalige Angelegenheit (zumindest pro System, nicht wahr?).

Nun hätte ich gern "Produktionssysteme", die kein Portage und teilweise gar keine Entwicklungsumgebung (make, gcc, etc.) beinhalten. Aus Gründen besserer Sicherheit würde ich gcc z. B. nur ungern auf einem Server oder Surf-Rechner sehen, außerdem nehmen die Programme dort nur unnötig Platz weg.

Ist es mit Gentoo irgendwie möglich, sich z. B. auf einer zweiten Festplatte ein reines System zum Kompilieren von Gentoo und von Binärpaketen, sowie zum Updaten anzulegen und auf einem anderen System dann nur das Gentoo Basissystem (ohne gcc und portage, etc.) mit Binärpaketen zu installieren? Zur Zeit arbeite ich mit OpenBSD und dort ist das kein Problem, aber da kann ich ja auch nicht das ganze System neu kompilieren (bzw. kann ich das schon - aber eben so, dass ich am Ende gcc usw. nicht installieren muss!).

Grüße,

StefanLast edited by sohletz on Fri Mar 17, 2006 12:16 pm; edited 1 time in total

----------

## c_m

Portage wirst du auf jedem System brauchen.

Generelle Idee (ungetestet):

Mach dir ne Partition wo alles wichtigedrauf ist: dein Portagedir, gcc usw. einfach nach der installation rüberkopieren. Dann die originale durch symlinks ersetzen. jetzt die Platte unmounten. Wenn du die tools brauchst mountest du die partition. Wenn du das ganze auf ne externe HDD schiebst kannst du sogar sicher sein, das im falle einer kompromitierung deines Systems niemand die benötigte Partition einbinden kann

----------

## STiGMaTa_ch

 *c_m wrote:*   

> Portage wirst du auf jedem System brauchen.

 

Nicht wirklich. Ist aber seeehr empfehlenswert, ansonsten könnte man gleich LFS einsetzen.  :Very Happy: 

Um dein Problem zu lösen könntest du folgenden (ungetesteten) Ansatz wählen:

- Alle Rechner müssen vom selben Architekturtyp sein (z.B. alles i686 oder alles amd64 etc.)

- Auf einem Rechner (möglichst dem stärksten) kompilierst du die nötigen Pakete uns erstellt mit quickpkg zugleich ein tbz2 File vom jeweiligen Paket.

- Auf dem "remote" Rechner (also z.b. die Surfstation) muss portage installiert sein.

- Auf dem "remote" Rechner mountest du mittels NFS die "/usr/portage/packages" vom Rechner, welcher die Pakete erstellt hat oder du verwendest die PORTAGE_BINHOST Umgebungsvariable.

- Auf dem "remote" Rechner kannst du nun normal syncen, beim updaten musst du jedoch sicherstellen, dass er nur die Binary Pakete verwendet (glaube das war die emerge Option --getbinpkgonly (-G)).

Gleichzeitig kannst du auf den "remote" Maschinen gcc und weitere tools löschen.

Lieber Gruss

STiGMaTa

----------

## sohletz

 *STiGMaTa_ch wrote:*   

> Gleichzeitig kannst du auf den "remote" Maschinen gcc und weitere tools löschen.
> 
> 

 

So, wie Du es beschrieben hast, hatte ich mir das auch vorgestellt ... aufgrund meiner Unerfahrenheit mit Gentoo war für mich nur die Frage, ob man es hinbekommen kann, dass Portage wirklich *nur* binäre Pakete für die Aktualisierung verwendet und nicht plötzlich nach irgendeinem gcc oder make sucht bzw. anfängt, irgendwelche Quellen herunterzuladen.

Werde das demnächst in jedem Fall mal ausprobieren ... bin schon gespannt!  :Smile: 

Danke für die Hilfe und schöne Grüße,

Stefan

----------

## firefly

@STiGMaTa_ch:

wenn das package-dir(in dem die binary-pakete liegen) per NFS exportiert wird, dann langt ein 

```
emerge -K <paket>
```

für die PORTAGE_BINHOST variante kann man in der make.conf festlegen, das er nur binary-pakete laden soll.

Und zwar wenn man getbinpkg in die FEATURE-variable hinzufügt.

----------

## dakjo

Ich frage mich nur, was ein gcc mit der sicherheit des systems zu tun hat.

Angenommen, ich breche in ein system ein und finde kein gcc vor, ja dann nimm ich halt nen binaer paket, oder bau das zeug quasi @home.

----------

## firefly

das hochladen und das installieren/einrichten kostet zeit und das kann dazu führen, das der einbruch in das system bemerkt wird.

Und zum anderen, wenn du weist, das das system ein x86 system ist, dann brauchst du auch keinen gcc auf dem   system, in dem du eingebrochen bist.  Dann übersetzt du halt dein "schad-programm" ohne spezielle optimierungen auf eine cpu, und schon gehts auch ohne gcc.

Wenn jemand auf einem System root-rechte erlangt, dann ist eh alles zu spät. Denn dann kann er machen was er will.

Am besten ist immer noch so wenige Angriffspunkte wie möglich zu bieten.

D.h. nur die wirklich notwenigen dienste laufen lassen und diese soweit wie möglich sicher konfigurieren.

Und zweitens, wenn du dein system im bezug auf bugfixes aktuell hälst, dann ist die gefahr das bei dir jemand einbrichen kann relativ gering.

Aber eine 100% sicherheit gibts eh nicht. (sollte jeder wissen)

----------

## Anarcho

 *dakjo wrote:*   

> Ich frage mich nur, was ein gcc mit der sicherheit des systems zu tun hat.
> 
> Angenommen, ich breche in ein system ein und finde kein gcc vor, ja dann nimm ich halt nen binaer paket, oder bau das zeug quasi @home.

 

Das habe ich mich auch gefragt. Als wenn man exploits nur auf der Zielmaschine bauen könnte...

Das ist so änhlich wie der Tipp sshd auf nem anderen Port lauschen zu lassen. Das schrumpft zwar die Logs aber bedeutet trotzdem nicht das man nun 3-Zeichen Passwörter nehmen kann.

----------

## dakjo

 *firefly wrote:*   

> .....
> 
> Und zweitens, wenn du dein system im bezug auf bugfixes aktuell hälst, dann ist die gefahr das bei dir jemand einbrichen kann relativ gering.
> 
> Aber eine 100% sicherheit gibts eh nicht. (sollte jeder wissen)

 

Und genau da sehe ich die gefahr wenn kein gcc, portage etc. auf dem System läuft. Wer mountet den erst ne andere Platte zu updaten etc.

Um systemnsicherheit zu erreichen gibt es wesentlich bessere möglichkeiten.

/me möchte da auf das Gentoo security-handbook verweisen.

----------

## nic0000

 *dakjo wrote:*   

> Und genau da sehe ich die gefahr wenn kein gcc, portage etc. auf dem System läuft. 

 

Naja, das wird jetzt aber nicht die little vs. bigendian diskussion, oder?

 *dakjo wrote:*   

> Wer mountet den erst ne andere Platte zu updaten etc.

 

Wahrscheinlich er, weil er nun diesen Weg verfolgen möchte.

Ich schätze zwar den Zwang von Gentoo sich mehr um die OS interna kümmern zu müssen als z.B. bei Debian oder ganz besonders Susi aber für manche Anwendungen ist es schlichweg nicht der richtige Weg. 

Wenn er damit experimentiert und womöglich vielleicht neue Werkzeuge Entwickelt, daß würde ich schon gutheißen. 

Wenn er scheitert, dann benutzt er halt wieder was binäres.

Nicht alles schon am Anfang kleinreden.

----------

## sohletz

Also ich find's ja witzig, dass hier eine Diskussion über Sicherheit angebrochen ist, obwohl es mir eigentlich nur darum ging, ein Produktionssystem ohne Portage einzurichten. Ich bitte mal zu beachten, dass ich nicht nur von gcc gesprochen habe, sondern von "Entwicklungsumgebung" bzw. "gcc, make, *etc.*".

Es geht mir ja nicht nur um gcc, sondern um ein einfaches Grundprinzip des Härtens von Systemen: Software, die nicht benötigt wird, um einen bestimmten Dienst zur Verfügung zu stellen, fliegt runter. Nehmen wir etwa einen Web-Server oder Firewall-Rechner. Viel zu tun hat so ein Rechner nicht. Jedenfalls benutze ich einen Server nicht, um Software zu entwickeln. Was also hat gcc auf einem Server verloren?

Wenn jemand remote auf so einem System einbricht (z. B. über Buffer-Overflow in iptables), dann sollte es doch das Ziel sein, die Möglichkeiten zum Herunterladen von Binärpaketen (z. B. Root-Kits) soweit es nur irgendwie geht zu beschränken. Dürfte verdammt viel Mühe kosten, macht aber meiner Ansicht nach Sinn. Selbst "root" dürfte es nämlich schwer haben, Binärpakete herunterzuladen, ohne die entsprechenden Pakete (ftp, lynx, scp, wget, usw.) dafür vorzufinden. Zumindest habe ich noch keinen Hacker gesehen, der eine Installations-CD durch ein Kabel jagen und in das entfernte Laufwerk legen kann, um weitere Software zu installieren. Die genannten Maßnahmen sollten - wenn ordentlich durchgeführt - zumindest Skript-Kiddies abwehren.

Nun kann der Hacker aber programmieren. Schnell ein C-Programm geschrieben, was eine Socket-Verbindung zu einem HTTP-Server öffnet und die benötigten Pakete herunterlädt. Ist ja nicht sooo umfangreich. (Leider geht das auch mit Perl, mit PHP, etc. - diese Programme nerven ebenfalls!)

Beachte: andere Sicherheitsmaßnahmen sind natürlich ebenfalls notwendig.

Vollständige Sicherheit lässt sich zwar nicht erreichen, aber warum soll ich einem Hacker das Leben leicht machen, indem ich ihm die absolut komfortable Möglichkeit biete, sich mittels Portage jede beliebige Software auf eine Firewall runterladen zu können?

Wenn hier also gefragt wird, welchen Sinn es macht, gcc *nicht* zu installieren, dann frage ich mal umgekehrt, welchen genauen Sinn es haben soll, ein Programm wie gcc auf einer Firewall zu installieren? Wozu braucht Ihr das?

Ansonsten möchte ich anmerken, dass ich ursprünglich von Windoof auf Linux/Unix umgestiegen bin, weil MS mich dazu zwingt, allen möglichen *SCHEISS* auf meinem Rechner mitzuinstallieren, den ich eigentlich gar nicht haben will! Bei Linux war das mal anders, aber als ich gestern die neue SuSE 10.0 gesehen habe, hätte ich echt kotzen können. Zum Glück muss ich die bei mir zu Hause nicht benutzen. Es geht mir auch darum, mein System schlank zu halten und wenn ich lese, dass Portage bereits 500 MB wegnimmt, dann frage ich mich, wozu ich diesen Platz auf einem Produktionssystem verschwenden soll (samt 2 GB Empfehlung für /var, nur um kompilieren zu können?). Nachdem ich irgendwann von der SuSE enttäuscht war, bin ich auf OpenBSD umgestiegen. Finde ich gut, aber Linux interessiert mich trotzdem noch (mehr Software, häufiger anzutreffen, etc.). Jetzt suche ich nach einem guten Linux-System und ich dachte, Gentoo wäre vielleicht was für mich. LFS kannte ich bisher noch nicht, aber das werde ich mir sicher mal ansehen.

Schöne Grüße,

Stefan

----------

## Anarcho

Wir wollen dir deinen Plan ja nicht schlecht reden. Sicherlich ist es Vorteilhaft wenn der Server schlank ist.

Aber, und das ist ja dann auch was du ja ursprünglich wolltest, wenn du bei Gentoo auf den gcc verzichtest, dann musst du

einigen Aufwand treiben um Updates einspielen zu können. Aber gerade das ist auf nem Server sehr wichtig. 

Dem Aufwand steht der minimale Sicherheitsgewinn gegenüber, denn auch wenn kein gcc, make usw. auf der Maschine ist,

so sogar wenn nichtmal perl, python, php usw. auf der Maschine ist, kannst du es nicht verhindern das der Angreifer trotzdem

Programme nachladen kann wenn du z.b. den Rechner per ssh verwartetst.

Hier mal ein Beispiel:

- Hacker entdeckt das du ne Fehlerhafte Version von Programm X installiert hast (möglicherweise weil das updaten so umständlich ist)

- Hacker bekommt über dieses Programm ne root-shell

- Hacker merkt das er kein wget, kein perl, kein ... hat

- Hacker hat nun folgende Möglichkeiten:

   a) er kopiert mittels scp ne Binary hoch und hat das entsprechende Programm (z.b. statisch kompiliertes wget)

   b) er benutzt nen Hexeditor um das Binary direkt abzutippen

   c) er benutzt ein möglicherweise anderes Programm was er dazu umfunktionieren kann

- Hacker hat nun ein wget und installiert darüber nen statischen gcc

- Hacker kompiliert nun lustig vor sich hin

usw.

Also wie du siehst ist es nur ne Frage des Aufwandes. Ich persönlich würde da lieber einfacher Updates einspielen können um damit die Gefahr schon in Punkt 1 zu unterbinden.

Wie gesagt, das gilt eher der Aufklärung, hier will dir keiner ans Bein pissen.

----------

## nic0000

 *Anarcho wrote:*   

> Also wie du siehst ist es nur ne Frage des Aufwandes. 

 

Das weiß er aber schon, zumindest scheint er kein n00b zu sein  :Wink: 

 *Anarcho wrote:*   

> Ich persönlich würde da lieber einfacher Updates einspielen können um damit die Gefahr schon in Punkt 1 zu unterbinden.

 

Ich auch

 *Anarcho wrote:*   

> Wie gesagt, das gilt eher der Aufklärung, hier will dir keiner ans Bein pissen.

 

Das sollte unterstrichen werden, denn häufig macht der Ton die Musik.

----------

## firefly

man kann die größe Portage-verzeichniss auch verkleinern in dem man die ebuilds von nicht benötigte kategorien/programme beim syncen ausschliest.

siehe hier

Da du bestimmt über binär-pakete das system updaten möchtest (dazu braucht man kein automake,gcc und co.) dann kannst du dir ein simplen alias oder nen wrappere für emerge schreiben, welches standard-mäßig nur binärpakte installieren möchte.

ein alias könnte in etwa so aussehen:

```
alias emerge='emerge -Q -K'
```

der -Q parameter sagt emerge, das es versuchen soll nicht vorhandene binär-pakete von dem über PORTAGE_BINHOST eingestellten host zu laden.

der -K parameter ist dafür da, das emerge nur binärpakete zum installieren verwenden soll.

----------

## sohletz

 *Anarcho wrote:*   

> Dem Aufwand steht der minimale Sicherheitsgewinn gegenüber, denn auch wenn kein gcc, make usw. auf der Maschine ist,
> 
> so sogar wenn nichtmal perl, python, php usw. auf der Maschine ist, kannst du es nicht verhindern das der Angreifer trotzdem
> 
> Programme nachladen kann wenn du z.b. den Rechner per ssh verwartetst.

 

SSH (bzw. scp) hatte ich in meine Liste der zu entfernenden Programme bereits mit aufgenommen.  :Wink: 

Du hast Recht: notfalls tippt der Hacker halt die Nullen und Einsen der Binärdatei ab. Oder benutzt einen Assembler. Finde ich persönlich jedoch aufwendiger, als ein C-Programm oder gar ein Perl-Skript zu schreiben.

 *Anarcho wrote:*   

> Also wie du siehst ist es nur ne Frage des Aufwandes.

 

Das bezweifele ich nicht. Absolute Sicherheit gibt es nicht. Aber wie weit man das mit der Sicherheit treiben will, das hängt von den eigenen Annahmen, von den Bedürfnissen und davon ab, wie man gewisse Risiken einschätzt. Ich könnte mir vorstellen, dass sich der Gelegenheitshacker lieber ein anderes Opfer sucht, wenn er das Download-Programm erst mühselig in Form von Nullen und Einsen eingeben oder scp disassemblieren muss, um zu begreifen, dass es sich um eine manipulierte Version handelt, deren Zugriff auf bestimmte Server und Programme beschränkt ist. (Zumal der Disassembler auf dem Rechner nicht vorhanden ist.) 

Wie "minimal" der Sicherheitsgewinn ist, ist wohl Ansichtssache.

Automatische Updates allein sind auch nicht der Weisheit letzter Schluss. Die helfen wenig, wenn ich einen ganzen Haufen von Programmen auf dem Rechner habe, die potentielle Sicherheitslücken enthalten. Und das tun leider alle Programme. Je mehr Code, desto mehr Sicherheitslücken (auch unveröffentlichte!). Ich möchte mich nicht darüber ärgern müssen, dass jemand ausgerechnet über ein Programm in meinen Rechner kommt, das ich einfach hätte löschen können, weil ich's gar nicht brauche. Und mich nervt es, wenn mir ein System das Entfernen in diesem Fall nicht erlaubt.

Bei OpenBSD z. B. lassen sich Binärpakete völlig problemlos gänzlich ohne Ports-System auf andere Systeme aufspielen, obwohl OpenBSD wie Gentoo portbasiert ist. Ein Skript, das sich immer die aktuellsten Pakete von einem zentralen Server zieht und die alten gegen die aktuellen austauscht, ist auch nicht schwer zu programmieren. Ich hatte gehofft, dass sowas mit Gentoo ebenfalls realisiert werden kann. Laut den anderen Beiträgen scheint es sooo kompliziert ja auch nicht zu sein.

Ich bin gerade bei der Installation und hoffe aufgrund der anderen Beiträge und Tips das Beste. 

Danke jedenfalls für die vielen Antworten und die spannende Diskussion.  :Smile: 

Viele Grüße,

Stefan

PS: Nur mal so als Gedanke zu Kosten/Nutzen-Rechnungen. Inwiefern lohnt sich der Installationsaufwand von Gentoo im Vergleich zum Nutzen eines optimierten Systems? Andere Distros lassen sich wesentlich einfacher installieren, ebenso Windows. Das hat z. B. auch ein automatisches Update-System.

----------

## Anarcho

Letztendlich sind hauptsächlich solche Programme verwundbar die auch erreichbar sind. Und da der gcc erst erreichbar ist, wenn man schon ne shell...

naja, wie schon gesagt, muss jeder selber wissen.

Ich persönlich verwende Gentoo auf Produktivsystemen weil ich die Installation von Software so genial finde (daher kommt es für mich auch nicht in Frage den gcc runterzuschmeissen) und weil es NICHT Versionsbasiert ist.

----------

## STiGMaTa_ch

 *sohletz wrote:*   

>  *Anarcho wrote:*   Dem Aufwand steht der minimale Sicherheitsgewinn gegenüber, denn auch wenn kein gcc, make usw. auf der Maschine ist,
> 
> so sogar wenn nichtmal perl, python, php usw. auf der Maschine ist, kannst du es nicht verhindern das der Angreifer trotzdem
> 
> Programme nachladen kann wenn du z.b. den Rechner per ssh verwartetst. 
> ...

 

Und wie wartest du dann das System? Nur noch direkt von der Konsole aus? Und was ist, wenn du grad 150Km entfernt bist und einen Anruf kriegst, dass da grad was "komisches" im Gange ist auf dem Rechner? Warten und wertvolle Zeit vergeuden bis du die drei Staus durchquert hast und in der Zwischenzeit den Hacker einfach mal walten lassen?

Dem Anrufer raten "Stecker ziehen"???

 *sohletz wrote:*   

> [...]Ich könnte mir vorstellen, dass sich der Gelegenheitshacker lieber ein anderes Opfer sucht, wenn er das Download-Programm erst mühselig in Form von Nullen und Einsen eingeben[...]

 

Schon mal von Copy&Paste gehört?

 *sohletz wrote:*   

> oder scp disassemblieren muss, um zu begreifen, dass es sich um eine manipulierte Version handelt, deren Zugriff auf bestimmte Server und Programme beschränkt ist. (Zumal der Disassembler auf dem Rechner nicht vorhanden ist.) 

 

Ich behaupte sogar, dass dein modifiziertes scp Programm (das nur auf bestimmte Server/Programme beschränkt wurde) viel besser zum hacken genutzt werden kann als ein ganz normales scp out of the box. Warum? Weil der Mensch tendenziell faul ist.

Wenn du scp immer auf dem neusten Stand haben willst, musst du auch jedesmal deine Aenderung (Server/Programmbeschränkung) wieder einpflegen. Auf dem Papier ist das eine gute Idee, in der Praxis wirst du tausend Gründe finden warum du "gerade eben mal" die alte Version drauf lässt. Und schon hat dein System ein zwar beschränkteres scp, dafür eines mit einer Sicherheitslücke.

 *sohletz wrote:*   

> Wie "minimal" der Sicherheitsgewinn ist, ist wohl Ansichtssache.

 

Nein, der Sicherheitsgewinn ist messbar. Und das entfernen von gcc auf einem System erhöt, bzw. gefährdet die Systemsicherheit schlichtweg in keinster Weise. Warum?

Weil gcc oder andere Compiler/Interpretersprachen etc. schlichtweg zu umständlich sind.

Wenn ich in dein System eindringen will, überprüfe ich erst einmal welche Dienste du mir denn überhaupt zur Verfügung stellst. Dann muss ich in etwa herausfinden in welchen Version, bzw. in welchem Umfang dieser Dienst seine Services zur Verfügung stellt. Dann muss ich hoffen, dass mindestens ein (besser mehrere) Exploit(s) bekannt ist.

Wenn nichts dergleichen Möglich ist, habe ich schon einmal keine Chance auch nur irgend etwas "ungewolltes" mit deinem Server anzustellen. Daher ist es mir in dem Moment erstmal sowas von egal ob da nun gcc drauf ist oder nicht.

Gehen wir nun aber davon aus, dass du irgendwas übersehen hast. Jetzt habe ich wieder mehrere Möglichkeiten.

Möglichkeit 1: Durch einen Fehler kriege ich Zugang auf deinen Rechner. Allerdings nur mir den Rechten des jeweiligen Dienstes (welcher hoffentlich NICHT als root läuft). Wenn ich jetzt auf Daten aus bin, die im Zusammenhang mit den angebotenen Diensten stehen (Kreditkarten Informationen, Passwörter, whatever), dann stehen meine Chancen schon mal nicht schlecht. Die Chance besteht, dass ich anhand von z.B. php DateienZugang zu mysql Datenbanken erhalte, welche wiedeurm interessante Infos liefern.

Tendenziell wird mir dieser Eingeschränkte Zugang jedoch nichts nützen, wenn ich z.b. einen Daemon für einen neuen "bösen" Dienst nutzen will (wegen fehlender Berechtigungen) oder wen ich tiefer in dein Netzwerk eindringen möchte (Grösstenteils, weil z.B. der Benutzer apache, nobody, mysql oder was auch immer sich an anderen Systemen gar nicht anmelden kann).

Bis hier hin habe ich keinen gcc oder andere Kompiler Tools benötigt.

Möglichkeit 2: Durch einen Fehler kriege ich eine komplette Root Shell auf deinem Rechner. Nun, in diesem Moment hast du einfach nur verloren. Ich bin jetzt der Master of Desaster auf diesem Rechner. Und glaube mir, das letzte was ich hier suche ist das vorhanden sein eines gcc's. Was nicht passt wird halt passend gemacht. Wenn ich auf deinem System keine Tools finde, mit denen ich z.B. was runterladen kann, dann mach ich mir eben schnell eines. Aber warum sollte ich dafür den Aufwand mit gcc, ev. nicht vorhandenen Lib's und dergleichen antun, wenn ich das benötigte Programm einfach mittels copy Paste auf dein System transferieren kann?

Ich nehme meinen Rechner, kompiliere das benötigte Tool als statisches binary und schreibe mir schnell einen Bash-Script welcher das binary in normale Zeichen umwandelt. Das so erzeugte File (welches nun keine Steuerzeichen etc. mehr enthält) kopiere ich mittels Copy&Paste nun einfach in eine Datei auf deinen Rechner. Dort noch schnell einen shellscript schreiben, welcher diese Datei wieder in ein binary verwandelt und fertig ist mein wget binary (oder was auch immer).

Tja, damit sauge ich mir dann runter, was immer ich möchte. 

Wie du siehst, ist auch hier der gcc nicht nötig.

Möglichkeit 3: Durch einen Pufferüberlauf gelingt es mir Befehle auf dem System ausführen zu lassen und wenn ich glück habe, kann ich mir sogar den erzeugten Output anzeigen lassen. Nun, auch in diesem Fall ist das letzte was ich tun werde irgendwelche hunderte Zeilen von Sourcecode auf dein System zu pasten (z.B. indem ich deinen Rechner anweise ein (echo "Zeile 1 vom Sourcecode") ausführen zu lassen) und diesen Sourcecode dann zu kompilieren versuchen (sind alle Libs vorhanden, sind alle benötigten Tools da etc.).

Viel einfacher ist auch hier wieder das verwenden der aus Möglichkeit 2 bekannten Methode. Und wieder ist gcc auch hier nur hinderlich.

Und jetzt lass mal deine Argumente hören, welche stichhaltig aufzeigen dass z.b. ein gcc die Sicherheit wesentlich vermindern oder einem Hacker in die Arme spielt.  :Wink: 

Ich gehe ehrlich gesagt sogar soweit, dass ich behaupte dein "verkrüppeltes" System wird sogar ein viel leichteres Ziel für einen Hacker als ein ganz normales Gentoo System. Der Grund ist einfach. Mit den von dir genannten Verkrüppelungsmechanismen (ich nenn die jetzt einfach mal so  :Smile:  ) ist das System schwieriger und umständlicher zu warten. Dies wiederum sorgt zwangsläufig dafür, dass dein System länger ungeschützt im Netz steht.

Das kannst du mit folgendem Beispiel einfach sehen:

Ein Server, welche nur Apache (ohne PHP etc.) am laufen hat steht im Netz. Die einzige Angriffsfläche die diese Maschine bietet ist der Kernel (resp. TCP/IP) sowie der Apache (Port 80). Solch ein Rechner braucht nichtmal eine Firewall, da diese die gesammte Kommunikation zwischen Apache und dem Kunden/Hacker eh durchlassen müsste. Und einen anderen offenen Port gibt es nicht...

Also. Wir haben nun also zwei solcher Rechenr. Meinen und deinen. Der einzige Unterschied zwischen diesen Rechnern besteht darin, dass ich ein Gentoo-Out-of-the-Box verwende, während du mit dem löschen Unzähliger Tools ein vermeintlich sichereres System hast.

Nungut, wir erfahren beide zur selben Zeit vom einem Sicherheitsloch im Apache so gross wie ein Scheunentor. Was jetzt passiert ist folgendes:

Mein Rechner: Ich logge mich (intern) mittels ssh auf meinen Server (welcher im Keller steht) ein. Nach einem kurzen Sync emerge ich die aktuellste Apache Version welche bis auf den Fix keine weitere Aenderung (von wegen neue Konfigfiles etc.) nach sich zieht. Arbeitsaufwand --> 2 Min Tastatureingabe, 13 Minuten Wartezeit auf Sync und Kompilieren. Fertig, der Apache ist wieder gesichert.

Dein Rechner: Mühsam musst du Stufe für Stufe bis in den Keller watscheln (Der Lift will auch nach 3 Minuten noch nicht anhalten). Dies, weil du ja kein sshd auf dem Server laufen lassen willst. Zuerst setzt du dich jedoch an deinen Spielrechner und gehst das syncen und emergen durch. Sobald das getan ist paketierst du den neuen Apache sowie alle neuen Abhängigkeiten. Diese Pakete schiebst du nun auf den NFS Server.

Jetzt loggst du dich auf dem Apache Server via Konsole ein und ziehst das Paket vom NFS runter. Nun musst du zuerst einmal den Apache stoppen. In Ermangelung eines emerge Befehls löscht du die benötigten Apache Files (und Abhängigkeiten) von Hand. Danach installierst du die vom NFS geholte Binary + Abhängigkeiten ebenfalls wieder händisch. Dein Aufwand, eine gute Stunde.

Abgesehen davon, dass du 45 Minuten länger zum updaten benötigt hast, hat dir das fehlen all der Tools überhaupt nichts gebracht. Es ist sogar so, dass dein System viel länger als Angriffsziel gedient hat. Wenn nun das nächste mal auch die Konfigs etc. angepasst werden müssen, schaut es noch schlechter für dich aus. Dein Apache muss noch länger down sein, was ev. sogar bedingt den geplanten Update auf einen späteren Zeitpunkt zu verlagern, weil andere auf den Apache vielleicht angewiesen sind.

Lieber Gruss

STiGMaTa

----------

## sohletz

Zunächst mal danke für diese umfangreiche Antwort. Hat echt geholfen und so langsam klärt sich in meinem Hirn einiges.  :Wink:  Jetzt kapiere ich, dass jemand mit Copy&Paste trotzdem Code auf den Rechner bringen kann. Daran hatte ich so nicht gedacht und damit hast Du mich überzeugt. Hier bringt es wirklich nichts, gcc zu entfernen.

Woran ich allerdings auch gedacht hatte, das waren mögliche Sicherheitslücken in gcc (oder make, flex, libtool, usw.). Sprich: der Hacker hat zwar keinen Root-Zugriff, aber eine normale Benutzershell. Nachdem ich mich über Bugtraq schlau gemacht habe, bin ich etwas beruhigter: so viele Schwachstellen gibt es in den Tools scheinbar nicht, zumindest keine bekannten. Das Risiko ist also tatsächlich gering. Obwohl es vor etlichen Jahren möglich gewesen wäre, als normaler Benutzer über gcc Root-Zugriff zu erlangen, sobald Root irgendwas kompiliert! (Hier wäre es nicht gut gewesen, gcc auf dem Rechner zu haben.)

Zum Vorgang des Updates mit Binärpaketen möchte ich allerdings noch anmerken, dass ich versucht hätte, das mit einem Skript/Programm zu automatisieren. Der Rechner, auf dem Portage installiert ist, hätte sich also z. B. jede Nacht die neuesten Pakete und Patches gezogen und kompiliert, die dabei entstandenen Binärpakete auf einem Server abgelegt, von dem sich alle verwalteten Rechner dann die neuesten Binärpakete runtergezogen und diese installiert hätten - natürlich unter Berücksichtigung gewisser Abhängigkeiten (also automatischer Stop der betroffenen Dienste, Update, erneuter Start der Dienste). Falls das wegen geänderter Konfigurationsdateien nicht klappt, so ließe sich dieser Vorgang natürlich auch rein manuell anstoßen, wäre aber nicht zwingend mehr Arbeit, als Du mit Deinem manuellen Update per SSH gehabt hättest. Nur das Programm dafür will natürlich erstellt werden.

Also noch mal Danke für die Aufklärung. Ich lasse Portage und gcc jetzt auf dem System.  :Smile: 

Liebe Grüße,

Stefan

----------

## Anarcho

 *sohletz wrote:*   

> Zunächst mal danke für diese umfangreiche Antwort. Hat echt geholfen und so langsam klärt sich in meinem Hirn einiges.  Jetzt kapiere ich, dass jemand mit Copy&Paste trotzdem Code auf den Rechner bringen kann. Daran hatte ich so nicht gedacht und damit hast Du mich überzeugt. Hier bringt es wirklich nichts, gcc zu entfernen.

 

Diese Erkenntnis hättest du auch schon nach meinem Post haben können...

 *sohletz wrote:*   

> Nur das Programm dafür will natürlich erstellt werden.

 

Welches wieder potentielle Sicherheitslöcher haben kann...

 *Quote:*   

> Ich lasse Portage und gcc jetzt auf dem System. 

 

Na endlich   :Wink: 

----------

## nic0000

 *sohletz wrote:*   

> Zum Vorgang des Updates mit Binärpaketen möchte ich allerdings noch anmerken, dass ich versucht hätte, das mit einem Skript/Programm zu automatisieren. Der Rechner, auf dem Portage installiert ist, hätte sich also z. B. jede Nacht die neuesten Pakete und Patches gezogen und kompiliert, die dabei entstandenen Binärpakete auf einem Server abgelegt, von dem sich alle verwalteten Rechner dann die neuesten Binärpakete runtergezogen und diese installiert hätten - natürlich unter Berücksichtigung gewisser Abhängigkeiten (also automatischer Stop der betroffenen Dienste, Update, erneuter Start der Dienste). Falls das wegen geänderter Konfigurationsdateien nicht klappt, so ließe sich dieser Vorgang natürlich auch rein manuell anstoßen, wäre aber nicht zwingend mehr Arbeit, als Du mit Deinem manuellen Update per SSH gehabt hättest. Nur das Programm dafür will natürlich erstellt werden.

 

Das halte ich trotzdem für eine sehr gute Idee, wenn mehrere identische (Hardware) Rechner verwaltet werden sollen ist das IMHO ein durchaus gehbarer Weg. Dann noch einen Schritt weiter zu gehen und Packete vorzubauen um sie bei wunsch/bedarf zu installieren zu können. 

Wenn das sich Automatisieren ließe, währe endlich mal den ganzen Gentoo hassern der Wind aus den Segeln genommen.

Ich weiß zwar nicht ob es euch ähnlich geht, aber ich treffe ziemlich häufig solche (Besonders viele Debian-Nutzer). Wobei mir durchaus klar ist, das diese sich meistens nur bedrohtfühlen in ihrer Gottgleichen-Status, egal ein anderes Thema...

Also ich halte absolut nichts davon portage, gcc etc. vom System zu schmeißen aber ich halte sehr viel von der Option ein Gentoo-Netzwerk mit binären Packeten versorgen zu können ohne sich gleich die Finger zu brechen.

----------

