iPhone- / Mac-Hilfe



Defragmentierung, Macs & Mac OS X | Mac-Tipps von MacMark

Mit MacMark habe ich ausgiebig über Defragmentierung von Macs und Mac OS X geplaudert. Welche Mac-Tipps Markus noch auf Lager hatte erfährst du im Interview. May our Macs be with us!

MacMark.de | Mac OS X-Defragmentierung und Mac-Tipps | MacMark

Durch deine Homepage und verschiedene Foren bist du als MacMark bekannt. Was magst du noch über dich verraten?
MacMark.de betreibe ich neben Familie und Beruf. Ich bin Diplom-Informatiker (Uni) und arbeite seit etlichen Jahren als Programmierer. Dabei war ich zwischendurch mehrere Jahre selbständig und inzwischen aus familiären Gründen wieder festangestellt, aktuell als Senior Software Architect in Hamburg. Durch meinen Beruf habe ich jahrelang mit diversen Unices, GNU/Linux-Varianten und Windows-Versionen zu tun gehabt.

Mein erster Rechner war ein Apple // c Mitte der 80er. Während des Studiums bekam ich dann Anfang 1992 meinen ersten Mac: Einen Macintosh II ci mit System 7. Danach kamen etliche weitere Macs. Behalten habe ich nur den Apple // c mit eingebauter Z80-Karte, mit dem ich als Schüler programmieren lernte.

Der Name “MacMark” entstand aus der Not: Mitte der 90er hatten die Westwood Studios Command & Conquer (Tiberian Dawn) als Mac C&C portieren lassen und für die Online-Matches brauchte ich einen Namen. MarcAnton und Caesar und so weiter waren schon vergeben. So habe ich halt einen Namen gewählt, der die Summe aus mir und meinem Mac ist und die erlaubte Länge einhielt: Macintosh + Markus = MacMark. Den Namen habe ich danach generell verwendet, immer wenn ich einen Nickname brauchte.

Als ich Ende 2006 anfing mich für Apple, Mac, Mac OS X und alles drumherum zu interessieren bin ich auch über das Thema Defragmentierung und Mac gestoßen.

In den Foren liest man immer wieder und gebetsmühlenartig die selbe Antwort: “Ein Mac braucht nicht defragmentiert werden.“, “Lass den Mac ab und zu über Nacht an, dann optimiert und defragmentiert sich der Mac von alleine.” “Mac-Programme wie iDefrag gefährden das System bei der Defragmentierung mehr als sie dem System helfen.

Wo liegt denn nun die Wahrheit, in Sachen Mac und Defragmentierung, die Entwickler von iDefrag & Co, werden sich doch etwas dabei gedacht haben – Wie siehst du das Thema Mac OS X und Defragmentierung im allgemeinen und Defragmentierung unter Snow Leopard im speziellen?

Defragmentierung ist eines der typischen Switcher-Themen, weil es unter Windows nötig und gewohnt ist.

Der Begriff Defragmentierung ist jedoch nicht eindeutig. Landläufig ist damit die Zersplitterung von Dateien auf der Platte gemeint.

Vor vielen Jahren konnte man die physikalische Verteilung der Daten auf der Platte noch feststellen. Heutzutage mit Platten-Firmware, die die physikalischen Sektoren auf logische Sektoren abbildet, kann man die tatsächliche physikalische Verteilung nicht mehr feststellen. Alles sichtbare sind nur noch logische Sektoren, die die Platten-Firmware zeigt. Eine Defragmentierung gleich welcher Art findet also gar nicht mehr auf Basis der tatsächlichen physikalischen Belegung statt, sondern nur noch auf logischer Ebene. Das bedeutet, daß eine logisch anscheinend defragmentierte Platte physikalisch stark fragementiert sein kann und umgekehrt.

OS X auf HFS+ wirkt der Datei-Fragmentierung erfolgreich entgegen. Auf meiner Seite habe ich einen Abschnitt dazu: Keine Defragmentierung von Hand notwendig. Amit Singh (Mac OS X Internals-Autor) hat auf seiner Seite eine ausführliche Analyse dazu, auf die ich ebenfalls eingehe.

Der einzig typische Grund, bei OS X eine Defragmentierung durchzuführen, ist der Spezialfall, daß man eine weitere Partition auf der Platte anlegen möchte, der freie Speicher jedoch nicht in ausreichender Größe am Stück vorliegt. Dabei geht es jedoch nicht um Datei-Defragmentierung, sondern um Defragmentierung des unbenutzten Bereichs.

Zu den Detailfragen:

“Ein Mac braucht nicht defragmentiert werden.”

Richtig. Nur für nachträgliches Partitionieren ist Defragmentierung des freien (!) Speichers eventuell nötig.

“Lass den Mac ab und zu über Nacht an, dann optimiert und defragmentiert sich der Mac von alleine.”

Die periodischen Skripte haben nichts (!) mit Defragmentierung zu tun. Defragmentierung findet bei OS X auf HFS+ mit jedem Schreibzugriff statt. Die periodischen Skripte laufen übrigens auch nachträglich, wenn der Rechner nachts nicht läuft.

“Mac-Programme wie iDefrag gefährden das System bei der Defragmentierung mehr als sie dem System helfen.”

Korrekt. Ein Bug im Programm, versehentlicher Neustart oder Stromausfall während der Defragmentierung bedeutet Datenverlust. Zudem liegt keine nennenswerte Datei-Fragmentierung vor. Siehe Amit Singhs Artikel und Apples Doku, die ich beide verlinkt habe. Das deckt sich auch mit dem, was ich bei meinen Platten sehe. Also unnötiges Risiko und kein Gewinn.

