Hallo habe heute mein neues MacBook pro bekommen und weiß jetzt nicht brauche ich ein Viren Programm oder kann ich ohne surfen? Danke euch

Hi Alice,

Du kannst getrost surfen ohne Virenscanner.
Aber immer beachten: Nicht auf jeden Scheiss klicken und runterladen!


Gruß

Klaus

Da kann ich zustimmen.

Wenn du dich aber dann sicherer fühlst und vielleicht auch die Windows-Viren, etwa auf USB-Sticks, erkennen willst, gibt es da z.B. Sophos Anti-Virus:

Das hört sich doch gut an vielen dank für eure schnelle Hilfe.

Ist es den so wie die bei Media Markt sagen das das Mac System ein vierenprogramm im system hat ?

Im Fünferpack sind Vierenprogramme von Drittanbietern meist doppelt so günstig zu haben wie alleine.

Der Mac hat keinen Virenscanner drin, jedoch eine Funktion, die bestimmte Schadprogramme erkennt und entfernen kann. Bis jetzt reicht das üblicherweise, da es nur sehr wenig Schadprogramme für den Mac gibt.

Prodest!
Mann sollte nur Fiehrenbrograme von Viertanpiedern nehmen. Tan ist sicher.

Ganz klar und kurz meine Meinung, auch wenn mich gleich einige zurechtweisen werde:

Braucht man nicht. Ganz einfach.

Es gibt für OS X momentan keine Viren oder Würmer im Umlauf. Die Scareware Mac Defender war etwas anderes. Mit dem bald kommenden Sandboxing werden solche Lösungen in Zukunft noch sinnloser als sie jetzt schon sind.

Einzig und allein um Windows User zu schützen mit denen du möglicherweise Dateien austauscht kann ein solches Programm sinnvoll sein, vorausgesetzt dir liegt etwas daran.

Du hast bereits ein solches. Seit MacOSX Snow Leopard. Und MacOSX Lion hat's ebenfalls. Nennt sich XProtect. Allerdings eines in seinem Umfang eher sehr frugal und seinem Erkennungsumfang und seinen Wirkungsmöglichkeiten im Vergleich mit voll ausgewachsener AV-Software deutlich eingeschränkten und rudimentär daherkommendes.
Seit einem der letzten MacOSX Sicherheits-Updates (anlässlich des seit Mai/Juni 2011 kursierenden MacDefender-Trojaners) hat Apple XProtect ein wenig mehr ausgebaut und MacOSX befähigt, XProtect selbständig und zeitgesteuert regelmäßig mit einem Signatur-Update zu versorgen. Bis zu dem Zeitpunkt ist das lediglich nur alle paar Monate im Rahmen von Apples Updates geschehen, inzwischen hält sich XProtect selber auf dem Laufenden durch eine eigene Update-Funktion.

XProtect "kennt" weniger Schadprogramme (derzeit im Umlauf befindliche und mögliche Schadprogramme nur die MacOSX-Plattform betreffend) als ein AV-Programm eines Drittherstellers (wo i.d.R. Schadprogramme für alle Plattformen, also Mac, Windows, Linux und andere Unices erkannt werden, der Erkennungsradius also weitaus größer ist). Außerdem ist XProtect im Grunde nur ein rudimentäres Warnsystem à la "Da ist irgendwas, das ich erkannt und klassifiziert habe, weitere Schritte musst Du selber gehen, da kann ich Dir nicht helfen." Klassische AV-Programme bieten an so einer Stelle i.d.R. noch weitere Möglichkeiten und Handlungs-Optionen (alles individuell konfigurierbar) an, anstatt sich alleine nur auf solch einen Hinweis zu beschränken. Zu Details von XProtect siehe dazu auch unten genannte Apple-Support-Dokumente.
XProtect ist Teil von Apples Datei-Quarantäne-Konzept. XProtect arbeitet nur im Rahmen der grafischen Oberfläche und im Rahmen dessen wie und ob Programme in dieses Quarantäne-Konzept eingebunden sind. Außerhalb des Desktops (i.d.R. sind Finder, Web-Browser und FTP-Programme in dieses Konzept eingebunden), z.B. auf der Unix-Shell, greift dieses Quarantäne-Konzept nicht, eine per /usr/bin/curl runtergeladene Datei wird von diesem Quarantäne-Konzept z.B. nicht erfasst, bekommt kein com.apple.quarantine Flag verpasst, kann somit also auch nicht gegen die Signatur-Liste von MacOSX' Quarantäne-Funktion geprüft werden.

XProtect arbeitet bei der Erkennung von Schadprogrammen sehr ähnlich wie auch AV-Programme von Drittherstellern: lokal ist eine Datei vorhanden, in welcher quasi Fingerabdrücke, sog. Signaturen bzw. Signatur-Hashes, bekannter Schadprogramme abgespeichert sind. Gegen diese Fingerabdrücke wird geprüft, mit diesen Fingerabdrücken wird verglichen. Bei jedem Download. Bei XProtect nur dann. Bei anderen AV-Programmen auf Wunsch auch auf Zuruf (à la "Scanne mir diese Datei XY/dieses Verzeichnis XY. Jetzt."), regelmäßig zeitgesteuert oder und/oder auf Wunsch auch individuell ausgewählte Dateien/Verzeichnisse oder der komplette Datenträger (z.B. beim Einstöpseln eines USB-Sticks oder einer USB-Festplatte).

XProtect aktualisiert seine Definitionsliste alle 24 Stunden über einen launchd-Service (wer technisch bewandert ist, kann diesen Rhythmus ggf. für sich ändern, indem man die betreffende launchd-Datei von Hand entsprechend ändert, allerdings kann es passieren, dass sie beim nächsten OS-Update von Apple wieder überschrieben wird), indem es seine lokal vorliegende Definitionsliste mit der, die auf einem Apple-Server liegt, vergleicht und ggf. ein lokales Update dieser Liste macht.
AV-Programme von Drittherstellern machen das sehr ähnlich bzw. auf sehr ähnliche Weise, dort kann der Benutzer in der Regel aber gewollt und bequem einstellen, wann und wie oft solche Updates vonstatten gehen sollen.

XProtect besteht aus folgenden Dateien:
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist (Meta-Info über Versionsstand und letzte Aktualisierung von XProtect.plist, XML-Datei, kann mit einem Plist-Editor oder jedem beliebigen Text-Editor eingesehen werden)
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist (Schadprogramm-Definitionsliste, XML-Datei, kann mit einem Plist-Editor oder jedem beliebigen Text-Editor eingesehen werden)
/System/Library/LaunchDaemons/com.apple.xprotectupdater.plist (launchd-Dienst, XProtect-Updater)
/usr/libexec/XProtectUpdater (XProtectUpdater, eigentliches Programm)

http://configuration.apple.com/configurations/macosx/xprotect/1/clientConfiguration.plist (AV-Signatur-Datei mit der sich der XProtect-Updater abgleicht für Mac OS X Snow Leopard (10.6))

http://configuration.apple.com/configurations/macosx/xprotect/2/clientConfiguration.plist (AV-Signatur-Datei mit der sich der XProtect-Updater abgleicht für Mac OS X Lion (10.7))

Wer wissen will, welche Mac-only-Malware XProtect im Moment kennt, muss sich nur den Inhalt dieser XProtect.plist-Datei anschauen.

Zum Vergleich:

ClamAV Virus Database Search (Stichwort: "osx", Stand: 09.08.2011) :

Wikipedia: XProtect

Apple Support: Informationen zur Dateiquarantäne in Mac OS X 10.5 und 10.6 (und 10.7)

Apple Support: Malware "Mac Defender" vermeiden oder entfernen

