Aufgrund der Brisanz des MoAB hab ich hier mal ein wenig zum Thema Sicherheit in OS X zusammengestellt. Ich hoffe, dass auch Anfänger durch meine Argumentation durchsteigen und das Ding zumindest bis (fast) zum Ende lesen, da es ziemlich wichtiges, elementares Wissen rund um die Sicherheit im OS X ist, dass eigentlich jeder beherzigen sollte, um keine bösen Überraschungen zu erleben 
Das Original stammt von meinem Weblog.
Das Original stammt von meinem Weblog.
Special: Mac OS X und Sicherheit
"Hello, I'm a Mac - And I'm a PC" - Wir alle kennen wohl die lustigen Ads von Apple, in denen auf teils recht zynische Art und Weise mit den Nachteilen eines "normalen" PCs gegenüber den Vorteilen eines Macs abgerechnet wird. Einer dieser Spots dreht es sich natürlich auch um die Viren-Problematik eines Windows-PCs: Der Mac reicht dem PC ein Taschentuch und schlägt damit dessen Ratschlag aus, ihm doch lieber nicht zu nahe zu kommen, weil man sich doch anstecken könne. Dies sei allerdings nicht zu befürchten, da Viren nur eine Gefahr für PCs darstellen - nicht für Macs.
Was ist an dieser Behauptung eigentlich dran..? Richtig ist, dass Windows-Viren nicht gefährlich für Macs sind, denn ein Mac kann logischerweise nichts mit Windows-Binaries ("EXE-Dateien") anfangen. Aber was ist mit dem Rest? Könnten spezielle Mac-Viren programmiert und z.B. über präparierte Websites im Netz verbreitet werden? Wie sicher ist man mit einem Mac eigentlich?
Ein bisschen Historie
Um das Sicherheitskonzept des Mac OS X zu verstehen, lohnt es sich einen Blick "unter die Haube" zu werfen: Das "X" in OS X ist nämlich nicht nur die römische Ziffer für 10, sondern sie deutet noch auf etwas anderes hin. Streng genommen ist OS X der Nachfolger des Betriebssystems NeXTStep, einem Produkt der Firma NeXT, die in den 80er Jahren von Steve Jobs nach seinem Ausstieg bei Apple gegründet wurde. NeXTStep wie OS X basieren auf BSD, einem Derivat des UNI"X"
Die Motivation von Unix war, ein Betriebssystem zu entwickeln, mit dem verschiedene Benutzer simultan an einem (Groß-)Rechner arbeiten können. Dazu war es nötig, jeden einzelnen User mit restriktiven Benutzerrechten auszustatten und sie bestimmten (Arbeits-)Gruppen zuzuordnen, damit nicht "wie wild" Dateien im Dateisystem geschrieben oder vielleicht sogar gelöscht werden konnten. Dieses Sicherheitskonzept hat sich nun seit nun über 35 Jahren bewährt und ist demnach logischerweise auch ein elemantarer Bestandteil von OS X bzw. von "Darwin" (dem eigentlichen Betriebssystemkern des OS X)
Sie haben das Recht zu schreiben
Das Rechte-Management in einem Unix- bzw. Unix ähnlichen Betriebssystems sieht vor, dass jede Datei und jedes Verzeichnis im Dateisystem verschiedene Rechte besitzt. Dabei unterscheidet man zwischen Lese- (r), Schreib- (w) und Ausführ-Rechten (x), die dann dem Dateibesitzer, der zugehörigen Gruppe und "allen anderen" zugewiesen werden. Diese Ansammlung von Rechten ist in einem String (Zeichenkette) dargestellt, der aus neun bzw. zehn Zeichen besteht. Ist ein bestimmtes Recht für den Benutzer, die Gruppe oder alle anderen nicht gesetzt, ist dies mit einem Minuszeichen (-) vermerkt. In der Praxis sieht dies z.B. so aus:
(Ausgabe in der Terminal.app)
Code:macbookpro:~ stylez$ ls -l /etc/syslog.conf -rw-r--r-- 1 root wheel 823 Aug 19 12:36 /etc/syslog.conf
In diesem Fall sehen wir, dass die Datei syslog.conf im Verzeichnis /etc den Besitzer root hat und der Gruppe wheel angehört. Die Rechte sind dabei so gesetzt, dass der Eigentümer (root) Lese- und Schreibrechte besitzt (rw-), wobei die Gruppe (wheel) und "alle anderen" nur Leserechte (r--) besitzen. Da es sich bei der Datei um eine Konfigurationsdatei handelt, sind logischerweise für niemanden die Ausführungsrechte gesetzt.
Der Besitzer root ist in Unix-Umgebungen derjenige User, der im Dateisystem Schreib- und Leserecht für alle Dateien und Verzeichnisse hat. Er ist quasi der Oberhäuptling (Super-User) des Systems
Unix kontra OS X
Beim OS X gesellt sich zum Super-User (root) nun noch eine weitere Sicherheitsinstanz mit dem Namen Admin (admin) hinzu. Dies sorgt insbesondere bei Switchen für Verwirrung, da sie i.d.R. nicht zwischen Admin und Super-User unterscheiden. Der Grund dafür ist, dass im OS X Dateisystem einige Verzeichnisse existieren, die in einem Unix-Dateisystem keine Rolle spielen. Dazu gehören z.B. die Verzeichnisse /Library (Konfigurationsdateien, Frameworks etc.) oder /Applications (Programme), die sich in Sachen Datei- bzw. Verzeichnisrechte von Unix-Systemressourcen wie beispielsweise /usr unterscheiden:
(Ausgabe in der Terminal.app)
Code:drwxrwxr-x 71 root admin 2414 Jan 27 18:18 Applications drwxrwxr-t 55 root admin 1870 Dec 21 21:02 Library drwxr-xr-x 11 root wheel 374 Nov 21 21:01 usr
Bevor wir auf die eigentlichen Unterschiede eingehen, sei zuvor erklärt, dass ein "d" im Dateizugriffs-String ein Verzeichnis (Directory) bezeichnet und das "t" bei Library dafür sorgt, dass nur der Besitzer (in diesem Falle root) aus diesem Verzeichnis löschen darf.
Nun aber zu den eigentlichen Unterschieden: Zunächst sehen wir, dass alle drei Verzeichnisse zwar dem Benutzer root gehören, sie aber nicht alle der gleichen Gruppe zugeordnet sind. Das (Unix-)Verzeichnis /usr ist dabei der Gruppe wheel zugeordnet und die anderen beiden Verzeichnisse der Gruppe admin. Der oben erwähnte OS X Admin-User ist i.d.R. Mitglied der Gruppen admin und staff, während der Super-User allen anderen Gruppen angehört. Der Admin-User besitzt also für das das Verzeichnis /usr (als "alle anderen") nur Lese- und Ausführ-Rechte (r-x), während er für /Library und /Applications (als Mitglied der Gruppe "admin") ebenfalls Schreibrechte (rwx) besitzt.
Wem das jetzt alles zuviel trockene Theorie war, merke sich einfach, dass es beim OS X neben dem Super-User und dem "normalen" User einfach noch jemanden gibt, der rechtemäßig quasi zwischen den beiden anzusiedeln ist.
Die Problematik
...liegt quasi auf der Hand, wenn man bedenkt, dass der Standard-User (d.h. der User, der bei der Installation von OS X angelegt wird) von Anfang zur admin Gruppe gehört, d.h. er besitzt Schreibrechte für die o.g. Verzeichnisse /Library und /Applications. Im Rahmen des MOAB (Month of Apple Bugs) sind nun mehrere Schwachstellen aufgetaucht, die diesen Umstand für bösartige Zwecke ausnutzen. In einem Beispiel erstellt ein Script eine manipulierte BOM (Bill of Material) Datei in /Library/Receipts, die zusammen mit einer Schwachstelle im diskutil Tool dafür ausgenutzt werden kann, Datei- und sogar Verzeichnisrechte zu manipulieren, um Backdoors ins System einzunisten.
Wie wir sehen ist das mit den potentiellen Mac-Viren doch gar nicht so utopisch, wie es viele eingefleischte Apple-Jünger gerne darstellen
Die (notwendige) Lösung
Das oberste Prinzip sollte sein, dass der standardmäßig eingestellte Admin-User für die normalen Arbeiten am Mac (Surfen, Mails etc.) tabu sein sollte! Am besten mal erstellt sich unter Systemeinstellungen -> User einen seperaten Admin-User, loggt sich über ihn im System ein, entzieht dem "normalen" User die voreingstellten Admin-Rechte und loggt sich schließlich wieder als "normaler" User ein. Das wars.
Wer jetzt denkt, dass diese Veränderung sein normales Arbeiten mit dem Mac erschwert, weil man sich für bestimmte Aktionen immer extra als Admin-User einloggen muss, der irrt. Versucht man z.B. nun als normaler User in das Verzeichnis /Library zu schreiben, so wird OS X anmerken, dass für diese Aktion nicht die nötigen Rechte vorhanden sind und das dafür die gewünschte Operation die Eingabe einer Admin-Kennung notwendig ist. Damit ist gleichzeitig sichergestellt, dass der User sich nicht in seinem Workflow "gestört" fühlt, aber auch dass sich keine "bösartigen" Dateien unbemerkt in jene Verzeichnisse einnisten.
Some more geeky stuff at the end
(Für alle, die noch Luft haben...)
Wenn man sich jetzt wundert, warum nicht - wie bei Unix ähnlichen Betriebssystem üblich - während der Installation ein Super-User, sondern "nur" ein Admin-User angelegt wird, dem sei gesagt, dass in OS X zwar ein Super-User existiert, er aber per default deaktiviert ist. Will man auf ihn aus irgendeinem Grund nicht verzichten, so ist eine Möglichkeit ihn im Netinfo Manager (Dienstprogramme) freizuschalten.
Das Home-Verzeichnis des Super-Users befindet sich nicht wie alle anderen im Verzeichnis /Users, sondern unter /var/root. Um sich dann bei Systemstart als root einzuloggen, wählt man im Anmeldefenster die Option "Andere" und gibt als Kennung root und das zugehörige Passwort ein.
Fraglich ist allerdings, ob es wirklich nötig ist den Super-User explizit freizuschalten, da es mehrere Mechanismen gibt, die das arbeiten als root zu ermöglichen. Einer ist natürlich der allseits bekannte Unix-Befehl sudo, bei dem Gebraucht vom setuid gemacht wird, um ausführbare Programme nicht mit den Rechten des momentan eingeloggten Users, sondern mit denen des Besitzers (wie z.B. root), auszuführen. Allerdings sind "normale" User in OS X nicht dazu berechtigt, den sudo-Befehl im Terminal abzusetzen, da sie sich nicht in der Liste der sudoers in /etc/sudoers befinden. Um diesen Umstand zu ändern, erweitere man die Liste in der beschriebenen Datei auf folgende Art und Weiese:
(Ausschnitt der Datei /etc/sudoers)
Code:# User privilege specification root ALL=(ALL) ALL %admin ALL=(ALL) ALL stylez ALL=(ALL) ALL
In diesem Falle wurde der User stylez in die Liste der sudoers eingetragen.
Ein weiterer Mechanismus ist das erstellen sogenannter Credentials. Credentials sind wohl jedem OS X User schon mal begegnet, nämlich dann, wenn man z.B. Veränderungen in den Systemeinstallungen vornimmt. In diesen Fällen "poppt" ein Fenster hoch und man wird um die Eingabe eines Admin-Namens und eines Admin-Passworts gebeten.
Viele Unix- bzw. Linux-Switcher denken in einem solchen Fall vielleicht an das eben erwähnte setuid denken, welches ja auch in diversen KDE, Gnome etc. Frontends verwendet wird, aber das Verfahren ist ein anderes. Vereinfach dargestellt ist ein Credential eine zeitweise Erlaubnis, die vom System ausgestellt wird, um diverse Aufgaben zu erledigen, die Rechte eines Super-Users zu benötigen. In diesem Fall wird z.B. ein Credential für system.preferences benötigt.
Um noch einmal den Unterschied zu verdeutlichen: Der User wird durch ein Credential nicht zum Super-User (ein Admin ist nach der Eingabe der Kennung immer noch ein Admin), sondern er bekommt nur das zeitweise Recht eine bestimmte Datei bzw. Verzeichnis zu verändern.
Eine Gefahr dabei ist, dass die Ausstellung dieser Credentials in OS X an einigen Stellen aus Kompatiblitätsgründen automatisiert ist, d.h. für einen Admin-User kann für bestimmte Operation ein Credential automatisch erstellt werden, ohne dass vorher eine entsprechende Kennung gefordert wird. Wie man sieht ist dies noch ein weiterer Grund, um für seine normalen Arbeiten mit OS X auf die Benutzung eines Admin-Users zu verzichten
Die wird es nirgendwo geben... wer auf der Datenautobahn durch die Gegend "braust" muss sich genauso anschnallen wie auf der Autobahn. Daher würde ich letzten Endes immer zum Gebrauch orbiger Maßnahmen raten. Nennen wir das einen Sicherheitsgurt - doch behalten wir im Auge, dass Glatteis immer gefährlich ist. Egal womit man unterwegs ist. 