…die Entwickler von iDefrag & Co, werden sich doch etwas dabei gedacht haben…

Aber man benötigt es nur, wenn überhaupt, vor dem nachträglichen Partitionieren. Nachträglich heißt, daß die Platte schon mit Daten eine Weile beschrieben wurde und nicht frisch formatiert ist.

Was empfiehlst du Einsteigern um Mac OS X sicherer zu machen?
Möglichst die Finger vom System zu lassen, also keine Programme zu installieren, die das System “verbessern”. Man sollte in den Safari-Einstellungen darauf achten, daß heruntergeladene Dateien nicht automatisch geöffnet werden. Außerdem nur die Dinge unter “Sharing” aktivieren, die man wirklich benötigt. Im Auslieferungszustand sind alle aus. Im Detail würde ich auf das PDF Security Configuration Guide von Apple verweisen, welches alle Details für die Praxis erläutert.

Es gibt durchaus Leute die Mac OS X als unsicher einstufen. Diese Stimmen kommen auch aus dem Linuxlager. Was denkst du darüber?
Solche Stimmen höre ich meist aus dem Windows-Lager. Von Seiten der GNU/Linux-User kenne ich derartiges eigentlich gar nicht. Ich könnte mir allerdings vorstellen, daß sie sauer auf OS X sind, weil es den Platz eingenommen hat, den sie für ihr System immer gewünscht haben: Das etablierte Desktop-Unix für den Normalverbraucher zu sein.

Ansonsten sind OS X und GNU/Linux zentrale Sicherheitsvorteile gemeinsam, beispielsweise einfach handhabbare und wirksame POSIX-Dateirechte plus optionale feinkörnigere aber komplexere und dadurch für Fehlkonfiguration anfällige ACLs; zudem sind keine unnötigen Netzwerkdienste aktiv; bei beiden findet man eine saubere Trennung der User untereinander und vom System.

Wenn ich die GNU/Linux-Varianten mit OS X vergleiche, gibt es drei interessante Punkte, die auffallen:

Das “Executable and Linking Format” (ELF), welches von GNU/Linux verwendet wird, hat im Vergleich zum “Mach-Object” (Mach-O) folgende Besonderheiten:
– ELF kann flexibel und kreativ manipuliert werden, was eine Infizierung erleichtert. Mit Mach-O haben Angreifer ein bißchen mehr Schwierigkeiten.
– ELF hat unter GNU/Linux (anders als unter Solaris) keine etablierte Unterstützung für Code Signing, wodurch Code-Manipulationen erkannt werden könnten. OS X hat Code Signing.

Bei üblichen Unices (und GNU/Linux) ist man entweder root oder kann fast nichts (“normal”). Das hat zur Folge, daß beispielsweise zur Installation von Programmen, die für alle Benutzer verfügbar sein sollen, auf root gewechselt werden muß. OS X hat eine Gruppe zwischen root und normal: Admins. Diese ermöglicht alltägliche administrative Aufgaben ohne daß man root werden muß. Wenn man vergleicht, wie oft man bei GNU/Linux und OS X auf root wechseln muß, dann sieht OS X sicherer aus.

Mandatory Access Control (MAC) ist fester Bestandteil von OS X. Die verfügbaren Linux-Kernel bieten nicht alle MAC, das unter anderem in Form von SELinux implementiert ist. Dadurch hatte Google mit der Umsetzung einer Sandbox für den Chrome-Browser auf Linux Schwierigkeiten, fand aber auf OS X gute und einfache APIs dafür vor.

Stell dir vor du triffst einen neuen Besucher auf macmark.de, welche Beiträge würdest du ihm empfehlen und warum?
Ich würde die Stellen empfehlen, die das Sandboxing behandeln, insbesondere, wie man Safari selbst sandboxen kann, weil es ein praktischer Sicherheitsgewinn ist.

Bist du als Admin oder als normaler User auf deinem Mac unterwegs?
Beides. Als Admin besteht die zusätzliche Möglichkeit, daß in /Applications und /Library geschrieben werden kann. Das /System und die Verzeichnisse der anderen User sind allerdings auch von OS X Admins nicht änderbar. Das kann nur wheel, die Gruppe von root. Da wir auf unseren Macs mehrere User haben, ist immer nur einer davon in der Admin-Gruppe, alle anderen sind normale User.

Welchen Quellen im Netz die sich mit Mac und Mac OS X beschäftigen vertraust du soweit das du sie empfehlen magst?

Mac-Buch Mac OS X Internals von Amit Singh | OSXBOOK.COM

Amit Singh hat nicht nur ein gutes Buch geschrieben, sondern auch viele interessante Artikel:
OSXBOOK.COM
Die Seite ist sehr komplex und hat auch ein Blog:
Mac OS X Internals – The Blog
Mit OSXFAQ bin ich vor vielen Jahren eingestiegen unter die Haube von OS X und halte es auch weiterhin für sehr gut:
Mac OS X Unix Tutorial und Mac OS X Unix Tricks

Sämtliche Doku auf Apples Seiten ist natürlich ein Muß, beispielsweise
Mac OS X Technology Overview

Die Artikel von John Siracusa auf ars technica Insbesondere seine Reviews von jeweils neuen OS X-Versionen.

Nicht ganz so technisch, aber meist korrekt analysiert schreibt John Gruber auf DARING FIREBALL Es ist eine der ganz wenigen Nachrichtenseiten, die wirklich selbst recherchiert und mit Verstand schreibt.

Jonathan “Wolf” Rentzsch hat seine Seite leider kürzlich umgezogen und sie ist noch nicht wieder mit Inhalt versorgt.