Apple Support: Mac OS X Snow Leopard (und Lion) und Malware-Erkennung

The Register: Apple sneaks malware protection into Snow Leopard


Apples MacOSX Server verwendet im Gegensatz zu MacOSX Desktop seit Jahren einen voll ausgewachsenen, klassischen AV-Scanner und hat den ab Werk installiert, konfiguriert und ins System eingebunden: Clamav . Source-Code dazu auf Apples Server:
Dokumentation zu Clamav auf Apples Server: (PDF).

Clamav dürfte das am weitest verbreiteste AV-Programm im gesamten Unix-Bereich sein. Clamav ist Open-Source und kostenfrei, ist eigentlich nur die AV-Engine nebst Signatur-Updater (freshclam) ohne GUI (grafische Bedienoberfläche). Es gibt betriebssystemübergreifend (vor allem im Linux-/Unix-Bereich) zahlreiche GUI-Programme, die Clamav per Maus bedienbar machen. Clamav ist neben der Tatsache, dass es Open-Source-Software ist, u.a. auch deshalb so beliebt bei Linux-/Unix-Admins und -Nutzern, weil es einen im Vergleich zu anderer AV-Software geringen Ressourcen-Bedarf hat also sehr genügsam ist und das System nicht oder kaum ausbremst, nur dann in Erscheinung tritt, wenn's gebraucht oder angefordert wird und in ziemliche vielen Richtungen sehr gut gemäß den Wünschen und Bedürfnissen des jeweiligen Anwenders/Admins anpassbar/konfigurierbar ist und sich gut und nahtlos ins restliche Unix-System einfügt bzw. einfügen lässt.

Clamav ist ein Produkt der Firma Sourcefire , aus deren Feder u.a. auch das im Unix-Bereich seit Jahren geschätzte Sicherheits-Werkzeug Snort (ebenfalls Open-Source) stammt. Die Firma Sourcefire wurde aufbauend auf dem Erfolg von Snort von dessen Autor gegründet (ähnlich wie bei NTFS-3G ist um ein erfolgreiches Open-Source-Produkt dann irgendwann eine Firma entstanden). Das schon länger existierende Open-Source-Projekt Clamav wurde von Sourcefire irgendwann offiziell übernommen bzw. Sourcefire stellt seitdem die wichtigsten Entwickler dafür ab und treibt die Weiterentwicklung voran (neben der ebenfalls beteiligten Open-Source-Community) . Ähnlich wie es Apple mit CUPS gemacht hat.

Für MacOSX Desktop gibt's Clamav auch mit GUI, z.B. als ClamXav .
Oder auch in Gestalt des kommerziellen Programms ProtectMac AntiVirus , welches Clamav ebenfalls unter der Haube als AV-Engine nutzt.

Apple schreibt in seinen Security Configuration Guides

Apple Support: Mac OS X Security Configuration Guides (PDFs)

seit Jahren zum Thema Antivirus-Programme u.a. Folgendes (man beachte u.a. auch die von Apple gewählte Reihenfolge in dem Satz "In addition to..."):

sierkb
Lass mich raten: Du schreibst gerade eine Enzyklopädie über OS X, OpenSource und alles was im entferntesten damit zu tun hat. Als »Werbemaßnahme« veröffentlichst du hier jeweils einige Absätze als Antwort auf eine Frage, die auch nur im entferntesten was damit zu tun haben könnte.

Ob wohl das ziemlich nobel ist, hast du die gestellte Frage leider nicht im Ansatz beantwortet, obwohl du durchaus 50 der geschriebenen 1417 Worte hierfür verwenden hättest können

Ich find's super!
Ein kurzer Absatz, alles drin. Passt.
Danke!

Die Frage von Alice1991 hieß:
Und später nochmal:
Meine Antwort dazu gleich im ersten Satz meiner Einlassung:

Damit ist die Frage bzw. beide Fragen von Alice1991 im Grunde beantwortet.

Alles von mir danach Kommende versucht zu erklären, was XProtect macht und in welchem Umfang es arbeitet, hilft oder auch nicht hilft. Und was im Vergleich dazu z.B. Clamav ist, wie Apples Einstellung zu Clamav ist und wie Apples Sichtweise zu AV-Software insgesamt ist. Und dass es durchaus sinnvoll ist bzw. sein kann, sich ggf. noch zusätzlich zu XProtect eine andere AV-Software zu installieren, welche in ihrem Erkennungs- und Handlungsspielraum über die betreffenden Eigenschaften von XProtect hinausgeht und mehr Optionen bei der Erkennung und anschließenden Reaktion anbietet. Und nichts anderes schreibt auch Apple seit Jahren in seinen bereits genannten Security Configuration Guides, schreibt es schon dort rein, als es noch kein XProtect gab.

XProtect ist ein rudimentärer Grundschutz. Mehr nicht. Noch reicht er aus. Immerhin beweist schon allein seine Existenz und auch die Existenz seiner vom System nun automatisch aktualisierten Signatur-Datei mit aktuellen Trojaner-Signaturen (heute Nacht gerade wieder aktualisiert worden auf Version 23, Stand: Tue, 09 Aug 2011 02:38:55 GMT, Neuzugang ist die Signatur für den aktuell kursierenden OSX.QHost.WB.A), dass die Zeiten wohl endgültig vorbei sind, dass man ungeschoren behaupten konnte, der Mac brauche sowas nicht, und es gäbe da nix, wogegen man sich (und andere) schützen müsse. Apple höchstselbst hat mit XProtect und dem jüngst hinzugefügten XProtectUpdater dafür gesorgt, dass solche und ähnliche Aussagen spätestens seit dem Erscheinen von XProtect/XProtectUpdater so nicht mehr aufrechtzuerhalten sind. Spätestens seitdem. Und wer schon vorher Apples Mac OS X Security Configuration Guides gelesen hatte, der wusste es spätestens seitdem Apple sich dort in diesen Dokumenten zur Sinnhaftigkeit von AV-Software geäußert hat.

Es existieren da offenbar 2 Sichtweisen, Darstellungen und Handlungsanweisungen seitens Apple zu diesem Thema: eine Sichtweise für die breite (anzunehmenderweise wohl eher unwissende) Öffentlichkeit gedachte und vom Marketing beherrschte. Und eine wohl eher nicht so für die breite Öffentlichkeit und fürs Marketing gedachte Sichtweise und Darstellung, auf welche man nur stößt, wenn man als Interessierter und/oder Admin selber in Apples Support- und Developer-Dokumenten wühlt. Dann stößt man auf solche Dokumente wie die bereits genannten Mac OS X Security Configuration Guides. Oder auch, wenn man die Empfehlungen der NSA für verschiedene Betriebssysteme ansteuert. Dann stößt man ebenfalls auf diese Apple-Dokumente, welche dort auf den NSA-Seiten direkt verlinkt sind.

Der Laie bekommt solche Dokumente leider nicht zu Gesicht, vertraut darauf, dass wohl schon alles seine Richtigkeit habe, wie Apple es ihm ausgehändigt hat. Er weiß i.d.R. nichts davon, dass Apple höchstselbst in seinen eigenen Dokumenten in puncto Sicherheit entscheidene grundlegende Empfehlungen gibt und Maßnahmen empfiehlt, die dem normalen, durchschnittlichen Mac-Nutzer bei Kauf der Geräte und bei Nutzung ihres Betriebssystems so nicht bekannt sind und auch nicht bekannt gemacht werden. Er vertraut blind dem, was er ausgehändigt bekommen hat.

