Wow, selbst das BSI stellt fest (ich zitiere): "Die Installation eines separaten Virenschutzprogramms ist, basierend auf dem aktuellen Stand der Be­drohungslage durch Schadsoftware für Macs, unter OS X Mountain Lion nicht notwendig."

PS: Hab es mir jetzt mal durchgelesen, ist ganz gut gemacht als allgemeine Übersicht für den durchschnittlichen Anwender.

Trotzdem finde ich, dass man z.B. darauf hinweisen sollte, dass die Verwendung eines separaten Anmelde-Schlüsselbund-Kennwortes (also unabhängig vom Kennwort des Benutzers) überlegenswert ist.

Und ein mehrfaches Löschen von Daten (statt nur mit Nullen überschreiben) bringt keine erhöhte Sicherheit, aber das behauptet sogar noch das BSI (und vergisst dabei, darauf hinzuweisen, dass sich SSDs z.B. kaum 100%ig sicher löschen lassen).

Außerdem weist das BSI nicht darauf hin, dass selbst angelegte Ordner und Dateien im Benutzerordner standardmäßig mit Lese-Rechten für "staff" und "everyone" ausgestattet sind!

Aber ist ja noch eine Version 1.00 …

Aha, sind das nicht die die keinen Bundestrojaner programmieren können?

Wieder Experten....

So so .... Klasse

Die Info hätte auch von meinem Tankwart sein können!

Gruss

Godfather

Und dafür zahle ich meine Steuern? Möchte gerne mal wissen, was diese Kurzanleitung gekostet hat.

Whow!

Auch wenn sich hier einige nach dem Sinn dieses Dokuments fragen: Ich finde dieses PDF gut und wichtig. Es ist sozusagen eine "offizielle" Dokumentation des Ist-Zustandes hinsichtlich der Sicherheit von OS X ML. Es wird ausdrücklich darauf verwiesen, dass ein Virenscanner nicht notwendig ist, die Firewall zu aktivieren ist und welche Account-Typen man nutzen sollte.

Für alle, die in der Materie drin stecken mögen das triviale Antworten auf triviale Fragen sein. Für all die, auch mal ein offizielles Statement einer mehr oder minder vertrauenswürdigen Quelle haben wollten, ist das PDF dagegen sehr hilfreich. Nicht jeder hat einen Apple-Insider in seiner Familie.

claudiusw: Sei dem BSI dankbar. Es hilft, Deine Hoffnung vom 2012-04-19 21:44:38 zu stützen
Godfather: Bei dem würde ich auch immer Tanken wollen.

Peter

Marcel_75@work

Könntest du einmal erklären, was in diesem Fall "besser" wäre und wofür diese Zugriffsrechte standardisiert auch für "staff" und "everyone" erstellt werden? Wenn es besser wäre nur den eigenen Benutzer zuzulassen, wie würde man das abändern und worauf hätte es einen Einfluss? Mich würde das tatsächlich interessieren!