MacSurfer bietet seit Jahren eine aktuelle Übersicht über Mac-relevante Nachrichten. Wenn man wissen will, was los ist, dann genügt diese Seite.

Mac OS X Hints glänzt mit so manchem Hilfe-Tipp.

Wenn ich mal an einem Mac rumschraube, dann finde ich hier super Anleitungen: Mac Repair – iFixit

Ansonsten würde ich eher Bücher empfehlen, und zwar diese:
Interessante Technik-Bücher zu OSX

Gibt es Programme die jeder Macuser auf seinen Mac installiert haben sollte, wenn ja warum?
Cyberduck, um per Drag & Drop Webseiten zu pflegen.

GraphicConverter als Schweizer Taschenmesser für Bildbearbeitung inklusive Batch-Verarbeitung.

Integrity, um tote Links auf seiner Webseite zu finden.

FileJuicer, um Seiten und Bilder zu extrahieren aus Safaris Cache und diversen anderen Quellen.

Mactracker als Information über alle jemals erschienen Macs.

WakeOnLan, um Rechner im Netz aufzuwecken, wenn sie schlafen und man zugreifen möchte.

TeamSpeex um sich mit Mitspielern während Online-Spielen (Warcraft 3) zu unterhalten.

X-Chat Aqua, für IRC-Chats.

Region X, wenn man eine regionfreie DVD-Firmware eingespielt hat, und dann beliebig oft Sprachen umschalten möchte.

iMovie und iDVD für das Zusammenstellen und Brennen von Videos.

Zum Reparieren kann ich folgende Programme empfehlen:

• DiskWarrior, um das Dateisystem zu reparieren und
• Drive Genius zum Überprüfen physikalischer Platten-Probleme (und diverses anderes) sowie
• TechTool Pro als gutes Allzweck-Hilfsmittel für den ganzen Rechner und
• Data Rescue speziell zum Daten-Retten.

Diese Werkzeuge liefern gemeinhin bessere Ergebnisse als die Bordmittel und schaffen es auch, Festplatten, auf die nicht mehr zugegriffen werden kann, zu retten.

Und Warcraft 3: The Frozen Throne oder StarCraft 2, um in unserem Mac-Clan mitzuspielen mtn-clan.de ;-)

Mac-Spiele: Macuser können im MTN-Clan mitspielen | MacMark

Was sollte der ambitionierte Mac-Anwender über “sudo” wissen?
Er sollte die Manpages dazu kennen und verstehen, ansonsten die Finger davon lassen. Empfehlenswert dazu ist auch der Link oben auf OSXFAQ.

Eigentlich immer meine letzte Frage ich halte es für angebracht diese Frage jetzt schon zu stellen. Wonach würdest du gerne gefragt werden, worüber würdest du gerne reden und warum?
Vielleicht, was mich ärgert.

Das wäre, daß manche Leser nicht richtig lesen können. Wenn da zum Beispiel steht: “Dokument erstellt am 05. Mai 2005;
Diese Seite www.macmark.de/osx_security.php wurde aktualisiert am 18.01.2010 um 12:54:04 Uhr.”, dann glauben sie, die Seite wäre veraltet, weil angeblich von 2005. Wie kann man den Fettdruck übersehen?

Oder anderes Beispiel; Ich schreibe “keine durch ungeeignete System-Architektur bedingten Schwachstellen”, dann lesen manche daraus “keine Schwachstellen”, um mir dann zu unterstellen, ich würde Unfug schreiben.

Manche lesen nicht, was da steht, sondern was sie lesen wollen.

Das ist wie der Witz mit dem Mann, der auf jedem Bild, das ihm der Arzt zeigt, nackte Frauen sieht. Der Arzt zeigt ihm Bilder von Bäumen, Häusern, Blumen und der Mann sieht immer eine nackte Frau. Anschließend wirft der Mann dem Arzt vor, daß er ihm Schweinkram zeigen würde.

Setzt du in Sachen Mac-Sicherheit auf Verschlüsselung von Daten?
Wenn ich ein MacBook außer Haus mitnehme, nutze ich FileVault. Für geheime Daten “Secure Notes” in Keychain Access.

Welche Macs stehen bei dir herum?
Ein iMac G3 in blau für die Kinder, das MacBook meiner Frau hat unsere Jüngste kürzlich am Deckel gerissen und einen Wackelkontakt des Displays verursacht, mein MacBook und ein iMac Core 2 Duo. Der Bestand ändert sich jedoch häufig, weil wir gelegentlich die Geräte verkaufen und uns im Refurbished Store günstig etwas neueres holen. Die Preise für High-End-Modelle rechnen sich nicht für uns.

Was denkst du über IPhone, iPad und iPod?
Wir habe selber verschiedene iPhones und iPods im Einsatz. Bei älteren Firmware-Versionen konnte man beim iPhone noch den Unix-Boot-Prozeß anzeigen lassen, das war ziemlich cool anzuschauen. Das iPhone ist einfach klasse, außerdem kann ich diese winzigen Mäusetastaturen der anderen Telephone nicht leiden. Den älteren iPod Shuffle kann ich blind mit Winterhandschuhen durch die Jacke bedienen. Das iPad muß man mal in Ruhe abwarten. Für mich ist wohl das MacBook die bessere Wahl. Allerdings macht so eine iPad-Nutzung wohl ziemlich viel Spaß als iPhone in groß.
Das iPhone (und auch Macs) sind mir in IT-Firmen in jüngster Zeit unerwartet häufig begegnet. Da tut sich was.