Warum macht Apple das? Warum hantiert Apple hier seit Jahren doppelzüngig, was das Thema Sicherheit angeht -- einmal mit marketingbestimmten, wohlklingenden und sich gut verkaufenden Aussagen und Zuständen und einmal mit sicherheitsbestimmten (aber eben weniger wohlklingenden und sich nicht so schön verkaufenden) Aussagen und empfohlenen Maßnahmen?
Warum liefern sie ihre Geräte und Betriebssysteme nicht gleich so aus, wie sie es in diesen von ihnen selber stammenden Dokumenten zum Thema Sicherheit jedem Nutzer (und eben nicht nur den Admins und Wissenden) empfehlen und anraten (ja wie es teilweise an mancher Stelle der gesunde Menschenverstand und jahrelange Betriebssystem-Praxis vor allem im Unix-Bereich empfiehlt)?

Also Gratulation zu diese gelungenen Diskussion! Die unterschiedlichen Beiträge haben
mich eben gut aufgemuntert.

Aber hier bin ich doch etwas ernster geworden:

Danke für diese Hinweise!
Und wer von Euch macht das denn so wie oben und unten empfohlen?

pumacl

Hehe, das ist tatsächlich eine interessante Frage.
Ich denke kaum einer wird, insbesondere für den Privatgebrauch seinen Rechner so oder ähnlich abschotten. Da schiesst man schon ein wenig mit Kanonen auf Spatzen.

Das sind Dinge die werden eventuell an einigen wenigen Arbeitsplätzen innerhalb von Firmen gemacht wo es wirklich auf die höchstmögliche Sicherheit ankommt. Selbst im professionellen Bereich werden die wenigsten Macs so konfiguriert.

Es gibt natürlich auch Gründe weshalb Apple die Macs anders ausliefert als es für höchstmögliche Sicherheit notwendig wäre. Vieles davon hat mit Komfort und mit Diensten zu tun. In einigen Bereichen muss man also Sicherheit und Komfort abwägen. Auch wenn Sicherheitsfanatiker das nicht gerne hören, ich bleibe dabei. Als Privatanwender sollte man sich um diese Dokumente nicht den Kopf zerbrechen.

Fakt ist: Als Mac User bist du momentan weder durch Viren, Trojaner noch Würmer gefährdet. Daher ist es nicht notwendig irgendwelche zusätzliche Antivirensoftware zu verwenden. Es steht dir natürlich frei dies zu tun, wenn du zusätzlich ein wenig mehr Schutz bezüglich Phishing oder Scareware geniessen möchtest oder generell Windows Benutzer beschützen möchtest, mit denen du Dateien austauscht.

Notwendig ist dies aber wie gesagt momentan nicht und das sollten wir nicht vergessen, bevor wir in eine akademische Diskussion geraten.

StdOut:

Mac OS X Security Configuration Guides
Außerdem im selben Dokument:

Kapitel 6, Securing Accounts (S.118ff.),
insbesondere Unterkapitel “Securing Nonadministrator Accounts” (S.121)
und “Securing Administrator Accounts” (S.124)
und
Frage: Und was empfiehlt die NSA in ihren Hardening Tips for MAC OS X 10.6 Snow Leopard an ALLERERSTER Stelle?
Antwort:
Frage: Und was schreibt inzwischen sogar Microsoft in seinem TechNet-Blog zu diesem Thema und sagt damit nur etwas, was man eh schon seit Jahren wusste und Studien unabhängiger Dritter tatsächlich nachweisbar belegt haben?
Antwort:

Keine Admin-Rechte = sicherere PCs :

Frage: warum liefert Apple seine Systeme nicht gleich so aus, wie sie es in ihren eigenen Dokumenten empfehlen, wie es die NSA ebenfalls empfiehlt, wie es Microsoft inzwischen auch erkannt hat und für seine Systeme empfiehlt, ja wie es eigentlich im gesamten Unix-Bereich seit Jahrzehnten selbstverständliche Praxis ist, die dort in Fleisch und Blut übergegangen ist, ein no-brainer ist? Warum sind einige grundlegende in diesem Dokument gegebenen Ratschläge von Apple nur an erfahrene Nutzer gerichtet und in einigen Teilen nicht gleich von vornherein so für ALLE Nutzer gleich ab Werk umgesetzt? Warum muss man solche primitiven und grundlegenden Dinge wie eine strikte Nutzertrennung in Admin und Non-Admin erst hier nachlesen und selber ggf. per Hand nachregeln anstatt dass MacOSX von vornherein schon so ausgeliefert wird oder zumindest bei der Erstinstallation den Benutzer quasi mit dem Kopf drauf stößt, sich hier doch im Sinne höherer Sicherheit doch geschwind einen Non-Admin-Benutzeraccount anzulegen und diesen dann fortan für alle tagtäglichen Arbeiten zu benutzen?

Frage: macht Apple da evtl. denselben Fehler, wie ihn Microsoft jahrelang gemacht hat und stellt in der Abwägung von Bequemlichkeit und Sicherheit die Bequemlichkeit an erste Stelle? Es anders, es besser zu machen (und damit dann wiederum mit den eigenen schriftlichen Empfehlungen übereinstimmend), wäre so einfach und so schnell erledigt. Ein no-brainer sozusagen!
Wie z.B. einer per bei Erstinbetriebnahme gezeigten Meldung und mit Nachdruck formulierten Empfehlung an den Nutzer, sich für den Alltag doch bitte ein Non-Admin-Konto zuzulegen und das Admin-Konto nur für Admin-Zwecke (und nur diese) zu benutzen. Apple könnte bei der Erstinbetriebnahme dem Nutzer diesen Schritt freundlich aber bestimmt auf dem Silbertablett servieren, den Nutzer bei der Hand nehmen und ihn sanft und erläuternd begleiten bei dieser einfachen aber durchaus wirkungsvollen Maßnahme. Das ist zu schaffen.

Vor dem Sein kommt das Bewusstsein. Wo weckt, Apple bei seinen Nutzern ein Bewusstsein für solche Dinge, wo gewöhnt Apple seine Nutzer an solche so grundlegende, sinnvolle und richtige Maßnahmen?

Man könnte meinen, man hätte aus den jahrelangen Fehlern und Missständen bzgl. Microsoft Windows nichts gelernt. Da werden dieselben Fehler wider besseren Wissens erneut gemacht und das Schicksal sehenden Auges erneut rausgefordert. Bzw. alles Vertrauen des benutzers ruht auf Apple, dass die das schon irgendwie richtig gemacht haben. Apple spricht hier aber seit Jahren offenbar mit 2 Zungen! Und hat anscheinend eher nach außen hin die Aufrechterhaltung lange Jahre eingeübter und aufrechterhaltener Mythen und Verklärungen im Auge als die tatsächliche Sicherheit seiner Systeme. Hauptsache, es verkauft sich gut und löst in den Ohren der Nutzer wohlklingende Assoziationen aus. Da stören Sicherheitsmaßnahmen, die dem Nutzer des Denken und Mitdenken abverlangen und von ihm gewisse Verhaltensweisen erwarten, nur. Viel zu kompliziert und unbequem. Und kompliziert und unbequem will man ja gerade nicht sein, bzw. ein solches Bild will man gerade nicht vermitteln.

Bequemlichkeit und Sicherheit sind schon immer zwei überwiegend gegenläufig gerichtete Größen. Der Sicherheitsgurt um Auto ist ebenfalls nicht bequem und stört einige Menschen. Und in den 70er Jahren, als er verpflichtend eingeführt wurde, gab's ebenfalls Menschen, die ihn eine ganze Weile nicht anlegen wollten, weil sie sich in ihrer (Bewegungs-)Freiheit eingeschränkt fühlten bzw. er ihnen lästig war. Heute eine Selbstverständlichkeit, ein no-brainer. Man legt ihn inzwischen an ohne groß drüber nachzudenken. Und wievielen Menschen hat seitdem diese so einfache und simple/primitive Maßnahme das Leben gerettet, weil sie angegurtet waren?

