Marcel_75@work, Angelo scheint ja ein dicker Freund von dir zu sein, nimm's halt nicht persönlich

Gut, dann wäre zu klären, wieviele Installer tatsächlich root-Rechte brauchen. Meine Vorstellung war eher, dass man sich als root anmeldet für die Installation von ein oder zwei tools (wenn man die denn haben will), ansonsten also unbehelligt davon bleibt. Insofern wäre es nicht die Windows-Situation (man installiert LittleSnitch ja nicht täglich , im Gegenteil). Ansonsten finde ich den Gedanken mit den partiellen root-Rechten ja ganz reizvoll, aber eben nicht, wenn es sich tatsächlich recht leicht ausnutzen ließe.

Die Mär, dass Mac-User nicht auf alles klicken, was sich bewegt, glaube ich nämlich nicht. Ich hatte mal den Versuch gemacht und Freunden ein "Test-Programm" geschickt (nur ein leicht verstecktes Skript, welches ein Textfenster öffnete) und natürlich, selbstverständlich haben´s alle geöffnet. Und ob man dabei ein Admin-PW eingeben muss oder nicht...

Ties-Malte
Es gibt nur einen Installer auf Mac OS X: /Applications/Utillities/Intaller.app. Dem wird in der Regel ein sogenanntes Installer-Package (Icon ist ein gelber Karton) übergeben. Dieses Package installiert der Installer dann. Dieser systemeigene Installer ist der, auf den ich mich bezogen habe.
Möglicherweise, muß davon nicht jedes Paket mit Hilfe von sudo installiert werden. Aber um sicherzustellen, daß wirklich ein Admin am Werk ist, wird nur per Admin-Password installiert. Andernfalls hätten wir hier eine echte Sicherheitslücke.

Dann gibt es noch Programme, die einen eigenen Installer nutzen. Der braucht in der Regel kein Admin-Password.

Dann gibt es noch Programme, die gar keinen Installer nutzen, sondern einfach vom User manuell auf die Platte kopiert werden.

MacMark

Sorry, aber was du schreibst, ist so nicht richtig. Wenn du ein .pkg oder .mpkg installierst (wenn du also die Installer.app von nutzt) wird nicht zwangsläufig dein Admin-Passwort abgefragt.

Dieses wird nur abgefragt, wenn der Installer Dateien in Verzeichnisse ablegen oder Funktionen ausführen soll, auf die du als Admin keinen Zugriff hast. Die Passworteingabe ist deine Antwort auf ein vom Installer initiiertes sudo. Du gibst dem Installer also in dem Moment die Rechte des root-Users.
Es gibt keine Passwortabfrage nur um Sicher zu stellen, dass du auch wirklich der Admin-User in Persona bist.

Ebenso läuft es mit anderen Installern (z.B. VISE).

Nochmal Sorry, aber widersprichst du dir in den beiden Absätzen nicht ein wenig?

Das ganze Problem an der Situation "StartupItems" ist dich folgendes:
-Jeder Admin-User kann diesen Ordner anlegen.
-Jeder Admin-User kann ohne Passworteingabe StartupItems dort ablegen.
-Beim nächsten Neustart werden diese StartupItems im Root-Kontext ausgeführt.

Ergo: Es ist möglich, Prozesse im Root-Kontext laufen zu lassen, ohne dass an irgend einer Stelle je das Passwort eines sudoers oder des Root selber eingegeben wurde. Das stellt die eigentliche Sicherheitslücke dar.

@Hinnerk: kann ich nur bestätigen!

Außerdem wurde das auch schon hier

vor Monaten!!! näher erläutert.

Dennoch gibt es Leute wie MacMark, die mit ihrem "gefährlichen Halbwissen"... ach lassen wir das, die einzigen, die hier bei jeder Kleinigkeit "auf die Palme springen" sind eh Hot Mac und MacMark...

PS: ein Interview wird demnächst übrigens alle Fragen klären, also noch einmal der Aufruf an alle:

Stellt Eure Fragen jetzt und sie werden hoffentlich beantwortet werden!

Und nicht vergessen: der Ton macht die Musik...