Hast du eine Meinung zu der Strategie von Apple soweit man sie als Außenstehender beurteilen kann?
Als Apple Next kaufte und Steve damit zurückkehrte, wollte ich Aktien kaufen, hatte aber kein Geld. Das beste User-Interface auf einem Unix und Steves Charisma konnte nur richtig gut werden. Und bis auf die runde Maus, bei der man blind nicht wußte, wo vorne ist, haben sie ja dann auch alles richtig gemacht. OS X als System auf allen Geräten ist auch geschickt. Microsoft hat es da schwerer, weil sie für jede Plattform eine eigene Codebase haben, beispielsweise für Kassen, Telephone, Rechner.

Wie ist deine Meinung zu Spiele auf Mac, Steam for Mac und iPhone und iPad als Spieleplattform?
Für den Mac gab immer wieder gute Spiele. Allerdings nicht alle, die ich mir gewünscht hätte. Aber das wendet sich anscheinend langsam zum Guten. Das iPhone hat sich offenbar schon als Spieleplattform etabliert. Und da das iPad in der Regel alle iPhone-Programme nutzen kann plus spezielle eigene, die die höhere Auflösung brauchen, sollte dort sogar bald noch mehr los sein. Zumal auch Tastaturen angeschlossen werden können und Aktivlautsprecher und so weiter. Mit Steam habe ich mich noch nicht befaßt.

Herzlichen Dank! Das war Markus “MacMark” Möller.

Tillmann Scheele führte durch das Maclites Magazin Interview.

Aktualisiert am 18/11/2011

Tags: , , ,