eMac Extreme:
So wie ich das sehe, gehts um die Ordner in ~/. Die haben von Haus aus verschiedene, sinnvolle Zugriffsrechte. Wenn Du einen Ordner neu anlegst, haben auch staff und everyone Leserechte. (Die kann man via Infofenster (-i ändern.)

Meine Empfehlung an Kunden und Familie aber war und ist stets, in dem Ordner ~/ keine eigenen Dateien und Ordner anzulegen. Alles wichtige kann m.E. nach in die vorgebenen Verzeichnisse einsortiert werden. So umgehst Du auch, zufällig Ordner in einer Freigabe sichtbar zu machen.

Peter

twilight:

Nein, das steht da nicht, jedenfalls nicht so wie Du es verkürzt darstellst. Denn Du unterschlägst eine wichtige Teilinformation (ein Wort mit nicht kleiner Bedeutung). Da steht:

Dieser integrierte Schutz seitens Apple hat einen Namen: XProtect.
Wie wirkungsvoll XProtect mit seinem beschränkten Wissens- und Wirkunsgumfang ist, hat OSX.Flashback nebst dem damit erreichten Botnet bewiesen: es stand dem Ganzen wirkunsglos gegenüber, weil XProtect bei Java-Exploits bzw. über Java erwirkten Downloads prinzipiell nicht greift bzw. OSX.Flashback die Wirkungsweise und das Einflussfeld von XProtect umgangen und XProtect damit komplett ausgehebelt hatte (indem z.B. das Quarantäne-Bit, das beim Herunterladen und Schreiben auf die Festplatte gesetzt wird, nicht gesetzt wurde, und somit XProtect nicht anschlagen konnte, weil es auf das Vorhandensein genau dieses Quarantäne-Bits engewiesen ist, um überhaupt in Aktion treten zu können). Nicht etwa, weil Xprotects Definitionslisten nicht auf einem neuen Stand gewesen wären (was sie zudem auch nicht waren), sondern weil Apples XProtect mit einem einfachen Trick umgangen wurde.

Eine vollwerrige AV-Software mit aktueller AV-Signaturliste hingegen konnte OSX.Flashback wenigstens theoretisch rechtzeitig erkennen -- vielleicht nicht unbedingt gleich am ersten Tag, dafür aber Tage später nach aktualisierter Signaturliste (und immer noch früh genug, um mitzuhelfen, Schlimmeres zu verhindern). XProtect noch nicht mal theoretisch -- weil des dafür notwendigen Quarantäne-Bits gleich am Eingang beraubt. Weder am ersten Tag noch Tage später.
Soviel also zur Zuverlässigkeit und Wahrnehmungsgrenze von Apples eingebauter AV-Lösung. Mehr als ein rudimentärer Schutz ist es nicht. Ein rudimentärer Schutz, der nur allzuleicht ausgehebelt werden kann -- indem z.B. kein Quarantäne-Bit geschrieben wird bzw. dieses gelöscht wird, bevor XProtect dieses Quarantäne-Bit unbedingt brauchend, überhaupt in Aktion treten kann.

Zudem ist Apple beim Schreiben seiner Signaturlisten auch nicht immer vorne dabei und unter den Ersten. Manchmal begrüßenswerterweise ja, manchmal hinken sie Tage oder gar Wochen hinter den Signaturlisten der übrigen AV-Industrie hinterher, was aktuelle Mac-Malware angeht -- welche AV-Software welche akute Malware erkennt und welche noch nicht, kann man ganz gut untereinander vergleichen auf Virustotal.com, das vor kurzem von Google gekauft worden ist ().

Sprich: eine separate (will meinen: zusätzlich zur systemseitig vorhandenen XProtect-Lösung) vorhandene AV-Lösung eines Drittanbieters, und damit XProtect ergänzende Lösung (Prinzip: "Vier Augen sehen mehr als zwei" -- was XProtect durch die Lappen geht, geht der zusätzlichen Lösung evtl. nicht durch die Lappen und auch umgekehrt: was der zusätzlichen Lösung durch die Lappen geht, erkennt vielleicht XProtect) hat aufgrund der Schwächen von XProtect nach wievor durchaus seinen Sinn. Und zwar solange, wie Apple XProtect so belässt wie es ist und nicht noch weiter aufbohrt und ausweitet zu einer machtvolleren AV-Lösung, die der eines Drittanbieters in nichts mehr nachsteht und mit ihr in voller Konkurrenz steht (so wie Microsoft es auch mit seinen Security Essentials vorgemacht hat). Und genau Letzeres könnte durchaus passieren bzw. würde ich nicht ausschließen.

Wer hätte noch vor 3-4 Jahren gedacht, dass Apple eines Tages höchstselbst unter die AV-Anbieter gehen und überhaupt sowas wie XProtect (oder auch Gatekeeper) als integralen Bestandteil seines Betriebssystems anbieten würde (ohne groß öffentliches Trara und quasi heimlich durch die Hintertüre -- mit einem Mal war's da)?

Wow, eine sehr gute aufgeräume und ordentliche Erklärung. Enthält viele vernünftge Punkte.

Marcel: Über die Verwendung eines separaten Kennworts für den Anmelde-Schlüsselbund, eine andere Einstellung betr. Autolock desselben oder Verwendung von 2-3 Schlüsselbunden kann man durchaus in einigen Situationen diskutieren, wenn man aber die anderen Tips des PDFs berücksichtigt (in dieser Hinsicht v.a. Filevault und gute Kennwörter verwenden), dann ist für die allermeisten User der Schlüsselbund in Standardsetting vollkommen ok. Aber klar, in Grenzfällen gibt es Ausnahmen.

Godfather: Nein, das sind sie nicht. Und klar, dein Tankwart kennt XProtect ... ja klar. Ich wette mit dir, dass 9 von 10 Mitarbeiter bei Apple Händlern und Supportern nicht wissen, was XProtect ist.

Claudiusw: Ja, und bei dieser Anleitung ist unser Steuergeld gut angelegt.

twilight: Ja, oder man ändert eben die Zugriffsrechte auf den Ordner mit den eigenen Dokuementen drin. Ich würde Dir gerne 100% recht geben, aber ich finde, es gibt zuviel Programme, die "Zeugs" in ~/Dokumente/ ablegen, das wird recht schnell zugemüllt und unübersichtlich, daher tendiere ich zu einem weiteren Ordner mit den eigenen Dokumenten, eben mit kurz geänderten Zugriffsrechten. Aber würde es nicht zugemüllt, würde ich ~/Dokumente bevorzugen.

Das hatte ich mal hier diskutiert:

Zusammenfassung:

Mit einem


kann man den gesamten Benutzerordner so "zurecht biegen", dass nur noch der jeweilige Benutzer schalten und walten darf, wie er will. Das klammert dann aber die Nutzung des "Öffentlich"-Ordners aus (Briefkasten) und natürlich auch den "Sites"-Ordner - weil eben nur noch der User Lesen/Schreiben/Ausführen darf.

Etwas sanfter macht man es mit einem


in /etc/launchd-user.conf

Also so, wie Apple es hier beschreibt:

Beide Lösungen können in Zusammenhang mit speziellen Tools (z.B. VPN-Clients von Juniper Networks, die zwingend auf Java-Applets mit bestimmten Rechten angewiesen sind) zu Problemen führen. Auch manche Adobe-Programme (beispielsweise Photoshop Elements oder der Adobe Updater) mögen solche "Spezialeinstellungen" überhaupt nicht. Wenn man das weiß, kann man es leicht fixen, aber bis man mal darauf gekommen ist (also dass es genau daran liegt, wenn es "hakt"), kann es schon etwas dauern … Deshalb die Vorwarnung.

Habe gestern erst gemerkt, dass ich mit Admin Account "a" auf die .ssh/config Datei von Admin Account "B" lesend zugreifen konnte. Hatte mich erschrocken. Gehört wirklich schleunigst geändert.

Mit einem Admin-Account bist Du per


in einer root-Shell und darfst dann sowieso alles (und überall) auf Deinem Rechner …