Keychain etc: eigentliche Gruppe 80, Gruppe jedoch 0

[asphaltkaffee]

Hallo!
Beim Reparieren der Zugriffsrechte bekomme ich seit heute unten stehende Meldung, dies auch nach div. Neustarts und erneuter Reparatur auch im sicheren Modus.
Ich werde die Ursache wohl kaum ermitteln können.
Also Frage: Ist es okay, wenn wheel und nicht admin als Gruppe gesetzt ist?
Danke, Andreas

Hier die Meldung:

Korrekte Zugriffsrechte für die Dateien bestimmen
Die Gruppe unterscheidet sich für „./Applications/Utilities/Activity Monitor.app/Contents/Resources/pmTool“, eigentliche Gruppe ist 80, Gruppe ist jedoch 0
Eigentümer und Gruppe wurden für „./Applications/Utilities/Activity Monitor.app/Contents/Resources/pmTool“ korrigiert
Zugriffsrechte wurden für „./Applications/Utilities/Activity Monitor.app/Contents/Resources/pmTool“ korrigiert
Die Gruppe unterscheidet sich für „./Applications/Utilities/Keychain Access.app/Contents/Resources/kcproxy“, eigentliche Gruppe ist 80, Gruppe ist jedoch 0
Eigentümer und Gruppe wurden für „./Applications/Utilities/Keychain Access.app/Contents/Resources/kcproxy“ korrigiert
Zugriffsrechte wurden für „./Applications/Utilities/Keychain Access.app/Contents/Resources/kcproxy“ korrigiert
Die Gruppe unterscheidet sich für „./Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool“, eigentliche Gruppe ist 80, Gruppe ist jedoch 0
Eigentümer und Gruppe wurden für „./Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool“ korrigiert
Zugriffsrechte wurden für „./Applications/Utilities/ODBC Administrator.app/Contents/Resources/iodbcadmintool“ korrigiert

Reparatur der Zugriffsrechte abgeschlossen
Die Zugriffsrechte wurden auf dem ausgewählten Volume überprüft oder repariert.

 

[pepi]

Hallo asphaltkaffee, wie auch immer man auf diesen Namen kommt, willkommen zu Apfeltalk.

Welche Version von Mac OS X setzt Du ein?
Gruß Pepi

 

[asphaltkaffee]

"Mein Magen tut so weh, es war Asphalt im Kaffee..."

Morgen & Dank für die Begrüßung.
Was zum Namen inspirierte, findest Du unter <http://www.andiarroganti.com/mono.html>.
Der alte Mac läuft unter v10.4.8.
Zu meinem Posting: Das letzte Update der Sicherheitssoftware greift wohl tiefer ein, als vermutet. Man arbeitet daran. Werde die Auflösung hier posten oder, wehe, wenn's keine geben sollte, den Namen des fraglichen Produkts
Gruß und genieß das Leben,
Andreas

 

[asphaltkaffee]

Update: Die von der Sicherheitssoftware geänderten Gruppen/Rechte sind wohl eine Reaktion auf den "Applefehlermonat" - mehr hier.
Ciao, Andreas

 

[Rastafari]

Update: Die von der Sicherheitssoftware geänderten Gruppen/Rechte sind wohl eine Reaktion auf den "Applefehlermonat" - mehr hier.
Ciao, Andreas

Schmeiss deine "Sicherheitssoftware" getrost in die Mülltonne.
Die durch sie vorgenommene Änderung wirkt etwa so gut wie eine Tasse heisser Tee mit Zitrone gegen fortgeschrittenen Lungenkrebs. Lachhaft gestümpert. Dein System ist genauso sicher bzw unsicher wie zuvor.

 

[asphaltkaffee]