9 Kommentare

  1. Defragmentieren ist gefährlich? “Ein Bug im Programm, versehentlicher Neustart oder Stromausfall während der Defragmentierung bedeutet Datenverlust.” Das bedeutet es genauso für normale Schreibzugriffe. Das hat mit Defragmentieren null zu tun.

    “Defragmentierung ist eines der typischen Switcher-Themen, weil es unter Windows nötig und gewohnt ist.”

    Warum muss eigentlich Liebe zum Mac so oft mit Seitenheiben auf Windows korrelieren? Vor allem mit falchen, die nur das tiefe Unwissen von einem selbst zeigen? Defragmentierung ist unter Windows seit Vista auch kein Thema, genauso wie beim Mac. Das erledigt das System automatisch im Hintergrund. Vielleicht wäre hier ein wenig mehr Recherche hilfreich anstatt mit pauschalem Windows-Bashing seine “Kompetenz” zu zeigen.

    “Es gibt durchaus Leute die Mac OS X als unsicher einstufen. Diese Stimmen kommen auch aus dem Linuxlager. Was denkst du darüber?”

    Klar das ein Mac-Liebhaber da als erstes wieder auf Windos losgehen muss *Kopfschüttel*:

    “Solche Stimmen höre ich meist aus dem Windows-Lager. Von Seiten der GNU/Linux-User kenne ich derartiges eigentlich gar nicht.”

    Vielleicht sollte Euer Experte da mal besser genauer hin hören. Vor allem, wenn er sich selbst anmaßt, über Security zu schreiben. Seine Seite ist voll mit Falschinformationen zu dem Thema. Wieso wohl werden Macs mit am schnellsten gehackt auf jedem Hacking Contest? Pwn2own-Fazit: “Mac hacken macht Spaß, Windows ist harte Arbeit”: http://www.heise.de/newsticker/meldung/Pwn2own-Fazit-Mac-hacken-macht-Spass-Windows-ist-harte-Arbeit-208604.html
    Was er als Sicherheitsgewinn gegenüber Linux aufführt, ist übrigens in Windows schon lange drin. Länger als in OS X. Das verschweigt er aber. Windows wird nur dort rausgeholt, um uralte Kamellen als Beispiele heranzuziehen.

    Es stört aber Euren Experten, wenn man sein “keine durch ungeeignete System-Architektur bedingten Schwachstellen” kritisiert. Mac OS X hat also die perfekte System-Architektur? Seit welcher Version denn? 10.0 oder vielleicht auch erst später? So eine Pauschalaussage ist doch nichts wert, wenn man dann tausende Sicherheitslücken, die in OS X und den mitgelieferten Anwendungen von Apple bisher gefixed wurden, die jegliche Sicherheitsstufe (auch die höchste) erreicht haben und die totale Kompromittierbarkeit des Systems ermöglichen, einfach abtut. Die haben alle nichts mit der System-Architektur zu tun?

    “Manche lesen nicht, was da steht, sondern was sie lesen wollen.” Manche biegen sich die Realität auch so hin, wie sie es wollen.

    Vielleicht solltet ihr mal den Hintergrund Eures “Experten” besser prüfen, bevor ihr so ein Interview macht. Seine Argumente aus dem Bereich Sicherheit wurden hier sehr schön widerlegt (man kann auch von Demontage sprechen): http://blogs.technet.com/sieben/archive/2010/04/23/keine-admin-rechte-sicherere-pcs.aspx

  2. Mmh, ein anonymer Kommentar. Nun gut.

    Lieber “xyz”,

    bei normalen Schreibzugriffen ist nur eine einzelne Datei in Gefahr, beim Defragmentieren die ganze Platte. Das sieht auch Amit Singh so. Wenn Du meinen verlinkten Artikel gelesen hättest oder Amits Artikel, wüßtest Du das auch ;-)

    Windows auf NTFS ist deutlich anfälliger für Fragmentierung als OS X auf HFS+. Ältere Versionen auf FAT waren noch anfälliger. Daher kennen Windows-User dieses Problem aus ihrem Alltag und fragen sich beim Switch zum Mac, ob sie das gleiche auch bei OS X vorfinden.

    Macs wurde nicht am “schnellsten” gehackt bei den Pwn2Own-Wettbewerben. Die Reihenfolge, in der die Leute ihre lange vorbereiteten Hacks vorführen, wird gelost. Niemand weiß genau, wie lange die Vorbereitung jeweils war. Daher kann von “am schnellsten” gar nicht gesprochen werden. Siehe auch die Details dazu hier:
    http://www.macmark.de/blog/osx_blog_2010-03.php#pwn2own_osx_2010_news_review
    http://www.macmark.de/blog/osx_blog_2010-03.php#pwn2own_prediction
    http://www.macmark.de/blog/osx_blog_2009-03.php#macbook_not_hacked_in_two_minutes_again
    http://www.macmark.de/blog/osx_blog_2008-12.php#macbook_not_hacked_in_two_minutes

    Die Einschätzung von Charlie Miller und Dino Dai Zovi “Mac hacken macht Spaß, Windows ist harte Arbeit” ist natürlich sehr subjektiv, weil beide erfahren Mac-Hacker sind, die auch ein Buch darüber geschrieben haben, welches ich auf meiner Seite empfehle.
    Allerdings hat Charlie auch einmal gesagt, daß er seine Lebensaufgabe darin sieht, Apple schlecht zu machen. Von daher kommen solche Aussagen nicht von ungefähr.
    Fachlich bezog sich die Aussage nicht pauschal auf OS X, sondern auf einen ganz speziellen Aspekt und zwar darauf, daß OS X Address Space Layout Randomization (ASLR) nur für Systembibliotheken vornimmt, nicht jedoch für Anwendungsprogramme. Das ist richtig, hat aber mit effektiver Sicherheit nicht viel zu tun: ASLR bietet keine tatsächliche Sicherheit, sondern positioniert einfach ausgedrückt interessante Codestellen an zufälligen Adressen. Um einen Exploit zu schreiben, muß man dann, falls man ASLR nicht umgeht, sozusagen noch eine Suche einprogrammieren. ASLR ist, als wenn man die Eingangstür jeden Tag an einer anderen Stelle an der Hauswand positioniert. Der Einbrecher findet sie trotzdem oder umgeht das Problem, indem er ein Fenster öffnet. Dazu gleich mehr.
    Das ASLR von Applikationen hat zudem weder Windows Vista noch Windows 7 genützt, denn es ist schon oft überwunden oder umgegangen worden, auch auf den oben angesprochenen Hacker-Wettbewerben.
    Die Uni Stanford hat sogar gezeigt, wie man aus einem Exploit, der ohne ASLR funktioniert, einen Exploit generieren kann, der gegen ASLR funktioniert.
    Peter Vreugdenhil hat mehrere generelle Wege (Proof of Concepts) gefunden, um ASLR und DEP auf 7 und Vista zu umgehen. Damit sind beide Techniken ziemlich wertlos.
    Zusammenfassend muß man also sagen, daß sich der “macht Spaß”-Spruch auf eine spezielle nur teilweise angewandte Technik bezog, die so oder so nur eine scheinbare Sicherheit bietet.

    Die Vorteile, die ich bezüglich OS X gegenüber GNU/Linux nenne, sind nicht “bei Windows schon lange drin”. Im Gegenteil:
    Das Portable Executable (PE) Format der Windows-Binaries ist eine modifzierte Version des relativ primitiven und uralten UNIX Common Object File Format (COFF). Auf UNIX ist das inzwischen durch das bessere Format ersetzt worden, welches auch Linux verwendet: Executable and Linkable Format (ELF).
    Das Code-Signing bei Windows bezieht sich hauptsächlich auf Kompatibilitätsaspekte, die von Microsoft damit abgesegnet werden. Vor allem ist es bei OS X flächendeckend inklusive Drittherstellern umgesetzt. Bei Windows bezieht es sich hauptsächlich auf Gerätetreiber und ähnliches.
    Die UAC ist kein Sicherheitsmechanismus. Mark Russinovich von Microsoft hat das in seinen Technotes deutlich beschrieben und auch Beipiele gezeigt, wie ein Low-Integrity-Process einen höheren beeinflussen kann, beziehungsweise, wie man aus einer Integritätsstufe ausbricht – by Design. Die UAC ist eine sehr mäßige umsetzung von Mandatory Access Control (MAC). Das ist bei Linux und OS X besser und vor allem wirkungsvoll umgesetzt.

    Die grundlegenden Architektur-Vorteile von OS X sind von Anfang an schon drin gewesen, also 10.0. Der grundlegende Aspekt ist, daß es auf jedem System immer Bugs geben wird. Die entscheidende Frage ist jedoch, was aufgrund solcher Bugs angestellt werden kann. Bei UNIX im Allgemeinen und OS X im Speziellen, trifft jede Art von Schadprogramm auf mehr Schwierigkeiten als auf Windows. Einfachstes Beispiel ist der Umstand, daß ein Windows-User trotz UAC dank der “gespaltenen Persönlickkeit” des sogenannten “Protected Administrators” Systemrechte hat, die ein Schädling nutzen kann um das System zu verändern. Wem das nicht klar ist, mag sich an Mark Russinovich von Microsoft wenden. Admins auf OS X haben keine Systemrechte. Das hat nur root oder die Gruppe wheel. Weitere Details finden sich auf meiner Seite.

    Viele Bug-Beschreibungen in der Presse sind reißerisch und irreführend. Insbesondere, wenn es um OS X geht.

    Die “Demontage” auf der von “xyz” angesprochenen Seite, dem Windows 7 Blog von Microsoft Deutschland, habe ich dort damals schon beantwortet. Wie Du mich schon richtig zitierst, ist diese “Demontage” ein Paradebeispiel für “manche lesen nicht, was da steht, sondern was sie lesen wollen.” Der “Demonteur” hat auch meine Korrekturen an seiner “Demontage” nicht verstanden und eine Diskussion abgelehnt.

    Und meinen Hintergrund sollte jeder kennen, denn ich bin ja nicht anoynm. Siehe dieses Interview und mein Impressum.

    Grüße von
    MacMark

  3. “bei normalen Schreibzugriffen ist nur eine einzelne Datei in Gefahr, beim Defragmentieren die ganze Platte.”
    Aha. Ist natürlich ein Problem der Software, richtig? Ein System-Architekturfehler kann es ja nicht sein, weil Max OS X per deiner Definition keine Architekturfehler hat. Oder haben darf. Hurra! Nur das auf anderen Systemen sowas nicht so kritische Auswirkungen hat.
    “Windows auf NTFS ist deutlich anfälliger für Fragmentierung als OS X auf HFS+…. Daher kennen Windows-User dieses Problem aus ihrem Alltag und fragen sich beim Switch zum Mac, ob sie das gleiche auch bei OS X vorfinden.”
    Die Defragmentierung unter Windows ist maßlos überschätzt. Seit Vista kümmert sich das OS im Hintergrund automatisch darum. Was hier eigentlich viel mehr eine Rolle spielt, ist die Tatsache, dass unbedarften Anwendern schon seit Jahren Schlangenöl verkauft wird. Es wird ein Geschäft gemacht mit Tuningsoftware und C0. Nur weil diese Software existiert, heißt das nicht, dass sie ein wirkliches Problem lösen. Es gibt diese Software vor allem, weil man damit Gewinn machen kann. Viele Tests haben gezeigt, dass derartige Software eher Schaden anrichtet, als Gutes tut. Trotzdem ist sie nicht auszurotten. Wenn Mac OS X genauso populär wäre wie Windows würdest Du auch 1000 und 1 Trick lesen können, den Apple den Anwendern verschweigt und hunderte Tuningtools kaufen können, die das richtig machen, was Apple ab Werk falsch macht (so jedenfalls die Behauptung derartiger Software). Du empfiehlst selbst, Anwender sollten möglichst die Finger vom System lassen, also keine Programme installieren, die das System “verbessern”. Das gilt genauso für Windows. Deine Gebashe an Windows ist da völlig fehl am Platz.
    Ob Defragmentierung wirklich auf einem Mac nichts bringt, sein mal dahin gestellt. Das wird von EXT2/EXT3 auch immer wieder behauptet, obwohl es falsch ist. Hat die c’t ja sehr schön gezeigt: http://www.heise.de/open/artikel/Fragmentierung-224380.html Mich würde es nicht überraschen, wenn für HFS+ gleiches gelten würde, weil die Optimierungsstrategien ja sehr ähnlich sind.
    Was Du weiterhin nicht bedenkst: Die automatische Optimierung, die beim Zugriff auf eine Datei da durchgeführt werden, kosten auf jeden Fall Performance, weil die IO-Operationen ja zusätzlich durchgeführt werden. Kennt Mac OS X überhaupt so etwas wie Low Priority IO? Ich denke nicht. Mir ist ein performantes OS lieber, das im Hintergrund optimiert, wenn der Benutzer das System nicht belastet, als eins, das genau dann optimiert, wenn der Anwender auf die Datei zugreifen will. Auch das halte ich für einen Architekturfehler. Aber Du erklärst mir bestimmt, dass das alles ganz toll so ist, wie es ist und die Performance überschätzt wird.
    Zu Pwn2Own: Mac OS X wurde als erstes gehackt. Deine Argumentation ist da Haarspalterei. Die kannst Du genauso auf alle anderen OSse übernehmen. Am Ende zählt, was dabei rauskommt und OS X hat sich als sehr leicht zu überwinden gezeigt. Du verteidigst Apple auch noch dafür, dass sie mehrmals als defekt bekannte Systembibliotheken in ihren Betriebssystemen übernommen und nicht auf dem aktuellen Stand gehalten haben. Das Gegenteil ist richtig: Apple hat keinen vernünftigen formalen Sicherheitsprozess über seine Systeme integriert. Da wäre das sonst aufgefallen. Da sie das nicht tun, ist es nicht verwunderlich ,dass bekannte und in der Quelle gefixte Sicherheitslücken bei Mac OS X lange ungepatched bleiben. Das ist kein Einzelfall und Apple bekleckert sich hier nicht nur nicht mit Ruhm, sondern setzt seine anwender grob fahrlässig unnötigen Risiken aus. Das ist nicht akzeptabel und auf keinen Fall so schönzureden, wie Du das machst.
    Das es Dir nicht passt, wenn ein Sicherheitsexperte sich auf Mac OS X eingeschossen hat, passt zu dem Bild, das Du abgibst. Mac OS X ist ja fehlerfrei und heilig – die Bösen sind die, die das kritisieren oder sogar wagen, den Beweis immer und immer wieder zu erbringen, wie schwach das System eigentlich ist. Jammer weiter – Windows und Linux wird von viel mehr Experten permanent versucht zu überwinden. Sei nur froh, dass sowenige sich bisher mit Mac OS X Security beschäftigen. Die Ergebnisse sind schon beschämend genug. Für wieviele kritische Sicherheitslücken ist Safari verantwortlich?
    Dein Kommentar zu ASLR und DEP zeigt auch, wieweit Dein Wissen langt. Beides sind Techniken, die Angriffe erschweren (nicht für immer verhindern). Sie machen es viel schwerer, Buffer Overflows auszunutzen. Nur dass es Wege gibt, sie zu überwinden, heißt nicht, dass sie unnütz sind. Sie verkleinern die Menge an ausnutzbaren Buffer Overflows signifikant und machen das Ausnutzen um Längen schwerer. Das ist der Wert dieser Technologien. Apple hat das natürlich auch erkannt und hat in der Weiterentwicklung von Mac OS X ASLR und DEP mit eingebaut. Kein Grund, das schlecht zu reden, wie Du es tust.
    Zum Code Signing: Microsoft ist einer der Vorreiter bei Code Signing. Code-Signing bei Windows bezieht sich eben nicht hauptsächlich auf Kompatibilitätsaspekte. Mich würde auch mal interessieren, was Du damit eigentlich meinst. Warum sollte Code signiert werden, damit er kompatibler ist? Von Microsoft ist so ziemlich alles signiert, was mit dem System ausgeliefert wird. Sehr viele Drittanbieter signieren ihre Software, nicht nur die Treiber. Seit 64-bit Windows Vista kann man nur noch signierte Kernel Module laden. Das übersiehst Du alles. Bei OS X ist das auch (noch) nicht flächendeckend inklusive Drittherstellern umgesetzt. Du kannst auf Mac OS X genauso unsignierten Code (noch) ausführen.
    Naja, später in Deinem Post wirfst Du noch mehr Dinge zusammen, um Äpfel mit Birnen zu vergleichen und schießt Dich wieder mal auf UAC ein. Nur vergißt Du, dass ein UAC-protected Admin eben kein Benutzer ist, sondern ein Admin. Nimm ein normales Benutzerkonto und Du hast genau die Absicherung, die Du Windows absprichst. Gegenbeispiel bei Apple gefällig? Nimm mal task_for_pid(), damit kann man Code injizierren via mach_inject. Bis Mac OS X 10.4 konnte man das als Benutzer – das ist zum Beispiel auch eine architekturelle Schwachstelle, die erst in neueren Mac OS X Versionen behoben wurde. Witzigerweise aber nur für unsignierten Code – signierter Code darf das weiterhin. Das ist genauso eine Schwachstelle, wie bei UAC, weil hier davon ausgegangen wird, dass Code sich an Regeln hält. Und dass der Signaturschutz von Apple ausgehebelt wird, zeigt sich ja jedes mal, wenn das iPhone OS wieder gerootet wird.
    Und Dein beharren auf “Admins auf OS X haben keine Systemrechte. Das hat nur root oder die Gruppe wheel.” – die Menge an Local Root Exploits, die es für Mac OS X gegeben hat und geben wird, zeigt, dass diese Unterscheidung marginal ist. Wenn der Bösewicht auf der Kiste ist (was dank Safari ja recht einfach ist), dann kann er sich die Rechte erhöhen und mit den dann erworbenen Rechten sich Zugriff verschaffen. Du hast solche Scheuklappen auf bei Deinen Lobliedern auf Mac OS X.
    Und zu dem Blog: Du hast es ja vorgezogen, auf seine Argumente nicht einzugehen, sondern lieber mit Logik zu argumentieren. Was nur besonders peinlich ist, weil das Argument von Dir falsch ist (Apache hat schon seit längerer Zeit mehr Sicherheitslücken als IIS) und Dein rotes Auto Beispiel ist auch falsch: Dein Kritikpunkt war eine Pauschalaussage “viel Marktanteil, darum viele Angriffe”. Das ist keine Pauschalaussage. Du machst eine daraus, indem Du behauptest: “Nur viel Marktanteil bedeutet viele Angriffe” und das Gegenteil beweist. Nur folgt niemand Deiner Behauptung. Das “nur” ist falsch und deshalb hilft Dir Aussagenlogik nicht weiter.
    Dass die Diskussion mit Dir abgelehnt wird, kann ich völlig verstehen. Der Autor der Seite hat doch jede Menge Deiner Argumente widerlegt. Punkt für Punkt. Anstatt dass Du darauf eingehst und Dich entweder verteidigst, oder die Fehler in Deiner Argumentation zugibst und Deine Seite korrigierst, weichst Du der Diskussion aus und kommst mit einem “rote Auto” Beispiel. Es ist kindisch, wenn Du dann hinterher hier klagst, dass ja niemand mit Dir diskutieren will. Du biegst Dir die Fakten so zurecht, dass sie zu Deiner Argumentation passen. Wieviel von dem Schlechtmachen von Windows, das Du betreibst, geht gegen Versionen älter als 10 Jahre? Was wäre, wenn jemand Mac OS 9 mit Windows 7 vergleichen würde und daraus den Schluss zieht, dass Apples Technologie schlechter ist? Da würdest Du doch auch vehement protestieren.
    Also entweder machst Du Deine Aufgabe richtig und vergleichst die produkte fair oder Du lässt es. Dann ist jedem klar, dass das nur eine kleine Fanboyseite ist. Es muss Dir doch zu denken geben, dass Du in der Diskussion nicht ernst genommen wirst.
    BTW: Dein Rumhacken auf der SMBReplay-Attacke geht auch ins Leere. Warum wohl gibt es SMB Signing? Damit ist die Replay-Attack nämlich nicht möglich. Auch dieses Beispiel einer konzepionellen Schwachstelle von Windows ist nicht wirklich tragfähig.

  4. Dein Wissen über task_for_pid() ist mangelhaft. Nachhilfe gibt es hier:
    http://www.macmark.de/osx_dynamic-overriding.php

    Daniel Melanchthon, von Microsoft angestellt als sogenannter “Evangelist”, hat in dem “Widerlegungs-Kommentar” seines “Windows 7 Blog von Microsoft Deutschland” seine Eignung als Microsoft-“Evangelist” unter Beweis gestellt, aber nicht mit technischem Know-how geglänzt. Er hat, ganz offen gesprochen, nicht den leisesten Schimmer von OS X und weiß auch vieles über Windows nicht. Ich habe die Details dazu dort in ein paar Kommentaren angemerkt.

    Zum Rest Deines Postings kann ich mir erneute Kommentare schenken.

  5. Ja, ja, andere belehren aber wenn es hart auf hart kommt, kneifen. Wie wäre es mal, wenn Du inhaltlich auf die Argumente eingehen würdest? Stattdessen kommen Abwiegelung (ist ja nicht so schlimm), Verharmlosung (nur ein einfacher Bug) und persönliche Angriffe. Da kann sich ja jeder selbst ein Bild machen. Wird Dir das nicht irgendwann mal peinlich?

  6. Und noch ein Komentar zu “Dein Wissen über task_for_pid() ist mangelhaft. Nachhilfe gibt es hier: http://www.macmark.de/osx_dynamic-overriding.php

    Was Du dabei (mit Absicht?) unterschlägst, ist die Tatsache, dass alle Deine Ausführungen nur für neuere Mac OS X-Versionen gelten. Erst in Mac OS X 10.4.4 wurde die mach_inject-Schwachstelle abgedichtet, indem Securitychecks eingeführt wurden. In früheren Versionen war das nicht drin:
    “Important restriction: In 10.4.4 (intel build), Apple removed the ability to send low-level mach commands from one task to another.”
    http://guiheneuf.org/mach%20inject%20for%20intel.html

    “mach_inject is a very clever piece of hack that allows an application to inject and execute code in another running process. The PowerPC version works with standard user privilege whereas the intel version requires more privileges to work.”
    http://0xced.blogspot.com/2006/06/machinject-procmod-group-and-security.html
    Aber bestimmt ist das Deiner Meinung nach auch kein grundlegender Designfehler, den Mac OS X da gehabt hat, oder?

    Vielleicht wäre es für Dich an der Zeit, Deine Aussagen mal selbst zu hinterfragen. Das arrogante Verhalten anderen gegenüber ist da nicht wirklich angebracht. Wie war das noch gleich mit der Samba-Lücke, die bei Mac OS X ja nicht greifen würde? Uups, bei 10.6 doch: “Anscheinend verhält sich 10.6 etwas anders und hat eventuell hier noch einen Fehler.” Das nenne ich mal eine windelweiche Aussage. Aber Hauptsache schnell die Beruhigungspille einschieben und das Problem, welches nicht mehr abgestritten werden kann, verharmlosen: “Nicht tragisch, da dieser Benutzer nicht viel machen kann, aber dennoch unschön.”

  7. Lieber xyz,

    und wieder verleitet Dich Dein Unwissen zu falschen Schlußfolgerungen. Du hast wieder nicht vollständig und richtig gelesen, was ich geschrieben habe. In diesem Fall auf http://www.macmark.de/osx_dynamic-overriding.php.

    Der erste Teil des Artikels, den ich seit 2005 pflege, beschreibt die Situation vor dem Intel-Switch, also alles vor 10.4.4. Ich gehe weiter unten auch auf 10.3.0 ein. Das ist Dir völlig entgangen.

    Dynamic Overriding stellte in keiner Version von OS X ein Architektur- oder Sicherheits-Problem dar, denn task_for_pid() hat immer die UNIX-Usergrenzen beachtet: Man konnte task_for_pid() immer nur auf eigene Prozesse verwenden, es sei denn man ist root. Das ist Dir vollkommen unbekannt.

    Die erste Intel-Version von OS X schränkte das noch weiter ein. Die PowerPC-Version erst mit 10.5.0, als sie wieder codegleich wurde mit der Intel-Version. Auch das hast Du nicht korrekt hingekriegt. Jede weitere Version von OS X nahm weitere Einschränkungen und Code-Aufräumarbeiten vor.

    All das ist pro Version detailliert beschrieben worden von mir. Ist Dir entgangen.

    Signierter Code aus selektiven Quellen ist nur eine zusätzliche Bedingung, wenn Du meinen Artikel mal richtig lesen würdest. Details siehe dort. Hast Du weder gewußt noch verstanden.

    Wenn Du mal gründlich lesen würdest, dann hättest Du Dir ein paar fehlerhafte Postings sparen können. Versteckst Du Dich deshalb anonym hinter “xyz”?

    Grüße von
    MacMark

  8. XYZ hat, wie es MacMark schon geschrieben hat, seine Artikel nur überflogen und übereilig Argumentiert. Bitte liebe User, nehmt euch das zu Herzen was MacMark sagt und lernt richtig und vollständig zu lesen denn wer das kann ist ja bekanntlich im Vorteil.

    MfG

  9. Irgendwie tendiere ich immer dazu recht schnell die Emotionen, die in das Schreiben eines Textes einflossen auf mich zu projizieren und bei den Kommentaren von xyz hab ich eine extreme Wut gepaart mit blinder Arroganz und Hass wahrgenommen.
    Ich halte es immer für richtig und sehr wichtig wenn man nicht gleich alles glaubt was irgendwo im Internet steht und zumindest weitere Recherchen zu einem Thema tätigt. Aber es ist doch sehr grenzwertig, wenn man mit eigenem Unwissen, vehement und in einem völlig unangebrachten Tonfall, versucht jemanden zu diskreditieren.

    Auch wenn nicht unbedingt alles bis ins kleinste Detail stimmen mag, was MacMark schreibt, so ist er einer der wenigen von denen ich bisher auch nur etwas mit Hand und Fuß gelesen habe was OS X angeht. Allerdings würde ich mir auch etwas mehr technisch in die Tiefe gehende Artikel wünschen, aber ich verstehe auch, dass das nicht für jeden Leser seiner Seite angebracht ist.