Noch einmal speziell an MacMark und Hot Mac:
ist alles nicht sooo ernst oder gar böse gemeint, mir ging es nur um folgende Tatsache – selbst gut austeilen aber nichts einstecken können zeigt Eure, naja, mmh, wie soll ich es nennen ohne schon wieder etwas Falsches zu sagen?

You Know What I Mean!?!

Marcel_75@workAlle? coool . (sorry)
Aber find ich gut, wenn er sich noch mal meldet.
Oh mann... das gilt aber auch für dich, hej! MacMark geht zwar gerne schnell in die Luft, aber man muss doch nicht noch zündeln... aber lassen wir das.

Nee, hast recht - das zündeln hätt' ich mir auch sparen können aber wie gesagt: wer selbst austeilt muss auch einstecken können...

Aber nun wieder zurück zum eigentlichen Thema, oder?

Vielleicht möchte der eine oder andere ja noch einmal konkrete Fragen formulieren? (bitte aber möglichst keine, die schon hier

geklärt wurden...

Mal eine Anmerkung von mir.

Technisch finde ich die Diskussion hilfreich.

Es ist allerdings schade, dass bei einigen technische Fragen, die gestellt oder auch beantwortet werden, die gleichen Poster dann in einem Nebensatz noch ein teilweise unsachliches subjektives Argument mit eingefügt wird.

Ich möchte hier keine Namen nennen, bitte aber darum, technische Argumente nicht mit subjektiven Angriffen zu vermengen.

Das tut der Diskussion nicht gut.

Danke

Jochen

@Ties-Malte: und Du hast recht - alle Fragen werden sicher nicht geklärt werden... also noch einmal anders formuliert:

Das Interview wird demnächst eventuell einige aufgetauchte Fragen klären.

Murdock

ja, das geht manuell. Im Terminal kannst du die selben Befehle eingeben, wie sie im Workaround oben für die Cronscripte genannt werden. Nur musst du dich vorher via sudo mit Root-Rechten ausstatten. Also...

sudo chown -R root:wheel /Library/StartupItems
und
sudo chmod -R og-w /Library/StartupItems

oder per Info Dialog den User "System" zum Eigentümer machen, ihm Schreib und Leserechte geben, ebenso mit der Gruppe verfahren (Gruppenzugehörigkeit wäre dann "wheel"), die anderen User sollten nur lesen dürfen.

Wenn dir das alles noch ungenügend ist, konfiguriere eine Ordneraktion für /Library/StartupItems, die dir mitteilt, wenn sich im Ordner etwas ändert. So kannst du im Einzelfall entscheiden, ob die Änderung OK ist oder nicht.

Endlich mal ein konstruktiver Beitrag. Danke Hinnerk!

Hinnerk
Das ist nichts schlimmes, sondern normales Unixverhalten.

Man muß Admin sein, um etwas in /Library/StartupItems/ zu installieren. Wenn Du auf der shell nicht als Admin eingeloggt bist, dann kannst Du dort (/Library/StartupItems/) nichts machen.

Selbst wenn /Library/StartupItems/ nicht vorhanden wäre, kann ihn auch nur ein Admin anlegen, den /Library/ erlaubt ebenfalls nur Admins ein neues Verzeichnis in /Library/ anzulegen

Es ist das Konzept von Unix, daß Admins dort startup items ablegen und es ist auch so gewollt, daß sie als root laufen. Der Sinn ist, daß damit systemweites Verhalten beeinflußt wird oder ein systemweiter Dienst zur Verfügung gestellt wird, beispielsweise MySQL, selbst wenn niemand eingeloggt ist, für alle User der Maschine einschließlich Usern über das Netzwerk.

Ihr seht Probleme, wo keine sind.

MacMark

Wenn du das in Ordnung findest, warum prangerst du dann das Konzept von Windows an, bei dem Admin und Root eins sind?

Ich finde es jedenfalls nicht in Ordnung, wenn ein Prozess durch einen simplen Neustart mehr Rechte erlangt.

Eventuell verwechselt Ihr auch /Library/ mit /System/Library/.

So ist /System/Library/StartupItems/ reserviert für startup items von Apple.
Admins sollen ihre eigenen startup items in /Library/StartupItems/ ablegen.

Permissions von /Library/StartupItems/ sind:
drwxrwxr-x 5 root admin 170 2 Dec 2003 StartupItems
Permissions von /System/Library/StartupItems/ sind:
drwxr-xr-x 34 root wheel 1156 28 Oct 02:53 StartupItems

Seit Mac OS X 10.2 sind Admins nicht mehr Mitglied von wheel, sondern nur noch von staff und admin.

Verzeichnisse in /System/ sind in der Regel auch vor administrativem Zugriff etwas geschützt, da die Permissions wie in obigem Beispiel aussehen. Verzeichnisse in /Library/ genießen hingegen weniger Schutz und sind wie in obigem Beispiel der Gruppe admin zugeordnet und nicht wheel.

Wenn ihr nun per Hand /Library/ oder /Library/StartupItems/ wheel zuordnet, und nicht wie es sich gehört admin, dann handelt Ihr eigenmächtig am Grundkonzept vorbei. Diese Umstellung ist nicht normal und nicht gewollt von Apple.

Was Apple will und was nicht, ist mir hier eigentlich ziemlich Latte.
Apple hat halt Fehler im von dir erwähnten Grundkonzept. Warum soll ich die nicht mit einfachen Mitteln richten, bis Apple sie ausmerzt?

Hinnerk
Ein Admin kann nur temporär als root agieren unter Mac OS X. Jede root-Aktion eines admins wird per sudo ermöglicht und macht dem Admin deutlich, daß er nun mit diesem einen Befehl etwas außergewöhnliches tut.

Jeder Windows "Admin" ist immer "root". Immer. Sie haben keine Sonderaktion, die sie vor versehentlichen Fehlern schützt.

Es ist der Sinn von StartupItems, daß sie von Admins in diesem Verzeichnis angelegt werden. Es ist von Unix so gewollt, daß sie danach unter root laufen. Das ist der Zweck davon. Was Ihr hier als Bug anseht, ist ein völlig normales Unix-Feature.

Hinnerk
Es ist kein Fehler, sondern in Ordnung so. Wie geschrieben, sind die Rechte mit Absicht in /Library (group admin) anders als in /System (group wheel).

Nochmal zum Mitschreiben:

Die Rechte der Ordner sind anders. Die StartupItems die in ihnen liegen werden aber alle beim Bootvorgang vom SystemStarter gestartet. Sie laufen ergo mit Root-Rechten. Und das ist nicht in Ordnung.

Nehmen wir mal folgenden Fall an:
Du benutzt die ipfw von , hast in den Systemeinstellungen sichergestellt, dass nichts die Einstellung der ipfw verändern kann, ohne dass nach dem Passwort von root oder eines sudoers gefragt wird.

Du fühlst dich sicher, warum auch nicht?

Du lädst dir ein (um mal bei Angelos Beispiel zu bleiben) Programm herunter, dass als .pdf getarnt wurde und Malware enthält. Du öffnest es und im Hintergrund wird ein StartupItem in /Library/StartupItems gelegt. Du liest das PDF und wähnst dich in falscher Sicherheit.

Beim nächsten Neustart lädt das StartupItem einen Trojaner auf den Rechner und Startet diesen. Natürlich läuft dieser im Root-Kontext, da er ja vom StartupItem gestartet wurde, welches vom SystemStarter gestartet wurde. Dieser Trojaner konfiguriert deine Einstellungen der ipfw um, macht einen Port offen und lauscht an diesem. Jetzt stehen demjenigen auf der anderen Seite Tür und Tor offen. Er könnte eine Shell öffnen, deine Post lesen, deinen Server zum Absturz bringen, alles was als Root so geht....

Du als User fragst dich natürlich, wie konnte man soweit kommen ohne das Passwort zu kennen? Ausnutzen eines BufferOverflows, eine Wörterbuchattacke oder dreckiges BruteForce?

Nein, war alles gar nicht nötig, da ein paar Systemdesigner bei Apple Mist gebaut haben.

Würden die Rechte von /Library/StartupItems so sein wie die von /System/Library/SatrtupItems so hätte es dich bestimmt gewundert, warum du beim Öffnen eines "ganz normalen" PDFs dein Passwort eingeben sollst. Du hättest gestutzt und eine Kompromittierung deines Systems hätte nicht stattgefunden.

Meiner Meinung nach ist es völlig egal, ob nun über- oder untertrieben wurde. Wenn es auch nur den kleinsten Hinweisauf Lücken gibt sollte gehandelt werden. Ich bin den Leuten im CCC, die etwas FÜR Sicherheit machen wollen, dankbar, dass sie ein Auge auf der Sache haben.

P.S. Gibt es wieder Videomitschnitte o.Ä.?

Mit einem Trojaner kann man so oder so alles machen. Jemand schreibt ein Programm, das angeblich Bilder komprimiert und zwar besser als andere. Das tut es auch, aber es formatiert auch Deine Platte beim dritten Aufruf. Das kann es, weil es beim Installieren nach einem Admin-Password gefragt hat.

Wenn also erst ein Trojaner das Problem auslösen kann, dann ist es keine Sicherheitslücke, denn ein guter Trojaner braucht solche Schützenhilfe nicht.

ah i see: "Audio- und Videomitschnitte des Konferenzprogramms sollen in ein bis zwei Wochen über den FTP-Server des CCC (ftp://ccc.de/) unter einer Creative-Commons-Lizenz verfügbar gemacht werden"

MacMark

Der Trojaner war nur ein Beispiel für Malware, aber red' es dir ruhig schön.

Hinnerk
Gibt es einen anderen Weg, diese "Lücke" effektiv zu nutzen, außer mit einem Trojaner?

Hier



und hier



gibt es jetzt übrigens auch die ersten Meldungen zum Thema.

ALLEN einen guten Rutsch ins neue Jahr wünsche ich!

Habe auch noch was beizutragen!

Sogar der berüchtigte NSA äußert sich zur Sicherheit des Mac OSX.



Die kostenlose PDF-Date kann man sich herunterladen.

Leider kann ich kein englisch

Cu und Gruß
tk

tk69
Der NSA sind diese "Lücken" jedenfalls nicht aufgefallen

MacMark
Vielleicht behalten sie die besseren Lücken auch für sich?

… das traue ich ihnen auch zu. Dann steht auch "classified" auf den Seiten und nicht "unclassified".

Injection und Overriding, beides Vorgehensweisen, die schon unter den Mac OS 9-üblichen Systemerweiterungen Gang und Gebe waren, sind ein altbekanntes Vorgehen und wurden für Mach, also auch Mac OS X, schon spätestens im Jahre 2003 dokumentiert im "besten Paper" der MacHack 2003:
rentzsch.com/papers/overridingMacOSX
(Wahrscheinlich auch seit ewig irgendwo in Apples Developer Doku zu finden.)

Also ist es ebenfalls ein nützliches Feature, das uns hier als "Sicherheitslücke" verkauft werden soll.

Dieser "Bug" ist also schon seit fast zwei Jahren bekannt. Wenn diese "Lücke" tatsächlich eine wäre, dann hätte sich garantiert schon jemand in der "Szene" damit profiliert, den ersten ernsthaften Mac OS X Schädling geschrieben zu haben. Also entweder reichten die fast zwei Jahre nicht aus, um die "Lücke" zu nutzen oder es ist keine Lücke.

Angelo Laub liefert - mit Verlaub - alten Wein in neuen Schläuchen. Das alte Mach-Feature als "Sicherheitslücke" bezeichnen und schon hat man eine sichere Schlagzeile. So etwas kann man nur als unseriöus bezeichnen!

Moin.
Ich mag auch noch mal ein Beispiel geben, warum die Rechte von /Library/StartupItems ärgerlich sind. Wenn es schon jemand anders gebracht hat, tut es mir leid, das war mir um die Uhreit zu viel Text . Falls es zu kindisch formuliert ist, möchte ich mich im voraus entschludigen ...

Mein User ist der Standard-Benutzer, der bei der Installation angelegt wird. Ohne irgendwelche Nachfragen konnte ich den Sidetrack-Daemon
(Braucht man für SideTack, dieses Dingens, damit man mit dem Trackpad venünftig arbeiten kann...)
nach /Library/StartupItems verschieben. Grund für die fehlende Nachfrage sind die Rechte (interesant ist das in der Zeile die mit . endet):

[01:46][sicheise@Icebook:/] > la /Library/StartupItems/
total 16
drwxrwxr-x 3 root admin 136 1 Jan 01:36 .
drwxrwxr-x 42 root admin 1428 1 Jan 01:36 ..
drwxrwxr-x 6 root admin 204 26 Nov 21:53 SideTrack

Die erste Zeile bedeutet nämlich:
d: /Library/StartupItems ist ein Ordner
r: root darf lesen (read)
w: root darf schreiben (write)
x: root darf in den Ordner wechseln
r: Mitglieder der Gruppe admin dürfen lesen (read)
w: Mitglieder der Gruppe admin dürfen schreiben (write)
x: Mitglieder der Gruppe admin dürfen in den Ordner...
r: Alle anderen dürfen den Ordner lesen (read)
-: Alle anderen dürfen da nicht herum schreiben !!!
x: Alle anderen dürfen in den Ordner Wechseln.

Der einzige Unterschied zu den "anderen" StartupItems ist das "w" für die Gruppe admin. Das ist auch das Problem:

[02:00][sicheise@Icebook:/] > groups
sicheise appserverusr admin appserveradm

Das bedeutet, der normale Benutzer (hier "sicheise") ist Mitglied der Gruppe "admin"

Zusammen bedeutet das: Jedes Programm dass ich starte (und auch ein böswilliger Mensch am Computer) darf ohne Nachfrage Dinge in diesen Ordner kopieren!
Wenn es ein "-" wäre, würde der kleine "Identifizieren" Dialog angezeigt.
(Die Zeile müsste also bestenfalls
drwxr-xr-x 4 root admin 136 1 Jan 01:36 .
lauten!!!)

Na gut. Bis jetzt darf irgend ein Huster ungefragt Zeug in einen Ordner legen. Und nu?
Nach dem nächsten Neustart wird das Program das der Huster da abgelegt hat gestartet. Und?

Ein kleiner Blick in die laufenden Prozesse (Dienstprogramme/Aktivitäts-Anzeige; siehe screenshot) verrät uns, dass das Programm "sidetrackd" dass ich nach /Library/StartupItems verschoben habe, so läuft, als ob es von root gestartet worden ist!

Auf einem Unix-System (also auch bei OS-X) darf root alles! Insbesondere Schabernack treiben (Passwörter mitloggen, SPAM verschicken, ...)!
Programme die von root gestartet werden dürfen das auch alles!

Konkret: Bei Version-Tracker findet man Keylogger. Den auf einen UBS-Stick, beim Apple-Händler in der Mittagspause mal einstecken, Rechner neustarten, eine Woche warten ...

Ich mag nicht, dass irgend ein Huster mir einen Keylogger auf meinen Rechner schiebt!
Das mit dem überflüssigen "w" ist jetzt keine überwältigende Design-Schwäche, sonder wohl eher eine Unachtsamkeit. Nachdem ich das "w" auch selber wegmachen kann (sudo chmod g-w /Library/StartupItems) ist das wohl eher eine kleinere Ärgerlichkeit, die aber bei einem der nächsten Updates (zusammen mit dem Häcklein für Passwärter bei SystemPreferences als Voreinstellung) dennoch behoben werden sollte.

Weil es oben angesprochen wurde: Ein nicht Admin-User hat am System gar nichts zu ändern. Beim Systemstart schon gar nicht!
Wenn er nützliche Dinge automatisch gestartet braucht, kann er die in seine privaten StartObjekte stecken! (SystemsteuerungBenutzerxyzStartobjekte) Die werden dann gestartet, wenn er sich anmeldet.

Gute n8 und frohes neues Jahr

Donar


P.S. Für die etwas ins Detail Verliebten :
[02:28][sicheise@Icebook:~] > sudo cat /etc/sudoers
Password:
...
# User privilege specification
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL

Das bedeuted grob gesprochen, dass jeder in der Gruppe "admin" sudo verwenden kann. Oder anders formuliert: Er darf alles, muss es aber _vorher mit einem Passwort bestätigen_!

MacMark
Stimmt so halt nicht ganz - für faule Leute (die nicht nach jedem timeout das PW wieder neu eintippen wollen und z.B. für headless server configuration) gibt es dafür

sudo -s

Dann ist man solange "temporär" root bis man diese shell mit exit wieder verlässt...

Donar-
Der "normale User" ist nie in Gruppe "admin". Nur Admin-User sind dort drin.

Donar-
Du schreibst:
"Weil es oben angesprochen wurde: Ein nicht Admin-User hat am System gar nichts zu ändern. Beim Systemstart schon gar nicht!
Wenn er nützliche Dinge automatisch gestartet braucht, kann er die in seine privaten StartObjekte stecken! (SystemsteuerungBenutzerxyzStartobjekte) Die werden dann gestartet, wenn er sich anmeldet. "

Nein, denn Admins administrieren den Rechner. Und wenn ein Verhalten systemweit für alle User greifen soll, z. B. "anacron", oder ein Service allen Usern am Rechner und auch denen, die per Netzwerk auf den Rechner zugreifen, zur Verfügung stehen soll, selbst wenn niemand eingeloggt ist, z. B. MySQL, dann muß vom Admin ein entsprechendes StartupItem in /Library/StartupItems/ installiert werden.

Im Privatordner kann es diese Aufgabe nicht erfüllen.

Dieses Systematik ist so bei Unix. Wenn Ihr damit ein Problem habt, dann solltet Ihr kein Unix nutzen.

MacMark:
Vielleicht hab ich mich undeutlich ausgedrückt: Ich bin als Privatmann der einzige der an dem PB werkelt. Es gibt hier genau einen User. Für mich ist der "normale User" der, der bei der Installation angelegt wird. Und der ist definitiv in der Gruppe admin!
MacMark:
Kann es sein, dass du das _nicht_ bei _nicht Admin-User_ übersehen hast? Ich kann jedenfalls keinen signifikanten Unterschied zwischen unseren Aussagen erkennen...

Um es nocheinmal anders zu formulieren:
Mitglieder der Gruppe admin sollen ruhig Dinge nach /Library/StartupItems stecken. Insbesondere wenn es systemweite Dinge (für alle User) sind.

Solange aber der Benutzer, der bei der Installation angelegt wird Mitglied in der Gruppe admin ist (und wohl die meisten Privatleute wie ich mit diesem Nutzer arbeiten), will ich bei jeder Änderung an solchen zentralen Punkten eine Password Abfrage!
Dafür ist die Gruppe admin standartmäßig bei den sudoers. Damit sie, _wenn sie es brauchen_ alles dürfen. Sie müssen sich halt blos vorher authentifizieren! Bei der Menge an administrativen Tätigkeiten am Mac ist das für die gebotene Sicherheit auch akzeptabel.
Bei /Library/StartupItems wird diese Authentifizierung und damit der Sicherheitsmechanismus umgangen, weil die Gruppe admin (und damit der Benutzer mit dem ein Privatmann arbeitet) dort standartmäßig Schreibrechte hat...

Bei Sicherheitsproblemen geht es immer um die normale Verwendung eines Systems. Und Mac OS X ist nunmal in der Hinsicht kein "normales" Unix. Schon alleine wegen der Zielgruppe. Standartmäßig ist root deaktiviert und es wird auch nicht für Administrationszwecke auf einen anderen Benutzer gewechselt...
Wenn man das Sicherheitsnetz z.B. mit "sudo -s" absichtlich umgeht, kann einem das beste System der Welt nicht mehr helfen.

Ich habe überhaupt kein Problem mit der Systematik von Unix. Wenn aber durch eine Nachlässigkeit das Sicherheitssystem umgangen werden kann, dann habe ich ein gewaltiges Problem damit.

Also: Es gibt drei Arten von Usern: "Normalos", Admins und root.

Die Diksussion dreht sich doch jetzt darum, was der Unterschied zwischen einem Admin und root ist. Oder anders formuliert, welchen Unterschied man gerne hätte. Und natürlich um die Frage, wie kritisch es ist, wenn ein Programm von einem Admin installiert wird und dann von root ausgeführt wird.

Aus Sicht menschlicher Benutzer sind die Unterschiede m.E. gering: root muss erst von einem Admin freigeschaltet werden, so daß i.A. der Admin auch über das Paßwort von root verfügt. Falls nun /Library/StartupItems nur von root beschreibbar wäre, mußte man sich als root (temporär) anmelden, um da reinzuschreiben. Wieviele "Normalo"-User, also Nicht-Hacker und anndere Sicherheitsexperten, würden etwa beim Installer mit der Wimper zucken, wennn statt des Admin-Accounts der Root-Account benötigt werden würde? Wenn Normal-User und Admin nicht ein- und dieselbe Person sind, sieht die Sache evtl. anders aus. Aber dann kann der Admin auch die Rechte korrekt reparieren. So gesehen finde ich diesen "Bug" nicht so wild.

Nebenbei: Der Workaround wurde auch schon im Vortrag vorgestellt.

Donar-
Dann liegen wir doch nicht so weit auseinander mit unseren Meinungen.

Allerdings gebe ich zu bedenken, daß man nicht einfach etwas in /Library/StartupItems/ hineinlegen kann, denn damit ist es nicht getan. Wenn es funktionieren soll, was man dort anlegt, dann sind einige technische Arbeiten zu erledigen.

Auf OSXFAQ.com ist genau beschrieben, was das für Arbeiten sind:

osxfaq.com/Tutorials/LearningCenter/HowTo/Startup/index.ws

Es ist ganz offensichtlich so, daß der "normale User", also der Heimanwender, der als Erstuser auch Admin ist, einfach keine Ahnung von den technischen Details hat, die notwendig sind, um ein systemweites StartupItem funktionsfähig in /Library/StartupItems/ zu installieren.

Der Durchschnittsanwender wird weder XML-Dateien noch Startup-Parameter-Listen korrekt einstellen können noch wird er eine Datei mit einem korrekten shell script füllen können mangels Knowhow. Im schlimmsten Fall, wenn er sich doch drantraut, wird sein StartupItem nicht starten. Da zum Editieren der genannten Dateien auch nur Editoren wie der vi oder pico wirklich geeignet sind und nicht TextEdit oder Word, würden die Dateien selbst bei scheinbar korrektem Inhalt nicht funktionieren. Welcher Heimanwender kann den Unix-Editor vi bedienen?

Aus diesem Grund sehe ich nicht die von Dir beschriebene Gefahr, daß der Erstuser-Admin hier dazu neigt oder in der Lage wäre, Mac OS X unsicher zu machen.

Und wenn jemand sich mit XML, mit Startup-Parameterlisten, mit shell scripts und mit dem vi auskennt, dann soll er auch ohne sudo diese systemweiten StartupItems anlegen dürfen, denn er ist qualifiziert.

Es gibt natürlich auch fertige StartupItems, die man per Mac OS X Installer installieren lassen kann. Nur, da die meisten Leute hier nicht einmal das technische Englisch beherrschen, werden sie wohl kaum etwas installieren, dessen technische, englische Beschreibung sie nicht verstehen.

MacMark

Lange habe ich darauf gewartet, daß es in dieser Diskussion zur Sprache kommt, daß die Wahrscheinlichkeit, daß ein ganz normaler Heimanwender über entsprechende Kenntnisse und Fähigkeiten verfügt, um ein systemweites StarupItem überhaupt erst "gangbar" machen zu können, doch eher gering sein dürfte.

In meinem Bekanntenkreis befinden sich unzählige Mac-User, die sich mehr oder weniger gut auskennen, die ihren Rechner privat oder auch beruflich nutzen.
Letztere sind in der Regel mit ordentlichem Wissen, was die Mac-Plattform angeht, ausgestattet, jedoch habe ich mich in den vergangenen Tagen selbst davon überzeugen können, daß einem Großteil der "Normaluser", die Fähigkeit sich "Schaden" zuzufügen - einfach fehlt.

Vielleicht ist das auch gut so, denn dies würde bedeuten, daß die finale Sicherheitslücke immer noch der User selbst ist.

Wer für diese Aussage eine Verifizierung benötigt, dem gebe ich zu bedenken, wie groß das Interesse an diesem Thread ist. Man muß sich nur vor Augen halten, wie oft dieser Thread schon gelesen wurde und wie gering die Zahl der Beteiligten ist.
Dies scheint mir doch ein Zeichen dafür zu sein, daß viele Leser, die als "Normaluser" zu bezeichnen sind, mit "Fachchinesisch" jeglicher Art nur wenig am Hut haben.

Wer also als root in den Eingeweiden des Systems wühlt, der sollte sich schon in seinem eigenen Interesse mit der notwendigen Kompetenz ausstatten.

Da auch ich nicht mit fulminantem Fachwissen aufwarten kann, muß ich abschließend noch eine Frage stellen:

Wie kann ich die Ordneraktion für /Library/StartupItems so konfigurieren, daß ich mitbekomme, wenn sich dort eventuell etwas verändert ?
Nur für alle Fälle.

HotMac: Ich habe mir eine Ordneraktion konfiguriert, die bei jeder Änderung des Ornders Alarm schlägt. (Rechtsklick Ordneraktionen)

stiffler

Vielen Dank.

Probier ich gleich mal aus...

MacMark
Nun ja. Mit nur einem einzigen sudo geht's auch -- schlimmerweise selbst dann, wenn man root gar nicht aktiviert respektive wieder deaktiviert hat (im NetInfo Manager[/b] beispielsweise). Im Terminal als Administrator eine shell öffnen,

[i]sudo su -

eingeben, Administratorpasswort eingeben und root-Zugriff genießen. Sicher, man braucht immer noch ein Administratorpasswort, aber davon zu reden, dass root standardmäßig deaktiviert sei, halte ich auch bei OS X für nicht so ganz zutreffend.

Heiko47
Das setzt natürlich fundiertes Wissen über shell Befehle voraus. Selbst wenn ein normalsterblicher Macuser das nun als Admin im Terminal eingibt, wird es ihm weder nutzen noch schaden, denn was tippt er als nächstes ein? Kennt er irgendeinen funktionierenden shell Befehl und sein Syntax?

Und wer das nötige Wissen und die Praxis zu diesem Thema hat, also etwas unternehmen könnte auf die beschriebene Weise, der wird sehr vorsichtig tippen, wenn er root ist.

Hier findet ihr nun das weiter oben versprochene Interview:



LG,
Marcel_75

… das Interview klingt zum Glück nicht mehr so reißerisch wie seine "keynote"-Folien.

Endlich wurde auch die Sache mit der Mach Code-Injection relativiert.

Insgesamt liefert er in dem Interview eine sachlichere und technisch korrektere Darstellung der Dinge. Warum nicht gleich so, Angelo? Es geht doch

Seine "keynote" hingegen war leider geprägt von einer Art "Rache wegen Apples Mißachtung und daraus resultierender Übertreibung und Verzerrung der Dinge". Schön, daß ihm inzwischen auch die zwei Jahre alte Darstellung der Code Injection (siehe meinen Beitrag weiter oben mit Link) aufgefallen ist. Im Apfeltalk-Forum wußte er davon noch nichts und war überrascht und fragte nach dem Link …

Im ging es bei der "keynote" leider hauptsächlich darum, möglichst viel Staub aufzuwirbeln, was unwissenschaftliches Vorgehen ist. Das Interview zeigt einen deutlich besseren Angelo Laub.

Auf MacGuardians wird das Interview übrigens auch veröffentlicht werden, ergänzt durch eine weitere Frage und Antwort inkl. Screenshot bezüglich des Wurms.

Marcel_75@work

Jetzt sieht die Sache ja schon bedeutend "konstruktiver", aber auch "milder" aus.

Warum nicht gleich so ?

Mit diesem Interview kann wohl jeder Beteiligte leben.

Da hätten wir uns ja gar nicht erst an die Gurgel gehen müssen.

Bin sehr gespannt, wie die Reaktionen auf den angekündigten Screenshot ausfallen werden.

Freut mich, dass es Euch gefällt bzw. nun einige Fragen geklärt werden konnten.

Und wie Du richtig bemerkst haben sich unser aller Gemüter ja auch wieder beruhigt nach all der Aufregung...

Wir sollten alle dankbar sein, dass Angelo zu der Sorte "Hacker" (so möchte er sicher gar nicht genannt werden... gehört, die nicht auf Teufel komm raus Schaden anrichten wollen sondern lediglich um die Sicherheit von Mac OS X besorgt ist.

sehr interessantes und informatives Interview!

sehr informativ, hört sich gar nicht mehr sooo schlimm an
bin gespannt wann das gefixt wird von onkel steve und seinen jüngern

Eine Sache immer noch total falsch von Anfang an und bis heute nicht von ihm richtiggestellt:

Sein "Wurm" ist kein Wurm, sondern ein Trojaner. Ein Wurm verbreitet sich per Definition ohne User action. Angelos "Wurm" hingegen erfordert, daß der User ihn per Hand startet.