Nein, denn:

AV schadet mehr als sie nützt auf OS X:
macmark.de/osx_security.php#schutz

Das denken auch die "Promi-Hacker":
macmark.de/blog/osx_blog_2011-07-b.php

Außerdem gibt es keine Viren für OS X aus verschiedenen Gründen:
macmark.de/osx_viren.php

sierkb

Ich stimme dir da ja zu, insbesondere was die alltägliche Nutzung des Admin-Accounts angeht. Dennoch richten sich viele der in diesem Dokument beschriebenen Schritte an fortgeschrittene Anwender. Für den Privatgebraucht ist dies meiner Meinung nach bei aktueller Sicherheitslage unter OS X auch überhaupt nicht notwendig. Und ich würde ehrlich gesagt auch keinem normalen Nutzer zumuten wollen sich das Lesen solcher Dokumente antun zu müssen. Das bedeutet natürlich nicht gleich, dass ich Apples Strategie hier entschuldige.

Warum Apple da so verfährt und nicht anders ist eine gute Frage. Letztendlich kann man aber einen Admin Account unter Windows nicht mit einem Admin Account unter OS X vergleichen. Denn ein OS X Benutzer, welcher über die GUI als Admin Account eingestuft wurde ist != root. Und root wäre meiner Meinung nach das Äquivalent zum Windows Admin.

Dennoch hast du natürlich Recht. Apple verfährt da nicht ganz Konsequent, denn ein Admin Account unter OS X ist beispielsweise in der Lage problemlos Software zu installieren und agiert damit und auch durch andere Aktionen ausserhalb seines Home Folders und genau dies kann Schadsoftware theoretisch ausnutzen.

Dies ist auch ein grosser Unterschied zu Linux. Dort ist es seit jeher üblich als normaler Benutzer zu arbeiten und sich im Grunde auch niemals als root in einer GUI anzumelden. Wozu auch? Und trotzdem verzichtet man dort nicht auf den Komfort auch administrative Aufgaben erledigen zu können, ohne direkt den User wechseln zu müssen. Zum einen natürlich über das Terminal, doch auch über die GUI lassen sich diese Aufgaben erledigen, setzen allerdings konsequent die Eingabe des root Passworts voraus. Und zwar für jedwede systemrelevante Aktion und Zugriff ausserhalb des Home Folders. Genau da hätte Apple ein wenig konsequenter sein müssen. Der Grundstein ist ja sogar vorhanden, denn die Kennwortabfrage sehen wir häufig genug.

Im übrigen fand ich es schon immer verwirrend, weshalb Apple überhaupt auf die Bezeichnung Admin zurückgreift. Bzw. weshalb diese Bezeichnung bei Apple != root ist. Das wäre ja noch halbwegs konsequent gewesen. Naja...

Wir werden sehen, ich denke die Lage wird in Zukunft ein wenig besser, sobald das Sandboxing in OS X eingeführt wird. Damit ist der Schaden, den ein Schadprogramm anrichten kann natürlich deutlich limitiert. Zumindest gilt das für Code welcher beispielsweise irgendwie durch den Browser eingeschleust wird. Dieser könnte nur auf die Sandbox des Browsers zugreifen und würde nicht irgendwo im System wüten. Das setzt natürlich voraus, dass der Browser Sandboxing unterstützt und schützt auch nicht davor, dass User unwissentlich ein Schadprogramm installieren, welches eben nicht in einer Sandbox läuft. Von daher wäre es schon wünschenswert wenn die Grenze zwischen wirklichem Admin aka root und Benutzeraccount unter OS X in Zukunft deutlicher gezogen würde.

StdOut:

Du willst mir doch jetzt nicht weismachen, dass die Einrichtung und Nutzung eines Non-Admin-Accounts für einen durchschnittlichen Normalanwender nicht zumutbar ist bzw. diesen überfordert? Und erst recht nicht willst Du mir weismachen, dass das eine Überforderung bedeuten würde, wenn Apple sich dieses Themas annehmen würde, das schon alles vorbereiten, den Nutzer fürsorglich bei der Hand nehmen und ihn sanft dorthin geleiten würde. Warum schafft Microsoft das inzwischen?


Du meinst, Apple und der Nutzer sollen/müssen erst tätig werden, wenn das Kind quasi schon in den Brunnen gefallen ist? Wenn -- um's mal in altem Jargon auszudrücken -- der Russe mit seinen Panzern bereits vor den Stadttoren von Hamburg, Bremen und Köln steht. Dann also erst tätig werden und einen Finger rühren? Ist so ein Vorgehen klug und weise? Wie würde man in anderen Situationen des lebens sowas bezeichnen? Evtl. "Fahrlässig"? Evtl. "den Nutzer ins offene Messer laufen lassen und erst dann handeln, wenn es spitz auf Knopf steht und sich so mancher schon eine blutige Nase geholt hat?" Was nochmal konkret hat Apple zum konkreten Handeln in der Sache MacDefender gezwungen? Das waren nicht zufällig überlaufende Hotlines bei AppleCare USA und AppleCare USA war tagelang, wochenlang mit überwiegend nichts anderem beschäftigt als sich die Ängste/Sorgen/Nöte von betroffenen nichst ahnenden Mac-Nutzern anzuhören, die das Ganze völlig unvorbereitet und aus heiterem Himmel getroffen hatte?

Du hast mich anscheinend nicht richtig verstanden: natürlich sollen sie sich das nicht antun müssen, gewisse Informationen, die in diesen Dokumanten drinstehen, sollen da gar nicht erst drinstehen müssen, weil sie sowieso schon für JEDEN schopn längst ab Werk so eingestellt sind! Zum Beispiel eben die strikte Trennung zwischen Admin und Non-Admin! Eine Lapalie, ein absoluter no-brainer, eine totale Selbstverständlichkeit eigentlich, was den zu berwältigenden Schwierigkeitsgrad angeht! Aber ein vergleichsweise äußerst wirkungsvoller no-brainer, was seinen Wirkungsgrad gemessen am zu tätigenden Aufwand angeht!
Wieso wächst nicht jeder MacOSX-Nutzer vom ersten tag damit auf, dass das erste, was er zu tun hat, wenn er sein Gerät bzw. MacOSX das erste Mal in Betrieb nimmt, er einen Non-Admin-Benutzer anlegt und diesen fortan primär nutzt? Warum hat Apple MacOSX in seinen Konfigurations- und Hilfe-Dialogen so gestrickt, dass das System bei Erstinbetriebnahme genau sowas initiiert, den Benutzer bei der Hand nimmt, ihm kurz dazu was sagt wie sinnvoll so ein Schritt ist und ihm dann den Dialog vorhält, wo er einen Benutzernamen und ein Passwort für diesen neuen Non-Admin auswählt. Fertig ist die Sache. Eine Angelegenheit von vielleicht 2 Minuten. Apple ist doch sonst auch Meister darin, komplizierte Sachen auf eine einfache Ebene runterzubrechen! Und dieses willst Du ihnen in dieser leppischen Angelegenheit jetzt absprechen, willst dem Nutzer nicht zutrauen, dass er das nicht kapiert -- zwei Kontos vorzuhalten und mit einem Passwort zu versehen: eines für Admin-Aufgaben und eines für den tägliches Bedarf?

Tust Du aber leider, was diesen speziellen Punkt angeht.

Diese Frage sollte viel öfters gestellt werden. Und zwar laut. Und so manches Mal mit Nachdruck.

Doch kann man. Mittlerweile schon.

Auch ein Admin mit Admin-Rechten unter neueren Windows-Versionen hat immer noch einen, der über ihm steht: den (Super-)Administrator (unter Unix-Systemen: root).
Das, worauf Du Dich stützt, das sind unter Windows inzwischen veraltete Kamellen, auch wenn sie unter XP noch vorhanden und verbreitet sind. Unter neueren Windows-Versionen ist das inzwischen anders.

Siehe zuvor Gesagtes.

Warum wohl hat Apple mit Lion viele essentielle Ordner und Dateien wohl der bisherig üblichen admin-Gruppe entzogen und sie, wie unter fast allen BSD-Systemen und unter Linux der root-Gruppe zugeordnet (unter BSD ist das die Gruppe wheel, unter Linux-Systemen ist das die Gruppe root)?
Ein naheliegender Schluss ist: die admin-Gruppe unter MacOSX hat bisher immer noch zuviel Macht. Und da MacOSX von vornherein und ab Werk so daherkommt, dass eben der Standardnutzer volle admin-Rechte hat, ist das natürlich ein unnötig hohes Risiko, das man da eingeht. Und um diesen Schritt nicht zu gehen, den Nutzer damit zu konfrontieren, sich ein Non-Admin-Konto einzurichten, ist dann die einfachste Maßnahme, verschiedenen wichtigen Ordnern dann halt die admin-Rechte wegzunehmen und sie eine Etage höher zu hängen und sie nur der root-Gruppe zugänglich zu machen. An sich eine sehr sinnvolle Sache. Hätte Apple eigentlich schon immer machen können, machen sollen, ist es doch in BSD-Unices seit Jahren so üblich.

Unter MacOSX ist der Standard-Benutzer nach Erstinstallation Admin (Nutzername beliebig wählbar) und Mitglied der admin-Gruppe. Eine Etage höher ist der Superuser root mit der root-Gruppe wheel (welcher seit Lion wieder höhere Bedeutung zukommt, die ihr zuvor in Leopard und Snow Leopard die admin-Gruppe abspenstig machte). Es bedarf also nur eines einzigen weiteren Schrittes, um in diese privilligierte Riege vorzustoßen. Das geschieht i.d.R. mit su bzw. sudo. Unter MacOSX sind folgende Personen/Gruppen standardmäßig sudo-berechtigt: root und Mitglieder der Gruppe admin, also Nutzer mit Adminrechten.
Wäre unter MacOSX der Standardnutzer ein Nutzer der nicht-privillegierten Gruppe staff, hätte er also keine Admin-Rechte und wäre somit nicht Mitglied der Gruppe admin, so wären derer zwei Hürden zu nehmen statt einer, um volle und umfängliche Systemgewalt zu bekommen: erstmal müsste man Admin-Rechte bekommen. Um von dort aus dann überhaupt ein sudo-Kommando absetzen zu können, also irgendwas mit root-Rechten machen zu können, denn ein sudo-Kommando absetzen, das darf man standardmäßig (so ist es vorkonfiguriert in der Datei /etc/sudoers) entweder nur als root selbst oder als Mitglied der admin-Gruppe. Ein Standardnutzer unter MacOSX hat von Haus aus und ab Werk ständig genau diese sudo-Rechte, die ihn befähigen, root-Privilegien in Anspruch zu nehmen. Warum? Der Feld- Wald- und Wiesen-Nutzer unter MacOSX hat ab Werk, weil er Mitglied der admin-Gruppe ist und auch nie darauf hingewiesen wurde, das zu ändern und sich zwecks höherer Sicherheit und auch aus einem gewissen Selbstschutz Fehlbedienungen betreffend Rechte zu entziehen, der hat also sudo-Rechte, muss nur eine einzige Hürde nehmen, um root zu werden. Schadprogramme, die sich ein solcher Nutzer einfängt, die freuen sich riesig darüber, dass sie ohne groß was dafür tun zu müssen, imemrhin bereits Admin-Rechte haben und im Grunde nur noch eine Treppenstufe vom root-Himmel entfernt sind. Auch wenn sie da mangels Passwort nicht reinkommen -- immerhin haben sie Admin-Rechte und können auf so manchen Sysytem-Ordner schreibend und verändernd zugreifen, weil die so geartet sind, dass nicht nur root dort schreibend und lesend drauf zugreifen darf, sondern auch Mitglieder der admin-Gruppe, also im Grunde jeder ab Werk eingerichteter Standardnutzer. Nicht nur auf den /Applications-Ordner, sondern auch auf den /Library-Ordner bzw. manche seiner Unterordner können z.B. Mitglieder der admin-Gruppe schreibend und verändernd zugreifen, ohne sich per Passwort authentifizieren zu müssen, denn sie gehören ja bereits der admin-Gruppe an, dürfen das also.

Genau das mag Apple dazu bewogen haben, das mit Lion zu ändern. Und diesen Ordnern für die admin-Gruppe die Rechte zu entziehen und diese nur noch beschreib- und veränderbar für root und Mitglieder der root-Gruppe wheel zu machen. Immerhin etwas. Und auch wieder im Einklang mit übrigen BSD-Unix-Systemen.
Vielleicht erleben wir es ja mit MacOSX 12, dass Apple dann noch endlich einen Schritt weitergeht und dem Nutzer gleich zu Anfang abringt, schleunigst einen weiteren Non-Admin-Account anzulegen, das wäre dann nochmal ein auf einfache Weise erzeugter zusätzlicher Sicherheitsring. Wer keine Admin-Rechte hat (evtl. eingefangene Schadprogramme, die diese Rechte erben, inbegriffen), kann weniger kaputtmachen, muss sich erst Admin-Rechte besorgen, um von dort aus dann erst die Möglichkeit zu bekommen, root-Rechte zu erlangen.

Unter neueren Windows-Versionen ist es inzwischen recht ähnlich: der bei Erstinstallation voreingestellte Admin-Nutzer (Nutzername beliebig wählbar) ist nicht Höchster in der Hierarchie, über ihm gibt es noch jemanden Höheren, der nennt sich vorgegebenermaßen Administrator. Der ist standardmäßig verborgen, hat meiner Erinnerung nach auch (noch) kein Passwort und hat keinen Desktop (also ziemlich ähnlich wie unter MacOSX bezüglich root). Der Unterschied zu MacOSX kommt dann: Microsoft führt den Benutzer hin bzw. legt ihm nahe, ein Non-Admin-Konto zu erstellen für die ab dann anfallenden Alltagsgeschäfte. Apple macht genau das unter MacOSX bisher nicht und lässt den Benutzer dann in diesem Zustand als Admin-Nutzer ausgestattet mit Admin-Rechten verweilen, überlässt ihn quasi seinem Schicksal. Ohne weitere Hinweise, ohne weitere Tipps, so zügig wie möglich diesen Zustand zu verlassen und mithilfe des Systems eine weniger priviligierte Umgebung für den alltäglichen Gebrauch zu schaffen.

Frag' Apple. Ich habe hier bei MTN vor ein paar Jahren diese Frage ähnlich gestellt und infragegestellt, warum sie eine admin-Gruppe mit weitreichenden Rechten eingeführt haben, wo es doch unter BSD-Systemen üblicherweise eine root-Gruppe namens wheel dafür gibt. Mit Lion hat Apple das nun wieder etwas zurückgedreht, viele Dateien und Ordner, die bisher der admin-Gruppe zugehörig waren nun der root-Gruppe wheel zugeordnet. Faktisch hat Apple der admin-Gruppe also Dateien und Ordner aus deren bisherigen Wirkunsgkreis entzogen und sie höher gehängt, sodass auch ein Admin-Nutzer und Mitglied der admin-Gruppe da nur noch rankommt, wenn er sich per su oder sudo root-Rechte holt.

Apple löst dieses Thema betreffend jetzt erst mit Lion die vollmundigen Versprechen und Aussagen ein, die sie diesbzgl. mit Einführung des Sandboxings in Leopard gemacht haben. Snow Leopard war diesbzgl. fast eine Nullrunde, da hatte sich an dieser Front im Vergleich zu Leopard so gut wie nichts verändert und gebessert. Auf das Internet zugreifende Applikationen wie Safari, Mail, iChat waren bisher nicht gesandboxed. Eigentlich war bisher keine einzige Applikation bis auf ein paar Progrämmchen des Darwin-Unterbaus gesandboxed. Das ist mit Lion nun anders. Da ist so gut wie alles (zumindest die wichtigsten Programme) in einer Sandbox. Mit teilweise weitreichenden Folgen, die gerade auch für Entwickler zu beachten sind.
Apple verfolgt das Ziel "Every App is an island". Jede Applikation ist eine Insel für sich und gleichzeitig eine Sandbox. Autark und in sich alles Notwendige tragend und verschiedene Komponenten nicht mehr vertreut über das ganze System. Vorbild dafür ist iOS, unter MacOSX ist das nicht auf gleiche Weise machbar, musste etwas abgeändert werden. Auch das ist ein Grund, warum Programme aus dem AppStore sich nicht mehr komplett über die ganze Platte verteilen, sondern als in sich kompakte Einheit im /Applications-Verzeichnis sitzen, die Frameworks, die sie benötigen, in sich tragend. Beispiel iPhoto: Frameworks, die zuvor noch unter /Library/Frameworks abgelegt wurden, sind bei der der iPhoto-Version aus dem AppStore nun in der Application selber im Verzeichnis /Applications/iPhoto.app/Contents/Frameworks zu finden.

Die Datei- und Ordner-Rechte und deren Nutzer-/Gruppenzugehörigkeit betreffend: dem könnte Apple schon seit Jahren entsprechen, mit Leichtigkeit entsprechen, sie haben es bisher aus unerfindlichen Gründen nur nicht getan. Mit Lion sind sie diesem Ansinnen ein gutes Stück näher gekommen. Aber: warum erst jetzt? Warum nicht schon viel früher? Warum erst von solchen Gepflogenheiten aus der Unix-Welt entfernen und herumexperimentieren vor allem in Tiger und Leopard, um in Lion dann wieder und sinnvollerweise zu diesen tradierten Unix-Gepflogenheiten zurückzukehren bzw. sich diesen wieder anzunähern? Wozu also dieses Irrlichtern, Herumexperimentieren, um dann am Ende doch zu dem zu finden und zurückzukehren, was man vorher hatte bzw. was gewachsenes und jahrelang bewährtes Wissen im Unix-Bereich ist?

sierkb

Na, da habe ich bezueglich Windows anscheinend wieder etwas neues gelernt. Ich habe ehrlich gesagt seit XP keine Version mehr angefasst, deshalb waren mir diese Änderungen nicht bewusst.

Du hast mich aber ein wenig falsch verstanden denke ich.

Hiermit habe ich doch gesagt, dass ich bezüglich der Admin Account Thematik der selben Meinung bin.
Allerdings gibt es in diesem Dokument viele (über diese Account Geschichte hinausgehende) Schritte. Das weisst du doch auch. Da geht es teilweise um Netzwerksicherheit, Credentials, Firewalls, Sandboxing, Runtime Protection, etc, pp. Das ist nun wirklich nichts, was ein Anwender lesen oder konfigurieren sollte. Diese Dinge, sowie die Installation eines zusätzlichen Antivirentools sind meiner Meinung nach momentan eben nicht unbedingt notwendig. Das wollte ich damit ausdrücken. Ansonsten hätte ich ja auch nicht soviel zum Thema Admin Account geschrieben.

Ach Mensch jetzt darf ich nicht mehr Editieren, deshalb hier noch ein kleiner Nachtrag bezüglich der Userkonten:

Man kann hier natürlich bezüglich des Sinns der admin Gruppe im Allgemeinen und deren Daseinsberechtigung hin und her diskutieren. Das wird auch irgendwann recht theoretisch. Meiner Meinung nach ist diese gesamte Gruppe murks, aber gut.

Natürlich sollte ein User beim einrichten des Systems nach dem ersten Start einen eingeschränkten Benutzer erstellen sollen. Ganz ohne überhaupt daran denken oder das Wissen dazu haben zu müssen. Das sollte Default sein.

Eine andere Frage, das hast du oben ja einmal kurz angeschnitten ist ob ein User sudoer sein darf oder nicht. An dieser Stelle denke ich, ja jetzt kommt die Komfort Geschichte wieder, dass der erste angelegte User per Default ein sudoer sein sollte. Sudoer müssen ja nicht zwangsläufig per Gruppe definiert werden. Wirkliche Sicherheitsbedenken sehe ich allein in darin nicht. Diese Bedenken kommen ja eher durch die admin Gruppe und deren Rechte ausserhalb des Homes zustande als die Frage ob ein User sudoer ist oder nicht. Letztendlich ist es für Malware m.E. vollkommen unerheblich ob ein User dieses Recht hat oder nicht. Das Kennwort muss ohnehin geknackt werden. Also sind wir wieder bei der von dir angeschnittenen Problematik der Rechte des Admin Accounts in gewissen Systemteilen.

Und somit kommt man schnell wieder auf die Frage zurück ob dieser Admin Quatsch überhaupt sein muss. Das sollte einfach weg und das Problem wäre an dieser Stelle gelöst. Im Grunde kann man sich ja beispielsweise Ubuntu einmal zur Hand nehmen. Dort ist es doch genau so gelöst wie wir das gerade diskutieren. Und das tolle ist ja, dass der Nutzer sich dort gar nicht damit auseinander setzen muss.

... es wird spät und ich glaube ich schreibe hier auch gerade irgendwie im Kreis, also gute Nacht erst einmal.

Ohne Admingruppe müßte man oft auf root wechseln. Dumm. Dazu liefe dann die GUI unter root. Sehr dumm.

MacMark, da erzählst du aber gerade tierisch Quatsch.

Wenn du die Beiträge oben gelesen hast wirst du wissen, dass wir gerade über andere Lösungen diskutieren. In andere UNIX/Linux System arbeitet doch niemand als root in der GUI. Um Gottes Willen.

Man könnte aber beispielsweise bei Bedarf einen sudo absetzen und die GUI würde nicht als Root laufen sondern als Benutzer der Gruppe staff und bei Bedarf, also wenn der Nutzer wirklich explizit eine administrative Aufgabe erledigen möchte nach dem Passwort fragen um diesen einen Task ggf. mit privilegierten Rechten durchzuführen. Das ist auch bei vielen Linux Distributionen so.

Ich halte es ganz im Gegenteil für viel Dümmer eine admin Gruppe zu haben, welche nicht dem klassischen UNIX Schema folgt und Rechte ausserhalb des Home Folders des Users hat. Genau so konnte sich die letzte Version von MacDefener überhaupt irgendwo ablegen. Würde es so gehandhabt wie oben beschrieben, ginge das nicht, denn der Benutzer würde durch eine Passwortabfrage darauf aufmerksam, dass dort irgendetwas vor sich geht.

Im Uebrigen:

Momentan ist es ganz genauso gehandhabt. Auch wenn dein User Mitglied der Admin Gruppe ist, werden einige Aufgaben die du über die GUI startest mit superuser Privilegien ausgeführt, wenn dies erforderlich ist. Da ist nichts mit Benutzerwechsel. Und gerade weil UNIX dieses schöne System bietet ist es komplett sinnlos eine admin Gruppe zu haben, die mehr Privilegien besitzt als eine normale Usergruppe. Denn man ist ständig mit diesem Benutzer unterwegs.

Dann haben User in staff also sudo-Berechtigung. Keine gute Idee. Außerdem ist sudo unsicherer als das Authorization Services Konzept (Security Server et cetera) von OS X, das die GUI nutzt.

Der MacDefender kann auch mit Userrechten im Home des Users gespeichert werden. Das macht keinen Unterschied für die Effektivität dieser Scareware.

Kein Benutzerwechsel? Dann hätte die Admin-Gruppe ja Superuser-Rechte. Das ist jedoch nicht der Fall. Daher:

Falsch! Erstens läuft dabei nie etwas mit Superuser-Rechten (root) in der GUI. Zweitens laufen die entsprechenden angestoßenen Non-GUI-Tasks mit root, aber nicht unter einem Admin-User. Die Admin-Gruppe auf OS X hat keine Superuser-Privilegien.

Och Mensch da hast du scheinbar wieder nicht alles gelesen...

Also nochmal:

Nein, haben sie nicht automatisch. Wer sagt denn, dass die gesamte Gruppe staff als sudoer Konfiguriert sein muss? Dies kann per User geschehen und muss nicht die gesamte Gruppe betreffen. Zweitens ist sudo alles andere als unsicher, denn auch die sudo Privilegien lassen sich auf einer per User Basis definieren. Das bedeutet also, dass ein angestossener Task nicht direkt mit superuser Rechten laufen würde, sondern mit denen des sudoers. Sollte dieser Task also irgendwo kompromittiert sein, wäre dessen Zugriff noch immer auf den sudoer eingeschränkt und hätte nicht direkt volle superuser Rechte.

Das ist richtig und genau der Punkt , trifft aber nicht automatisch auf andere Malware zu. So wie sich MacDefender eingenistet hat, kann das andere Schadsoftware auch Problemlos tun. Wäre diese wie du selbst schreibst nur auf das Home Verzeichnis beschrankt, könnte sie auch nur dort wüten. Der Schaden würde sich in Grenzen halten und vom System fernhaften.

So wie es allerdings momentan mit der Admin Gruppe ist, und vor Lion war das noch schlimmer, kann eine Malware eben auch in gewissen Teilen des Systems wüten. Das ist der springende Punkt. Deswegen macht dein Argument hier m.E. gar keinen Sinn. Denn der Schaden wäre in dieser Situation deutlich größer.

Habe ich ja auch nie gesagt, dass irgendetwas in der GUI mit superuser Rechten läuft. Aber das, was die GUI letztendlich anstößt läuft u.U. sehr wohl mit solchen Rechten. Es findet also ein transparenter Benutzerwechsel statt, richtig, das ist aber für den User nicht unbedingt ersichtlich und weit, weit davon entfernt was du weiter oben geschrieben hast:

Das ist nämlich totaler Quatsch. Und du hast gerade ja selbst gesagt wie es wirklich läuft, nämlich unabhängig von der Frage ob eine admin Gruppe da ist oder nicht. Tasks werden über die GUI angestossen und laufen nach Passworteingabe mit höheren Privilegien ab.

Also nochmal: Wozu der admin Quatsch. Genau das hier beschriebene Verhalten laesst sich, und ist auf anderen Systemen bereits, besser implementiert. Ohne, dass irgendein tagtäglicher Benutzer Rechte ausserhalb seines eigenen Homes haben muss. Und ausloggen und als root in eine GUI einloggen um etwas administratives zu tun muss man sich dort auch nicht.

Fakt ist, dass die OS X Admin User genau hierin Schwachstellen haben und es nicht ersichtlich ist, weshalb dieser Weg überhaupt eingeschlagen wurde. Denn notwenig ist dies nicht und es gibt Systeme die machen es schon länger erfolgreich anders, als OS X überhaupt existiert. Und da man diese Schwachstellen auch nicht von der Hand weisen kann verstehe ich nicht, wie man in diesem Zusammenhang argumentieren kann, dass die Lösung über eine admin Gruppe sicherer sein soll als sudo.

Im Uebrigen, das habe ich oben auch nicht so richtig dargestellt, sind ja auch alle User der admin Gruppe ohnehin sudoer. Und sudoer oder nicht, Authentication Services hin oder her... all das steht vollkommen unabhängig davon ob überhaupt eine admin Gruppe in dieser Form existieren muss bzw. ob diese überhaupt ungefragten Zugriff auf gewisse Systemteile haben muss. Und ich denke das ist ein ganz klares nein. Eine Passwortabfrage wäre in diesem Fall angemessen und sinnvoll.

Die admin Gruppe würde dann Sinn ergeben, wenn diese ausschliesslich definieren würde, ob User, die dieser angehören temporär durch Authentifizierung höhere Rechte erhalten können oder nicht. Und dies setzt wie gesagt nicht voraus, dass diese sogenannten Admin User das im Filesystem mehr Rechte haben müssen als alle anderen. Ganz ohne Authentifizierung. Das ist fahrlässig.

Admins sind auf OS X dazu da, GUI-Apps für alle User zu installieren. Das ist sinnvoll, denn bei anderen Unices mußt Du (per sudo) auf root wechseln, um so etwas zu tun. Unter OS X hast Du also weniger oft Code unter root laufen als anderen Unices dank der Admin-Gruppe => Sicherer.
Außerdem sind Admins auf OS X dazu da, Systemupdates zu autorisieren. Bei anderen Unices muß der User dazu (per sudo) auf root wechseln. Wieder hat OS X weniger oft nötig, einen User unter root arbeiten zu lassen => Sicherer.

Das Alles-Oder-Nichts-Prinzip (normal oder root) bei anderen Unices und GNU/Linux ist für den Desktop-Einsatz nicht sinnvoll. Denn ohne Admin-Group muß man zu oft auf root wechseln (per sudo), was Normalsterblichen nicht zuzumuten ist und zudem erhöhte Angriffsflächen bietet.

Was Dir an der Admin-Gruppe fahrlässig vorkommt, akzeptierst Du für andere Unices klaglos, die in dem Fall sogar auf root gehen müssen. Unter OS X muß ein User normalerweise nie auf root gehen. Nie.

MacMark

Das ist natürlich eine ganz interessante Frage hier abzuwägen was sicherer ist. Ich bin der Meinung, dass ein User wie Admin in der derzeitigen Form eben gefährlicher als sudo ist. Einfach weil diese extensiven Rechte einfacher missbraucht werden können und so komplett ohne des Users Zutun und Wissen irgendetwas abgelegt werden kann ohne dass sich eine Malware überhaupt anstrengen müsste. Dazu auch noch versteckt in irgendwelchen Teilen der Library.

Ja, nein. Ich akzeptiere es eben nicht.
Wie gesagt halte ich die durch einen berechtigten User gewünschte Freigabe höherer Privilegien für eine bestimmte Aufgabe für sicherer, als wenn diese Aufgabe überhaupt keine explizite Freigabe benötigt. Da steht eventueller Malware eben ein weiterer Teil des Systems offen.

Der Tradeoff des ganzen ist ja, dass in diesem Fall unter OS X jedem Heimanwender empfohlen werden sollte nicht auf dem Admin Account zu arbeiten, sondern stattdessen einen normalen User anzulegen eben weil dieser Account erhöhten Risiken ausgesetzt ist, anstatt dem nur bei Bedarf ausgesetzt zu sein. Siehe Diskussion mit sierkb oben. Und genau das ist ja das Problem. Es ist momentan nicht von Apple automatisiert, es tut momentan so gut wie keiner. Und da sind wir wieder genau bei der Frage warum muss das so ungünstig sein?

Es wäre ganz einfach dem Benutzer einen ganz normalen User zu geben. Dieser könnte nämlich ganz genauso Anwendungen installieren, allerdings eben nur nach Eingabe eines Admin Passworts und genau das würde die Sache sicherer machen als jetzt.

Die arme Alice

Jeder Beitrag zum Thema Viren endet in der Regel zu einem Schlagabtausch zwischen MacMark und sierkb.

Das ist praxisfremd, denn dann müßte der User sich nicht nur sein eigenes Paßwort merken, sondern auch noch eines von einem Admin-Group-User. Das treibt die User dazu, zu einfache Paßworte zu nutzen und trainiert sie darauf, ihr Paßwort blind einzugeben bei jeder Gelegenheit.

Kommt dem User unter OS X ein Trojaner oder Schadcode unter und zur Ausführung trotz Quarantäne und Malware-Erkennungsfunktion, dann läuft er nie (ohne zusätzliche Kernelbugs) unter root, weil der User nie auf root eskalieren muß.
Kommt einem User eines anderen Unix ein Trojaner oder Schadcode unter, dann hat er gute Chance (auch ohne Kernelbug) an root zu kommen, beispielsweise, indem er wartet, bis der User sudo ausführen muß irgendwann und dann nutzt er die Grace-Period, um Sudo seinerseits (ohne Paßwort) aufzurufen und schon ist das komplette System Toast. Oder der Trojaner wird direkt vom User selbst mit sudo befördert.

Das "alles oder nichts" funktioniert nur bei Firmen, die einen dedizierten Admin haben, der alle Programme installiert, aber nicht auf dem Desktop zuhause. Einer der Gründe, warum OS X das erfolgreichste Desktop-Unix aller Zeiten ist.

Um mal etwas mehr zur Praxis zurückzukommen: Nimm derzeit auf keinen Fall etwas von Symantec! Kein Norton irgendwas! Nachdem ich es schon vor Jahren mal ausprobiert hatte und es eine Katastrophe war, wollte ich es vor ca. einem Jahr mit der damals aktuellen Version nochmals probieren - immer noch Katastrophe. Tiefe Systemeingriffe, unübersichtlich und einfrierendes System bzw. Abstürze. Dann Virus Barrier ausprobiert ("Dual Protection", habe parallel diverse Windows-Installationen laufen) von Intego. Das lief im Grunde ganz vernünftig, besitzt auch eine brauchbare Firewall und zeigt ein- und ausgehende Verbindungen an. Allerdings verlangsamt auch das den Mac gelegentlich spürbar. Leider hat es mit einer speziellen Präsentationssoftware, die ich brauche, nicht zusammenarbeiten wollen, so dass ich es zumindest auf dem Laptop wieder deinstalliert habe. Dort benutze ich wieder CLAM X:
http://www.clamxav.com/
Das ist kostenlos und bringt keine spürbaren Einbußen, ist recht einfach aufgebaut, damit allerdings auch weniger komfortabel.
Jenseits der Diskussion (die ich auch immer wieder mit Interesse verfolge), ob man auf dem Mac ein "Virenschutzprogramm" braucht, tauschen sehr viele Mac-Nutzer Daten mit Win- oder Linux-Nutzern aus. Und da besteht nun mal die Gefahr, dass man z.B. Würmer, Viren oder andere Malware mitüberträgt. Und um das auszuschließen, ist ein gelegentlicher Test der dafür genutzten Rechner, bzw. Bereiche imho sinnvoll.
Just my 2 cents.

Um mal wieder mehr zum Offtopic zurückzukommen:

Fünferpacks von Vierenprogrammen von Drittanbietern aus zweiter Hand sind meine erste Wahl.

Noch eine Ergänzung:

StdOut
Sudo ist ein setuid-Programm. Setuid-Programme sind ein Sicherheitsrisiko per se und das Ziel von Apple ist, den Einsatz von ihnen zu reduzieren. Zur Privilege-Separation wird von OS X launchd eingesetzt, was auch setuid-Programme wie sudo ablösen kann. macmark.de/osx_launchd.php

GNU/Linux übernimmt übrigens dieses Konzept von Apple: macmark.de/blog/osx_blog_2011-05.php#systemd

Wo Du bei anderen Unices sudo brauchst, um die User-Id in der Session zu wechseln, stellt Mac OS X sicher, daß ein entsprechend autorisierter User am Keyboard sitzt beziehungsweise ob die nötigen Credentials für das Recht, die privilegierte Aktion laufen zu lassen, vorliegen, und führt die privilegierte Task dank launchd unter einem anderen User aus ohne daß es sudo dafür braucht.

Nein, denn ein User der Administrator-Gruppe unter Windows 7 ist gleichmächtig zum System.

Bezüglich "Antiviren-Programme für Mac OS X" kann ich hier jetzt aus eigener Erfahrung nur für drei kommerzielle Produkte sprechen:

1. Intego VirusBarrier ist mir dabei bisher am angenehmsten aufgefallen, zumal die Firma schon seit Mac OS 8 Zeiten auf dem Apple-Markt aktiv ist (von ihnen kam übrigens auch der erste Malware-Scanner für iOS ).

2. Vom Einsatz bei einer GmbH mit mehr als 500 Mitarbeitern kenne ich außerdem Symantec Endpoint Protection , welches zwar beim LiveUpdate (dem Java-basierten Aktualisierungs-Dienst des Programmpaketes) manchmal "etwas hakt", aber ansonsten ebenfalls zuverlässig und stabil seinen Dienst verrichtet.

Von beiden genannten Programmen wird die CPU weder auffällig stark belastet, noch gab es Sicherheitslücken, die erst durch diese AV-Software ins System geschleust wurde (was ja auch hier im Forum immer wieder mal behauptet wird).

3. Als instabil habe ich jedoch die Mac-Version von Kaspersky Anti-Virus erlebt: (und umso erstaunlicher, wie so etwas "Testsieger" der Macwelt werden konnte … )

ClamXav kenne ich zwar auch, dessen Scan-Leistung reicht aber bei weiten nicht an die der kommerziellen Produkte heran.

Das ebenfalls kostenfreie Sophos AntiVirus habe ich mir noch nicht angesehen, ich kenne bisher nur eine ältere BETA, deren Implementierung aber ebenfalls zu Wünschen übrig ließ …

Dann wäre da noch PC Tools iAntiVirus , welches aber ausschließlich Mac-Malware erkennt.

Und diese hier habe ich persönlich noch nie ausprobiert (jemand von Euch vielleicht?):

McAfee VirusScan

Bitdefender Antivirus

F-Secure Anti-Virus

Norton AntiVirus

Als Beta existiert außerdem eine freie Version von avast! Antivirus

Ich bin gerade selbst etwas überrascht, wie viele Anti-Malware-Software es mittlerweile auch für Mac OS X gibt …

Rootkit-Scanner für Mac OS X klammere ich jetzt mal aus … Getestet habe ich zwar mal diesen hier ab und an , gefunden habe ich aber nie etwas …

Über den Sinn oder Unsinn dieser Programme möchte ich hier jetzt nicht streiten, meiner Meinung nach muss dies jeder Privatanwender für sich selbst abwägen. Zumindest wer viele Daten auch mit Windows-Nutzern austauscht, kann sich eventuell einigen Ärger und Frust ersparen, wenn er garantieren kann, dass er z.B. keine verseuchten/gefährlichen Dokumente weiterleitet.

PS: Den hier (Eset Antivirus) hatte ich noch vergessen, wobei auch dessen BETA mehr als enttäuschend war (und wahrscheinlich deshalb hatte ich es auch nicht mehr auf dem Schirm):