Guten Morgen!
Ist es denn nicht so, dass das "Hantieren" mit Dateien des Benutzers root und/bzw. der Gruppe wheel zumindest die Aktivierung von root voraussetzt, dass aber dieselben Dateien, wenn sie admin mit Schreib- und Leserechte gehören, nicht mehr ganz so unantastbar sind, nachdem man sich als admin identifiziert hat (siehe Rechteänderung beim Installieren der Sicherheitssoftware)? Paranoid? Womöglich. Sachlich falsch? Täte mir leid. Lungenkrank? Hab vor über 13 Jahren aufgehört mit dem Rauchen, und trinke heute lieber Tee zum Frühstück.
Anyway, ich hab die Software (trotz ihres früher legendär schlechten Supports) nicht etwa auf dem Rechner, weil ich ein Ketzer wäre, auch ich finde den Mac und speziell OS X anbetungswürdig, bin mir aber im Klaren darüber, dass mit steigender Attraktivität auf dem Mac nix für ewig "heilig" sein wird, und diese steigende Attraktivität begann für mich 2002 mit dem Kauf meines ersten Macs samt v10.2. Warum also ungehalten sein, sobald man (wenn auch nicht vom Schöpfer Apple selbst) auf "dezente Schwächen" des Systems aufmerksam gemacht wird.
Gruß, Andreas

 

[Rastafari]

Ist es denn nicht so, dass das "Hantieren" mit Dateien des Benutzers root und/bzw. der Gruppe wheel zumindest die Aktivierung von root voraussetzt,

Nein.

dass aber dieselben Dateien, wenn sie admin mit Schreib- und Leserechte gehören, nicht mehr ganz so unantastbar sind, nachdem man sich als admin identifiziert hat

Schlimmer. In diesem Fall ist eine Identifizierung gar nicht mehr nötig. Das ist aber deFacto gar nicht relevant, welche Rechte auf diese Dateien gesetzt sind. Der gesamte Pfad dorthin ist ein Angriffsziel. Für jeden Ordner auf dem Weg dort hin gilt exakt das gleiche wie für die Dateien selbst: Hat die Admin-Gruppe Schreibrecht, kann jeder Administrator OHNE Eingabe eines Kennworts jegliche Manipulationen vornehmen.

bin mir aber im Klaren darüber, dass mit steigender Attraktivität auf dem Mac nix für ewig "heilig" sein wird

Schlangenöl hilft nichts gegen Vampire.
Klopp die Soft in die Tonne. Die macht sich nur ziemlich lächerlich.

Willst du dich gegen diesen Bug effektvoll schützen, musst du folgendes tun:

1.) Rechte reparieren.

2.) Auf die Ausführung solch dubioser "Sicherheitssoft" verzichten. Sie gefährdet dich mehr als sie nutzt.

3.) Getrennte Benutzerkonten einrichten. Vom Administratorkonto aus nur das System administrieren und sonst gar nichts. Dort nur bedingungslos vertrauenswürdige Software ausführen.

4.) Für ALLE anderen Aufgaben ausschliesslich eingeschränkte Benutzerkonten einsetzen.

Wer das konsequent tut, braucht sich vor diesem Flaw nicht zu fürchten.
Wer das nicht tut, dem ist durch solche Kindereien nicht zu helfen. Period.

 

[asphaltkaffee]

Danke für die Zeilen und den Hinweis, nur als Normaluser zur arbeiten. Ich wusste doch, dass ich damit richtig liege.
Aber was ist

bedingungslos vertrauenswürdige Software

? Klingt wie Sicherheitssoftware auch irgendwie nach Illusion
Andreas

 

[Rastafari]

Klingt wie Sicherheitssoftware auch irgendwie nach Illusion

Sicher, das ist immer nur ein relativer Begriff.
Einfache Regeln:
Jegliche Form von Erweiterungen zum System immer nur auf Benutzerebene installieren, nie systemweit. Kontextmenüs, Prefpanes, Services und solches Zeug von Drittanbietern haben in einem Administratorkonto etwa so viel verloren wie ein affiger Junkie im Lagerraum einer Apotheke.
Ausserdem installiere man nie etwas auf Systemebene, das man nur irgendwie schick findet, aber gar nicht wirklich *braucht*. Zum reinen Ausprobieren von Software ist ein zweiter Rechner schon immer die beste Wahl gewesen.
Und was schon mal durch echt böse Sicherheitslücken von sich reden gemacht hat, wird in folgenden Versionen nur selten richtig gut.
Wenn du dich daran hältst, fährst du schon mal ganz gut.

 

[pepi]

[...]Dort nur bedingungslos vertrauenswürdige Software ausführen.[...]

Unter die Kategorie fällt wohl nichtmal das was ich selbst geschrieben habe. Oder vielleicht gerade deswegen?
Gruß Pepi

 

[asphaltkaffee]

Ich habe nun die aktuellen VirusBarrier Definitions deinstalliert. Eigentümer z.B. der Datei iodbadmintool des Utility ODBC Administrator ist jetzt wieder, wie von Apple vorgesehen, System mit Lese- u. Schreibrechten, Gruppe ist admin auch mit wr-Rechten, Andere dürfen nur lesen.

Schmeiss deine "Sicherheitssoftware" getrost in die Mülltonne.
Die durch sie vorgenommene Änderung wirkt etwa so gut wie eine Tasse heisser Tee mit Zitrone gegen fortgeschrittenen Lungenkrebs. Lachhaft gestümpert. Dein System ist genauso sicher bzw unsicher wie zuvor.

Was Du damit sagst, ist, dass oben beschriebener Zustand (Gruppe ist admin mit wr-rechten) nun auch nicht besser oder schlechter ist als der mit installierter Intego-Software und deren Setzung der Gruppe zu wheel mit Lese- u. Schreibrechten?

Wieso? Erklär's mit bei Gelegenheit, als wär ich 5. Interessiert mich per se. Oder nenn mir ein Buch. Danke.
Andreas

 

[pepi]

Die Zugriffsrechte einer Datei (von setuid mal abgesehen) sind mir herzlich egal solange ich einen übergeordneten Ordner manipulieren kann. Ich muß garnicht in dieser Datei schreiben können und tausch Dir Dein ach-so-schreibgeschütztes Tool einfach gegen ein anderes aus.
Gruß Pepi

 

[asphaltkaffee]

Kapiert. Auf User-Ebene heißt das z.B.: Bin ich zu eilig, mich vom einen Account in den andern einzuloggen, um benötigte Dateien zu kopieren, setze ich mit Admin-Rechten Eigentümer und Rechte so, dass ich schnell mal kriege, was ich brauche. Hab ich eigentlich schon 2003 beim Lesen von Th. Maschkes Tutorial zu v10.2 gelernt, aber zu selten gebraucht und bin daher in diesem Denken nicht so zu Hause Also, vielen Dank für die Geduld.
Andreas

 

[MacMark]

... dass oben beschriebener Zustand (Gruppe ist admin mit wr-rechten) nun auch nicht besser oder schlechter ist als der mit installierter Intego-Software und deren Setzung der Gruppe zu wheel mit Lese- u. Schreibrechten?

Wieso? Erklär's mit bei Gelegenheit, als wär ich 5. Interessiert mich per se. Oder nenn mir ein Buch. Danke.
Andreas

Wheel ist die primäre Gruppe von root, vergleiche:
http://www.osxfaq.com/Tutorials/LearningCenter/AdvancedUnix/ugp/index.ws

Da Admins nicht in wheel enthalten sind, müssen sie sich authentifizieren (Paßwort), wenn sie die Datei ändern wollen, also per sudo root werden.

 

[asphaltkaffee]

Wheel ist die primäre Gruppe von root, vergleiche:
http://www.osxfaq.com/Tutorials/LearningCenter/AdvancedUnix/ugp/index.ws

Da admins nicht in wheel enthalten sind, müssen sie sich authentifizieren (Paßwort), wenn sie die Datei ändern wollen, also per sudo root werden.

... und deshalb dachte ich auch, dass es zwar nicht nett ist, wenn Intego kommentarlos Rechte setzt, dies aber immerhin "zu meines Systems Sicherheit" tut und für die oben genannten Files wr-Rechte von admin nach wheel ändert und nicht vice versa.

Aber:

Die Zugriffsrechte einer Datei (von setuid mal abgesehen) sind mir herzlich egal solange ich einen übergeordneten Ordner manipulieren kann. Ich muß garnicht in dieser Datei schreiben können und tausch Dir Dein ach-so-schreibgeschütztes Tool einfach gegen ein anderes aus.
Gruß Pepi

Unix erlaubt mir, mich als sudo zeitweise auf root-Ebene einzuloggen bzw. root mit admin-Passwort zu aktivieren, d.h. es schützt mich natürlich im Zweifelsfalls auch nicht vor meiner eigenen Unwissenheit.
Wie soll mich, so verstehe ich Pepi und Rastafari, irgendeine "Sicherheitssoftware" unter Unix/OSX (von dem anderen kommerziellen System ganz zu schweigen) vor "Schädlingen", die die wenigen Schwächen nutzen, schützen?

Danke, MacMark, für die Links. Es wird Zeit, sich eingehender mit UNIX/OSX zu befassen. Andreas

 

[Rastafari]

Was Du damit sagst, ist, dass oben beschriebener Zustand (Gruppe ist admin mit wr-rechten) nun auch nicht besser oder schlechter ist als der mit installierter Intego-Software und deren Setzung der Gruppe zu wheel mit Lese- u. Schreibrechten?

Zunächst etwas Erhellung zu den einzelnen Gruppennamen:

Die Benutzergruppe "admin" (Kennzahl: 80) ist die Gruppe, in der alle OS X-Benutzer aufgeführt sind, die "den Rechner verwalten dürfen" - sprich: die lokale Administratoren sind. Die meisten der Priviliegien eines OS X-Admin, die ihn vom Normalbenutzer unterscheiden, erwachsen ganz einfach aus der Zugehörigkeit zu dieser besonderen Gruppe.

Die Gruppe "wheel" (Kennzahl: 0) ist dagegen die Privatgruppe des root-Benutzers, in der er (in aller Regel) selbst das einzige Mitglied ist.

(Jeder registrierte Benutzer hat eine solche Privatgruppe, idR mit der gleichen Benennung wie der Nutzername. Auf anderen Unix-Varianten heisst diese Privatgruppe von root dementsprechend ebenfalls 'root', der etwas seltsam wirkende Name 'wheel' ist nur eine BSD-typische Besonderheit mit symbolischem, historischen Bezug. Die Bedeutung dieser Gruppe ist aber exakt die gleiche.)

Zu diesem bekannten Bug nun:

Diese betreffenden Programme (drei an der Zahl) sind mit dem sog. "suid" Bit gekennzeichnet.

Erkennbar ist das in der Langdarstellung des Terminalbefehls 'ls -l Dateiname':
Anstatt des Ausführungsrechts 'x' wird beim Eigentümer ein 's' gezeigt. Beispiel:
-rwsrwxr-x ...blabla... Dateiname

Das bedeutet, dass wenn das Programm von irgendwem ausgeführt wird, es nicht wie normalerweise unter eben den Rechten dieses aktuell aufrufenden Benutzers läuft, sondern stattdessen im Kontext des Eigentümers der Programmdatei. Also genau so, als ob der Eigentümer der Datei das Programm selbst gestartet hätte.

Da der Eigentümer hier "System" (vulgo: 'root') heisst, läuft das Programm immer mit uneingeschränkten Zugriffsrechten, völlig egal von wem es gerade benutzt wird.
Das ist bei diesen Programmen zwar voll und ganz beabsichtigt und für die Funktion notwendig, aber eine äusserst heikle Sache und birgt etliche Tücken und Sicherheitsrisiken in sich, die man beim Einsatz dieses Mittels unbedingt berücksichtigen muss. (Der Einsatz von suid ist in der Unix-Systemprogrammierung generell eine Art "Last Resort".)

Das Recht, ein solches suid-Bit auf eine ausführbare Datei zu setzen, steht natürlich nicht jedermann frei zu. Aber wenn man nicht höllisch aufpasst, kann man es sich ziemlich simpel erschwindeln. Da hat Apple (mal wieder) gepatzt.

Normalerweise verhindert man den Missbrauch von suid-Binaries dadurch, dass man die entsprechenden Dateien nur für den root-Benutzer selbst beschreibbar macht und sie zusätzlich nur an solchen Orten aufbewahrt, wo für ausnahmslos alle Ordner auf dem Weg dorthin genau das gleiche gilt.
Apple hat gegen diese fundamentale Regel verstossen, indem sie in den Standardberechtigungen sowohl dieser Dateien selbst, als auch deren enthaltende Ordner die Gruppenzugehörigkeit auf "admin" gesetzt und dafür der Gruppe Schreibrechte erteilt haben. Alle Benutzer, die einen OS X Rechner "verwalten dürfen" (sprich: die Administratoren sind), dürfen damit den Inhalt der Datei frei bestimmen und ohne jede weitere Nachfrage verändern.

Somit kann ein von einem Administrator unwissentlich gestartetes Stück Malware den Programmcode in diesen Dateien einfach durch einen x-beliebigen anderen Code überschreiben und damit beliebige Dinge tun - unter der Fahne des root-Benutzers. Denn die suid-Berechtigung bleibt bei einem Schreibvorgang in die Datei weiterhin bestehen, der Schadcode würde also beim nächsten Start des (manipulierten) Programms ebenso mit vollen root-Rechten ausgeführt wie der ursprüngliche Inhalt.
Ein Angreifer bräuchte das so manipulierte Programm nur noch unter einem x-beliebigen Konto zu starten und wäre damit "drin" im Allerheiligsten.

Die gefährdete Datei selbst zu "sperren" (ziemlich egal mit welcher Methodik) ist dabei dank der noch unausgereift vorliegenden Reparaturfunktion des Festplattendienstprogramms ein absolut sinnloses Unterfangen. Kann ein Angreifer auf die Datei selbst nicht schreibend zugreifen, wohl aber auf einen Ordner, in dem sie liegt, dann tauscht er einfach einen kompletten Teilbaum des Dateisystems gegen seinen eigenen aus. Dass er so nicht direkt an das ersehnte "suid" herankommt (weil er es selbst nicht vergeben kann), stört ihn nicht weiter. Er braucht dann nur noch darauf zu warten, bis eine Reparatur der Dateirechte durchgeführt wird. Dann versieht das FP-DP nämlich die vermeintlich reparaturbedürftigen, aber in Wirklichkeit die völlig falschen Dateien mit dem erhofften suid-Segen....

Einige Klarheiten beseitigt?

 

[asphaltkaffee]

Vielen Dank, Rastafari, für Deine Geduld und die klare Ansage.
Ich werd alles noch mal durchlesen, und wenn ich's dann morgen beim Frühstück plausibel monologisieren kann, hab ich's wohl verinnerlicht. Erstmal. Liegen die Infos u.U. irgendwo auf Englisch vor? Dann maile ich sie Integos Support. Ich meine, die werden doch wohl wissen, dass sie imgrunde eine Illusion zum Download bereit stellen...
Gruß, Andreas

 

[Rastafari]

Ich meine, die werden doch wohl wissen, dass sie imgrunde eine Illusion zum Download bereit stellen...

There is no business like show business...

 

[asphaltkaffee]

There is no business like show business...

Offenbar, und um den Vergleich zu dehnen, hoffe ich, es ist bloß ein Film im TV und kein sozusagen Malwaremovie auf der HD eines gekaperten Rechners mit heiklen Daten, integrierter Kamera, Mikrofon und Internetanschluss...