Ergebnis 1 bis 7 von 7

Thema: [NYC10] - 08 - Know the UNIX

  1. #1
    Moderator
    Registriert seit
    May 2000
    Beiträge
    1.368
    Renommee
    1285

    bash [NYC10] - 08 - Know the UNIX

    Willkommen zur New Year's Challenge 2010 im Themenbereich UNIX-Systeme.

    Die Challenge besteht dieses Jahr aus 10 Fragen, vorwiegend zu den grundlegenden Ideen und Konzepten hinter dem Design der UNIX-Betriebssysteme, aber auch einigen allgemeineren Fragen.

    Der Schwierigkeitsgrad der Fragen variiert stark - einige Fragen werden für UNIX-Fans No-brainer sein, hier können sich auch Teilnehmer, die sich bisher wenig mit UNIX beschäftigt haben, durch etwas Recherche-Arbeit einige wertvolle Punkte für die Gesamtwertung der NYC10 verdienen. Andere Fragen werden vielleicht sogar für UNIX-Gurus eine Herausforderung sein, es sollte also einigermaßen spannend werden.

    Für vollständig beantwortete Fragen gibt es je einen Punkt, wenn die Antwort knapp dran ist, gibt es einen halben Punkt.

    Die Challenge startet heute gleich mit 2 Fragen:

    1.) Warum wurden ursprünglich die Namen fast aller Systemutilities (ls, cp, mv, ...) auf nur wenige Buchstaben reduziert?
    (Hinweis: "Damit man nicht so viel tippen muss" ist offensichtlich und noch nicht die ganze Wahrheit; wir wollen wissen, welche Auswirkung man sich durch diese Namensgebung erhofft hat)


    LÖSUNG
    Oft findet man die Begründung, dass die früher noch langsameren Terminalleitungen einer der Gründe waren, dass man die Länge der Befehle kurz gehalten hat. UNIX-Systeme übertragen allerdings schon lange die meisten Eingaben zeilenweise, nicht byte-weise, daher wird den langsamen Terminalleitungen möglicherweise mehr Bedeutung beigemessen, als sie tatsächlich hatten.
    Ein weiterer bis heute gültig gebliebener Grund hängt dennoch einfach mit der Schreibfaultheit der Anwender und den daraus folgenden Auswirkungen zusammen: Man wollte erreichen, dass sich auf UNIX-Systeme ein vielzahl modularer und leistungsfähiger Utilities entwickelt, wobei jedes nur eine bestimmte Funktionalität möglichst universell, dafür aber in hoher Qualität und mit offenen Schnittstellen, bereitstellt. Die gewünschte Operation erreicht man schließlich dadurch, dass man diese Utilities mit Hilfe der Shell kombiniert.
    Müsste man dafür endlos lange Kommandokombinationen eingeben, dann hätten sich stattdessen vermutlich bald anstatt der universellen, flexiblen Module für jeden speziellen Anwendungszweck große, starre Monsterprogramme mit Menüoberflächen entwickelt, so wie man das von vielen anderen Systemen kennt.
    Bis heute kann man auf UNIX-Systemen beispielsweise verschiedenste Daten mit dem Utility "sort" sortieren - während auf vielen anderen Systemen immer noch in jeder einzelnen starren Monsterapplikation das Rad wieder neu erfunden wird - ein Dateimanager mit eigener Sortierfunktion, ein Prozessmanager mit eigener Sortierfunktion, eine Usermanager mit eigener Sortierfunktion.
    Man hat weit vorausgedacht: Die Geschwindigkeit der Terminalleitungen ist mittlerweile gestiegen, die unserer Finger beim Schreiben auf der Tastatur aber leider nicht. ;-)


    2.) Welche Environment-Variable könnte bei der Ausführung privilegierter dynamisch kompilierter Binaries eine Sicherheitslücke bewirken, und wird daher normalerweise ignoriert?

    LÖSUNG
    LD_LIBRARY_PATH, LD_PRELOAD
    Diese Variablen geben Pfade an, von denen der dynamische Linker Libraries lädt, die vom Binary benutzt werden. Würde der Linker die Variablen bei privilegierten Binaries beachten, könnte ein Angreifer eine Funktion des Binaries durch eigenen Code ersetzen, indem er den Linker eine eigene Library laden lässt. Der Code des Angreifers würde dann im Kontext des privilegierten Binaries zur Ausführung kommen.
    Aus diesem Grund werden Variablen wie LD_LIBRARY_PATH und LD_PRELOAD vom Linker bei der Ausführung privilegierter Binaries ignoriert. Auf einigen Derivaten tragen die Variablen mit der prinzipiell selben Funktionalität andere Namen, beispielsweise LIBPATH (AIX) oder SHLIB_PATH (HP/UX).


    (Einsendeschluß für die Antworten zu den Fragen 1 und 2 war der 19. Jänner 2010, 20:00 CET (2010-01-19T19Z))
    Geändert von octogen (28.01.2010 um 22:55 Uhr)
    Segmentation fault (core dumped)

  2. #2
    Moderator
    Registriert seit
    May 2000
    Beiträge
    1.368
    Renommee
    1285

    Re: [NYC10] - 08 - Know the UNIX

    3.) UNIX repräsentiert Peripherie, wie z.B. Festplatten, und diverse logische Funktionalität, z.B. die Partitionen von Festplatten oder einen Zufallszahlengenerator, als Datei. Wofür benutzt der UNIX-Kernel die Major-Number und Minor-Number dieser Dateien?
    (Gefragt ist das technische Prinzip, mit dem der UNIX-Kernel anhand Major/Minor-Number herausfindet, welche Funktion er ausführen soll)


    LÖSUNG
    Der UNIX-Kernel verwaltet Tabellen mit den Adressen der Funktionen, durch die Dateioperationen (open, read, write,...) für verschiedene Dateitypen implementiert werden: die character device switch table für character devices und die block device switch table für block devices. Die Major-Number der jeweiligen Datei dient als Index zu einem Eintrag in dieser Tabelle. Der Eintrag enthält die Adressen der Treiberfunktionen für jede Dateioperation, oder einen nulldev-Eintrag, wenn eine Dateioperation nicht unterstützt ist (z.B. kein write auf readonly-devices). Der jeweilige Syscall verwendet lädt dann die Adresse der entsprechenden Treiberfunktion und führt die Funktion aus.
    Die Minor-Number wird als Parameter an die jeweilige Treiberfunktion übergeben, ihre Bedeutung ist somit treiberspezifisch.


    4.) Auf modernen UNIX-Systemen gibt es einen Dateityp, der das Aufbauen von lokalen Kommunikationskanälen wie über ein Netzwerk ermöglicht. Ein darüber kommunizierender Prozess kann feststellen, in welchem Benutzerkontext der Kommunikationspartner läuft, oder sogar Filedescriptoren übermitteln.
    Um welchen Dateityp handelt es sich, und wie erkennt man ihn im Filesystem (z.B. mit ls -l)?


    LÖSUNG
    POSIX local IPC socket, besser bekannt als UNIX domain socket
    Wie der Name schon sagt, handelt es sich dabei um ein Socket für Interprozesskommunikation. Es kommen die üblichen Netzwerk-APIs zur Anwendung (socket(), bind(), listen(), accept(), connect(), ...). Der Socket ist als Datei im Dateisystem abgebildet, wobei der Pfadname die gleiche Funktion erfüllt wie beispielsweise IP-Adresse und Portnummer bei einer TCP/IP-Netzwerkverbindung.
    In einem Long-Listing (mit ls -l) wird der Socket üblicherweise mit dem Typ "s" angezeigt:
    s-w------- 1 challenge staff 0 2010-01-09 14:22 foobar


    (Einsendeschluß für die Antworten zu den Fragen 3 und 4 war der 23. Jänner 2010, 23:00 CET (2010-01-23T22Z)
    Geändert von octogen (28.01.2010 um 23:22 Uhr)
    Segmentation fault (core dumped)

  3. #3
    Moderator
    Registriert seit
    May 2000
    Beiträge
    1.368
    Renommee
    1285

    Re: [NYC10] - 08 - Know the UNIX

    5.) Üblicherweise ist jeder Prozess der sogenannte "Child-Process" jenes anderen Prozesses, der ihn gestartet hat. Daher verfügt er selbst über einen Eintrag, welcher andere Prozess sein sogenannter "Parent-Process" ist. Doch was passiert mit diesem Parent-Process-Eintrag, wenn der Parent-Process beendet wird während der Child-Process noch läuft?

    LÖSUNG
    Der Child-Prozess wird "adoptiert", üblicherweise vom init-Prozess, der meistens die Prozess-ID 1 hat. Mittlerweile gibt es einige UNIX-Derivate, wo das so nicht mehr stimmt, aber das Prinzip dürfte dennoch immer noch überall gleich geblieben sein: Irgendein spezieller Prozess adoptiert alle Parent-losen Child-Prozesse.


    6.) Welche sicherheitsrelevanten Einstellungen bezüglich der Filesysteme sollte man vornehmen, wenn man Automounting von Wechselmedien (z.B. USB-Sticks, SD-Cards, externe Festplatten, etc.) konfiguriert?

    LÖSUNG
    Diese Frage könnte man natürlich sehr breit auffächern; zum Einsammeln der Punkte reichen aber zwei der wesentlichsten und offensichtlichsten Punkte:
    Die Optionen nodev und nosuid für das Mounten der Filesysteme.
    Ohne der Option nosuid könnte ein geeignetes Filesystem eine Datei enthalten, die privilegiert ausgeführt wird, egal wer sie startet.
    Ohne der Option nodev könnte ein geeignetes Filesystem eine Datei enthalten, die als Device-Node angelegt ist, und z.B. eine Festplatte oder den Kernel-Memory repräsentiert, und deren Berechtigungen so eingestellt sind, dass jeder Schreibzugriff hat.
    In beiden Fällen baut man am System ein riesiges Scheunentor ein, das man quasi mit einem x-beliebigen zuhause präparierten USB-Stick aufsperren kann. Daher gehören diese beiden Optionen zu den wichtigsten Konfigurationseinstellungen für das automatische Mounten von Filesystemen, deren Herkunft man nicht kennt.


    Einsendeschluß für die Antworten zu den Fragen 5 und 6 war der 26. Jänner 2010, 23:00 CET (2010-01-26T22Z)
    Geändert von octogen (28.01.2010 um 23:43 Uhr)
    Segmentation fault (core dumped)

  4. #4
    Moderator
    Registriert seit
    May 2000
    Beiträge
    1.368
    Renommee
    1285

    Re: [NYC10] - 08 - Know the UNIX

    7.) Auf niedrigen (IP-)Portnummern laufen oft sicherheitsrelevante Prozesse wie SSH (Port 22). Im Fall von SSH ist die Kommunikation verschlüsselt, und der Port 22 läßt sich von keinem anderen Prozess nutzen, da er von SSH bereits als Serverport geöffnet wurde, der Port scheint also auf den ersten Blick ohnehin gut geschützt zu sein. Aus welchem Grund kann man üblicherweise die Netzwerk-Ports mit einer Portnummer kleiner als 1024 trotzdem nur als "root" (bzw. mit entsprechenden Privileges) öffnen?

    LÖSUNG
    Die Idee hinter der Sperrung niedriger Portnummern für nicht-privilegierte Benutzer war, dass es einem normalen Benutzer gelingen könnte, einen durch einen vertrauenswürdiger Prozess gesperrten (da bereits in Benutzung befindlichen) Port zu übernehmen, indem er zuerst ein Denial-of-Service-Attack auf den jeweiligen Prozess ausführt, so dass dieser crasht, und anschließend den Port für einen eigenen Prozess öffnet, der z.B. ein trojanisches Pferd implementiert.
    Dazu bleibt oft nur ein kurzes Zeitfenster, da Prozesse wie telnetd, ftpd auf manchen Systemen automatisch neu gestartet werden. Mit geschicktem Timing könnte es trotzdem gelingen, mit einem eigenen Prozess den Port zu reservieren, bevor es der neu gestartete vertrauenswürdige Prozess schafft.
    Um diese Situation generell zu verhinden wurden Ports mit einer Nummer unter 1024 für vertrauenswürdige Services reserviert und für normale Anwender generell gesperrt.


    8.) Auf UNIX-Systemen tauchen zeitweilig Einträge in der Prozessliste auf, die nicht auf Signale reagieren, und die man daher nicht mit den ansonsten üblichen Mitteln los wird. Diese Einträge sind in der UNIX-Welt unter einem recht originellen Namen bekannt. Wie nennt man sie, wie entstehen sie, wie wird man sie wieder los, und wofür sind sie eigentlich gut?

    LÖSUNG
    Einen solchen Eintrag bezeichnet man als Zombie-Process. Dabei handelt es sich eigentlich nicht um einen Prozess, sondern nur um einen Eintrag für den Exit-Code eines Prozesses, der bereits beendet ist. Der Eintrag bleibt solange in der Prozessliste, bis der Parent-Process des bereits beendeten Prozesses den Eintrag abfragt. Macht der Parent-Process das nicht, bleibt der Eintrag stehen und man sieht einen Zombie-Process in der Prozessliste, meistens mit der Bezeichnung "<defunct>".
    Um Zombies loszuwerden, sollte man versuchen, SIGCHLD an den Parent-Process zu senden, der dann die Exit-Codes der Zombies einsammeln sollte. Funktioniert das auch nicht, bleibt nur noch die Möglichkeit, den Parent-Process zu beenden.


    Einsendeschluß für die Antworten zu den Fragen 7 und 8 war der 29. Jänner 2010, 23:00 CET (2010-01-29T22Z)
    Geändert von octogen (31.01.2010 um 13:11 Uhr)
    Segmentation fault (core dumped)

  5. #5
    Registered User
    Registriert seit
    Sep 2008
    Beiträge
    402
    Renommee
    270

    Re: [NYC10] - 08 - Know the UNIX

    Hi, kannste bitte die alten Lösungen reineditieren? Danke!

  6. #6
    Moderator
    Registriert seit
    May 2000
    Beiträge
    1.368
    Renommee
    1285

    Re: [NYC10] - 08 - Know the UNIX

    Die Lösungen zu den bereits abgelaufenen Fragen 1-6 stehen hiermit zur Verfügung. Die Lösungen zu den Fragen 7 und 8
    und die neuen Fragen 9 und 10 kommen voraussichtlich am Samstag gegen Mittag.
    Segmentation fault (core dumped)

  7. #7
    Moderator
    Registriert seit
    May 2000
    Beiträge
    1.368
    Renommee
    1285

    Re: [NYC10] - 08 - Know the UNIX

    Leider erst mit einem Tag Verspätung, aber hier sind sie jetzt: Die letzten beiden Fragen zur Unix-NYC10:

    9.) Warum lässt sich bei modernen Betriebssystemen, wie z.B. den meisten modernen UNIX-Derivaten, oft nicht so eindeutig sagen, wie viel Hauptspeicher ein bestimmter Prozess in Anspruch nimmt?

    LÖSUNG
    Manche Speicherbereiche werden nicht von einem einzelnen Prozess verwendet, sondern von mehreren - beispielsweise shared libraries. Wie viel Hauptspeicher freigegeben würde, wenn ein bestimmter Prozess beendet wird, hängt unter anderem davon ab, ob andere Prozesse die selben Libraries ebenfalls benutzen oder nicht. Ein anderes Beispiel ist der system call fork(), der einen Prozess dupliziert; der Duplikat-Prozess benutzt solange die gleichen Speicherseiten, bis einer der beiden Prozesse eine Speicherseite ändert - erst dann kriegt jeder Prozess seine eigene Kopie der Speicherseite (copy-on-write).


    10.) Was sind die Vor- und Nachteile einer Methode zur Verwaltung von Virtual Memory, bei der das Betriebssystem den Anwendungen Hauptspeicher zuweist, ihn aber tatsächlich erst dann reserviert, wenn die Anwendung den Hauptspeicher auch wirklich beschreibt?
    (Achtung: Es geht nicht um die Verzögerte Zuweisung der Speicherseiten beim Beschreiben, sondern um die Reservierung der dafür potentiell benötigten Speichermenge)


    LÖSUNG
    Gemeint war hier eine Art der Speicherverwaltung, die unter anderem als "lazy commit", "deferred page space allocation" oder "memory overcommit" bekannt ist. Dabei reserviert das Betriebssystem den Speicher, den Prozesse anfordern, nicht sofort, sondern erst, wenn der angeforderte Speicherplatz wirklich benutzt wird.
    Der Vorteil der Methode ist eine effizientere Speichernutzung (näher am Limit), womit auch Systeme mit wenig Hauptspeicher in der Praxis relativ viele größere Applikationen parallel ausführen können. Ebenso kann ein Prozess, der schon sehr viel Hauptspeicher in Anspruch nimmt, ein fork() ausführen (für die Nicht-Unixer: seinen Prozess duplizieren), beispielsweise um anschließend mittels execve() einen anderen Prozess zu starten (siehe auch die Anmerkung zu fork() in der Lösung zu Frage 9, daraus erklärt sich, warum der hier potentiell nötige Speicher oft nie wirklich benutzt wird).
    Der Nachteil der Methode ist, dass das System nicht mehr garantieren kann, dass der gesamte zugewiesene Speicher auch vorhanden ist. Wenn plötzlich doch mehr Speicherseiten benötigt werden als vorhanden sind, bleibt dem Kernel oft nur noch die Möglichkeit, willkürlich irgendeinen Prozess zu beenden.
    Auf einer Workstation, wo die Urlaubsphotos nachbearbeitet werden, ist das keine große Gefahr - schlimmstenfalls stürzt irgendetwas ab.
    Wenn man aber hohe Zuverlässigkeit benötigt, sollte man von dieser Methode der Speicherverwaltung eher Abstand nehmen; das System braucht dann zwar für manche Operationen mehr Speicher, aber dafür ist sichergestellt, dass die einer Anwendung zugesicherte Menge an Speicherseiten auch jederzeit zur Verfügung gestellt werden kann. Speicheranforderungen von Anwendungen, die das Betriebssystem nicht erfüllen kann, werden abgelehnt, dabei kann die Anwendung eigene Fehlerbehandlungsmethoden anwenden (z.B. warten, bis Speicher frei ist, einen Alarm auslösen, etc.).


    Die NYC10 Unix-Challenge ist geschlossen.
    Geändert von octogen (02.02.2010 um 00:43 Uhr)
    Segmentation fault (core dumped)

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Ähnliche Themen

  1. [NYC10] - 01 - Weltreise
    Von nait im Forum Contest Forum
    Antworten: 5
    Letzter Beitrag: 14.02.2010, 02:06
  2. [NYC10] - 09 - Quiz & More
    Von Rodnox im Forum Contest Forum
    Antworten: 30
    Letzter Beitrag: 30.01.2010, 22:48
  3. [NYC10] - 06 - MD5 checker
    Von dexcs im Forum Contest Forum
    Antworten: 5
    Letzter Beitrag: 19.01.2010, 20:56
  4. [NYC10] - 05 - Hidden Leaks
    Von Chb im Forum Contest Forum
    Antworten: 0
    Letzter Beitrag: 17.01.2010, 11:51
  5. Unix-Benutzer: Welches Unix-Derivat benutzt ihr?
    Von octogen im Forum UNIX/Linux
    Antworten: 9
    Letzter Beitrag: 12.06.2002, 18:29

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •