Hallo,

ich bin zu limitiert, um das selbst zu machen, daher frage ich, ob hier jemand so freundlich wäre und mir den Quellcode der aktuellen rsync in eine Ausführbare Unix-Datei kompilieren kann, damit ich diese auf meinem M1 nutzen kann. Den Quellcode gibts hier https://rsync.samba.org

Beste Grüße
Tobias

PS. Homebrew und Co ist für mich keine Alternative.

Danke, weia. /usr/local/lib habe ich angelegt und die Dateien liegen jetzt an Ort und Stelle. Morgen gehts weiter, wenn ich den Mac wieder in greifbarer Nähe habe.

@Marcel_75@work
Ich kann deine Argumentation verstehen, jedoch auch die von Weia. Wenn es um ein spezielles Programm X geht, teile ich deine Argumentation. Du weißt, du hast es installiert und rufst es auf, wenn du es brauchst. Bei Homebrew hast du allerdings die Situation, dass der Quellcode aus beliebigen Git-Repos kommt, die du bei der Installation nicht überprüfen kannst, ob diese vertrauenswürdig und sicher sind. Es wäre auch nicht das erste Mal, dass ein scheinbar vertrauenswürdiges Repo Schadsoftware enthält. Wenn diese Schadsoftware nun Standard Unix Kommandos mit ihrem eigenen Schadcode ersetzt bekommst du davon nichts mit, weil die PATH Variabel durch Homebrew erweitert wurde und du nun nicht weißt, ob das System nun /usr/bin oder /usr/local/bin verwendet.

Statt dem systemeigenen mkdir wird nun /usr/local/bin/mkdir aufgerufen, welches dir deine Dateien verschlüsselt.


So zumindest habe ich die Kritik von Weia für mich verstanden. Ich halte die Kritik für gerechtfertigt nutze Homebrew für meine Zwecke aber trotzdem.

KarstenM Danke für die Erläuterung. Jetzt kann ich besser nachvollziehen, was genau die Bauchschmerzen bezüglich Homebrew bereitet.

Ja ist alles soweit korrekt. Zur not muss man Rechte und Ausführbarkeit überprüfen.

Mist!
Aber wenn ich alles zitieren würde, würden die Threads ja noch ausufernder.
Das geht am Problem vorbei. Es geht nicht um die Installation von Apps oder Unix-Programmen. Wenn man sich da etwas Bösartiges holt, kann nichts und niemand den Schaden verhindern; das ist immer so, Cocoa-App oder Unix-Utility. Deshalb sind vertrauenswürdige Quellen so wichtig; etwas anderes als Vertrauen bleibt Dir letztlich nicht.
Nochmal: um die Installation geht es nicht.
Nein, das ist eben nicht egal, das ist der große Irrtum.

Konkretes Beispiel:

Du willst als Eindringling Root-Rechte auf einem Rechner kriegen (was passiert, wenn Du die hast, dazu muss ich ja wohl nichts sagen …). Dazu reicht Dir auf dem Mac ein Admin-Nutzer, der mit seinem Passwort sudo nutzen kann, was ihm dann die Root-Rechte gibt.

Du musst also das Admin-Passwort herausbekommen. Dass der Nutzer sehr oft von einem Konto mit Admin-Rechten aus arbeitet, reicht ja nicht; du brauchst explizit das Admin-Passwort für sudo.

Nun könntest Du natürlich versuchen, das Passwort über Social Engineering vom Nutzer zu erfragen. Aber wenn auch nicht alle, so werden doch (hoffentlich) viele Nutzer argwöhnisch werden, wenn ein kleines Progrämmchen (App oder Unix-Programm ist egal), von dem sie sich etwas versprechen und das sie sich deshalb von irgendwoher installiert haben, ohne nachvollziehbaren Grund nach einem Admin-Passwort fragt. (Bei Programmen, die das aufgrund ihrer Funktion mit nachvollziehbarem Grund tun, sollte man sich der Quelle doppelt und dreifach sicher sein.)

Ein solcher Ansatz ist also nicht übermäßig erfolgversprechend.

Nun könntest Du aber, falls der Nutzer Homebrew verwendet, aus Deinem Programm dank der laxen Homebrew-Zugriffsrechte ohne jede Nutzerabfrage und vollkommen unbemerkt eine modifizierte sudo-Version dorthin kopieren. Diese modifizierte Version tut alles, was sudo tut (dank Open Source problemlos möglich), funkt aber zusätzlich das eingegebene Admin-Passwort und einige andere Rechnerdaten ins Netz.

Da Homebrew nur funktionieren kann, wenn es in der PATH-Variablen an erster Stelle steht, sodass es statt der jeweiligen Original-macOS-Versionen aufgerufen wird, wird das nächste Mal, wenn der Nutzer sudo im Terminal benutzt, automatisch die Homebrew-Version verwendet. Der Nutzer merkt davon überhaupt nichts (sudo funktioniert wie immer und von dem Kopiervorgang des „harmlosen“ Progrämmchens hat er seinerzeit ebensowenig mitbekommen). Und schwuppdiwupp hast Du sein Admin-Passwort und damit Root-Rechte auf dem Rechner.
Das Problem ist aber eben nicht, was per Homebrew auf Deiner Kiste landet, sondern, was dank der zu laxen Homebrew-Zugriffsrechte Homebrew von dritter, bösartiger Seite später untergeschoben werden kann.
Ist das jetzt so? Das letzte Mal, als ich das probiert habe, reichten die Rechte des Nutzers aus, der Homebrew installiert hat, egal ob Standard- oder Admin-Nutzer.

Aber selbst wenn: wer sich so etwas wie Homebrew ins Haus holt, das Zugriffsrechte verbiegt, nur um dem Nutzer Passwortabfragen zu ersparen, der wird in aller Regel auch selbst in einem Admin-Konto arbeiten, sonst hätte er die Passwortabfragen ja da wieder.

Ja, genau darauf wollte ich hinaus.
Ich denke das alles was man sich installiert heutzutage ein Sicherheitsrisiko ist. Denn wann immer man beim Mac die "root" rechte braucht nistet sich Software ein die gott weis was anstellen kann.
Ich plädiere immer das sich jeder selbst etwas sensibilisiert und prüft was er tut.
Bei Homebrew fühle ich mich sicherer als bei anderer kostenlosen Software da hier eigentlich nur geprüfte Pakete installiert werden.
Und solange ich keine Standard Unix befehle durch andere austausche sollte es auch ziemlich sicher sein.

Das ist überhaupt nicht das Problem. Offenbar wurde das immer noch nicht verstanden.

Das Problem ist, dass Homebrew möglicherweise Schreibrecht auf Betriebssystemordner erteilt, in denen automatisch nach Software gesucht wird. Selbst wenn Du nur Homebrew selbst installierst und es dann niemals zur Installation anderer Programme verwendest, hast Du immer noch eine große Sicherheitslücke im System.

Ein Angreifer könnte auf diese Weise Fremdprogramme ins System schmuggeln, die danach "versehentlich" von privilegierten Teilen des Betriebssystems aufgerufen werden. Über diesen Umweg ist weitere privilege escalation möglich, d.h. wenn es zu so einem Aufruf kommt, kann das Programm seine Befugnisse beliebig ausweiten und das komplette System übernehmen.

Genau das ist aber der Kern des Problems: Stark vereinfacht gesagt gibt eine Homebrew-Installation Jedem das Recht, jeden Unix-Befehl auszutauschen.

Danke Marcel Bresink und auch Weia für die genaueren Erläuterungen.

Was ich mich dabei natürlich frage: Müsste Apple so etwas nicht einfach noch besser 'absichern' können im System?

Es gibt ja schon jetzt spezielle Bereich in macOS, wo man selbst als root nichts mehr dran 'schrauben' kann, vorausgesetzt natürlich, SIP und andere Sicherheitsmechanismen wurden nicht deaktiviert.

Speziell seit dem T2 Security-Chip bzw. auch mit 'Apple Silicon' wurden diesbezüglich die Daumenschrauben weiter angezogen.

Worauf ich hinaus will: Es müsste doch technisch möglich sein, das Apple unser schönes UNIX-basiertes macOS so sicher macht, dass der Austausch 'lebenswichtiger' Systembestandteile wie z.B. sudo einfach gar nicht mehr möglich ist? Also das diese weder 'überschrieben' werden können noch durch veränderte PATH-Angaben 'umgangen' werden?

Ich möchte natürlich kein so extrem abgeschottetes System wie iOS, gerade weil ich unter macOS ja weitaus mehr Freiheiten genieße, ist das nach wie vor meine Produktiv-Basis (und iOS eher zum konsumieren/informieren).

Mal den Gedanken weiter gesponnen: Theoretisch müsste es doch schon ausreichen, wenn das System mittels Prüfsummen die allerwichtigsten binaries des Systems dauerhaft prüft und bei möglicher Manipulation sehr eindeutige Warnmeldungen anzeigt?

So dass die von Euch geschilderten Angriffs-Vektoren entsprechend kleiner werden, zumindest in der Theorie?

Ich finde das Thema hoch-spannend, im Zweifel können wir dafür ja einen extra Thread aufmachen, um das eigentliche Thema 'rsync 3.x.x für M1 als binary ohne Homebrew/MacPorts' nicht zu verwässern?

Nein, auf gar keinen Fall. Ein Administrator muss auch die Freiheit haben, so etwas zuzulassen. Die Möglichkeit, beliebige Software installieren zu können, ist ja gerade das Alleinstellungsmerkmal von macOS gegenüber iPadOS oder iOS.

Das wird für diese Binaries schon seit vielen Jahren gemacht und es handelt sich nicht nur um einfache Prüfsummen, sondern kryptografisch unterschriebene Prüfsummen.

Und trotzdem noch einmal – ein Standard-User ohne Admin-Rechte kann Homebrew weder installieren:


noch kann er Homebrew später (also wenn es durch einen Admin bereits installiert wurde) nutzen, da er als Standard-User weder eine Admin-Shell und erst recht keine root-Shell geöffnet bekommt.

Ja, aber wie schon mehrfach erklärt, geht es ja nicht um die Nutzung von Homebrew.

Aber dann fehlt dem System (aktuell zumindest) ja offensichtlich trotzdem noch ein Feature, um bei Umgehung dieser System-Binaries entsprechende Warnmeldungen auszuspucken?

Und ich befürchte sowieso (und damit bin ich nicht allein), das Apple auf lange Sicht auch macOS weiter verriegeln und verrammeln wird. Als "Notbehelf" dürfen wir Admins dann wahrscheinlich etwas VM-artiges nutzen, was abgeschottet ist vom Rest des eigentlichen Systems (wo dann aber eben auch wie gehabt mehr Änderungen erlaubt sind). Eventuell etwas in Richtung Qubes OS oder so…

Nö. Wasch mich, aber mach mich nicht nass geht nicht. Wenn Du die Flexibilität eines Unix-Systems haben willst, kannst Du nicht mehr absichern, als Unix es von sich aus tut.
Ja, aber wenn Du das auf das gesamte System ausweitest, hast Du eben kein Unix mehr mit seiner unvergleichlichen Flexibilität. Die Sperre des Betriebssystems selbst kann Apple ja gerade durch den hierarchischen Aufbau von Unix vornehmen, der es erlaubt, dass nicht erwünschte Unix-Binaries im System durch erwünschte in den /usr/local-Hierarchien überschrieben werden können.

Und dennoch ist das Ganze durch die Rechtevergabe gut abgesichert. Um es mal völlig undiplomatisch zu sagen: Es wäre gut genug abgesichert, wenn diese Vollidioten von Homebrew die Absicherung nicht aushebeln würden, indem sie die Zugriffsrechte verstellen. Gegen Dummheit ist aber kein Kraut gewachsen. Apple muss da gar nichts verbessern, die Homebrew-Leute müssten es.
Klar geht das, es ist dann nur kein Unix mehr. Nimm doch nur das Thema dieses Threads: in macOS ist ein altes rsync installiert und Tobias will eine neuere Version. Das ist möglich, weil Unix flexibel ist.
Das hast Du dann aber.

Nochmal. Das Problem existiert in macOS solange nicht, solange Du nicht Homebrew (oder was vergleichbar Dämliches) installierst. macOS hat genau die richtige Balance zwischen Sicherheit und Flexibilität, nur Homebrew zerstört die.
Das scheint ja jetzt gelöst.

Das ist keine „Umgehung“, das ist genau so gedacht.

Hallo zusammen,

hoffentlich kurze Zwischenfrage: Wenn ich im Terminal

eingebe, meckert Ventura: "rsync" kann nicht geöffnet werden, da Apple darin nicht nach Schadsoftware suchen kann.

Hat hier jemand noch einen Zaubertrick für mich parat? Was muss ich tun?

Tobias

Das ist eine der Warnmeldungen, bei denen oben angemeckert wurde, dass sie angeblich nicht vorhanden sind.

Wie ist dieses Exemplar von rsync auf das System gekommen? Hast Du es selbst kompiliert oder wurde es Dir über einen unsicheren Kanal (z.B. per Mail) zugeschickt?

Falls letzteres, versuche zunächst ein

Das hilft vielleicht schon.

Hallo Marcel,

dieses Exemplar hatte mir stargator freundlicherweise via Dropbox geliefert. Kopiert habe ich immer, wie von weia empfohlen:

Teilerfolg! Jetzt kommt die gleiche Meldung für "liblz4.1dylib". Muss ich o.g. Befehl einzeln auf alle anwenden oder gibts da eine Abkürzung?

Gruß, Tobias

OK, dann stehen alle mitgelieferten Komponenten unter Quarantäne und dürfen auf diesem Mac nicht ohne Weiteres ausgeführt werden.

Ja.

Das war auch weniger, als ich gedacht habe. Ergebnis:


Danke!

Ende gut, alles gut!

Ich bin zumindest auf der Zielgeraden. Das Synology braucht jetzt noch etwas Zuwendung.

Danke euch allen für die Zeit, die ihr in mich investiert habt.

Tobias

Oh - hast du den Beitrag wieder gelöscht? - ich lasse es trotzdem noch mal hier drin.

"code signature in <0344D5FA-B0F3-3A6D-881F-CC3DAB222296> '/usr/local/lib/libcrypto.1.1.dylib' not valid for use in process: library load disallowed by system policy" erklärt doch schon einiges.
Die dylib ist nicht korrekt signiert. Wenn sie (verzeiht, wenn ich den Thread nicht komplett lese) mit gebaut wurde, dann erhielt sie vermutlich eine Ad-Hoc Signatur, die nach einigen Tagen abläuft (max. 90 Tage). Mittlerweile müssen sogar statische Bibliotheken signiert werden (und die Signaturen werden als extended attributes gespeichert).
Um das zu signieren bräuchtest du ein "Developer ID Application" Zertifikat, für welches man das kostenpflichtige Entwicklerprogramm braucht (die Developer-ID Zertifikate sind relativ lang gültig). Oder brauchst jemanden, der es für dich baut und signiert. Zuletzt kannst du natürlich regelmäßig neu bauen oder wenigstens die Signatur erneuern.

Hi ssh,

ja, weil ich nicht richtig geguckt hatte -- sorry. Du warst zu schnell. Der Fehler in der Konsole war veraltet. Das Problem ist inzwischen ja behoben. Rsync läuft.

Ich habe aber noch ein weiteres Problem. Der Mini stürzt aktuell 1× pro Tag ab. Der ist dann auch nicht per ping erreichbar. Die Ursache für das Problem ist mir noch völlig unklar. Ich hatte in der Konsole geguckt und war über die ursprünglich gepostete Fehlermeldung gestolpert. Die tauchte aber am 9.11.2022 letztmalig auf.

Den Mini halte ich per Amphetamine wach. Schlafen sollte der eigentlich nicht. Ausserdem hängt noch ein Raid (Promise Pegasus2 R6) über einen Adapter (Thunderbolt 3 (USB‑C) auf Thunderbolt 2 Adapter) und ein Synology am Ethernet-Port.

Ich hab keine Ahnung, wer oder was die Abstürze verursacht.

Tobias

Nachtrag/Nachfrage:
Ich habe gestern in einem anderen Thread () geschrieben, dass die Telekom-Leitung ein dickeres Problem hatte. Da kam kaum noch was durch ...

Der Techniker hat das Problem behoben und seitdem gab es keinen Absturz vom Mac mini mehr. Ich krieg den Zusammenhang von Problem mit Internetleitung und Rechnerabsturz nicht zusammen. Ist das Zufall? Ich mag es eigentlich lieber, wenn ich das Problem erkenne und behebe. Kann ich -- ausser durch abwarten und beobachten -- rausfinden, was vorgestern noch zu Abstürzen geführt hat? Ich würde den Übeltäter gerne kennen.

Was genau meinst Du denn mit Absturz?

• der Mac startet von selbst neu
• der Mac schaltet sich von selbst aus
• der Bildschirm wird schwarz, aber der Mac läuft noch
• die GUI friert ein

Gute Frage! Der Mini ist zunächst über Apple Remote Desktop nicht mehr erreichbar. Im Büro erwartet mich dann ein laufender Mini. Jedenfalls sieht alles normal aus, wenn ich den Monitor einschalte. Weder CarbonCopyCloner noch das Hyperbackup vom Synology haben ihren Dienst verrichtet. Ich mache dann einen Neustart und dann funktioniert alles wieder für etwa 1 Tag.
nein, denke nichtneinkönnte theoretisch sein. Den Bildschirm schalte ich aber selber aus. Schlafen sollte der allerdings nicht (Amphetamine () soll den Mini wach halten)nein

PS. Seit gestern läufts aber. Lediglich das Hyperbackup wurde heute Nacht nicht ausgeführt. Das konnte ich heute Morgen aber manuell anschieben.

Naja, das ist trivial, wenn die Leitung klemmt. Und auch der Rest ist dann leicht erklärbar. Wenn Du Remote Desktop laufen hast, aber die Netzwerkverbindung klemmt, kann im Prinzip alles passieren – schließlich hast Du ein Programm am Laufen, das Tief in das OS eingreift, aber selbst wegen Leitungsstörungen am Durchdrehen ist. Da würde mich überhaupt nichts wundern.

Abwarten, ob es jetzt behoben ist. Überraschend wäre es jedenfalls absolut nicht, wenn das an Remote Desktop plus schlechter Leitung lag.

Interessant ist nur, dass ich dann auch im lokalen Netz nicht per Apple Remote Desktop zugreifen kann. Aber wenn das mit der schlechten Telekom-Leitung zu erklären ist, soll mir das recht sein.

Ich behalte das mal im Auge. Danke.

Habe vor Jahren mal Homebrew installiert. Gibt's denn eine für Laien umsetzbare Möglichkeit, das Scheunentor wieder zu schließen, d.h. alle relevanten Zugriffsrechte wieder zu reparieren? Ich nehme an, dass eine Deinstallation von Homebrew das nicht tut...

Sicher gibt’s die, man muss „nur“ wissen, waswiewo installiert wurde. Gibt’s da sowas wie eine Installatations-Logdatei?

Wo ist denn Homebrew grundsätzlich bei Dir installiert, in /usr/local/ oder in /opt/? Es gibt, was ich mitbekommen habe, ja beide Varianten.
Gibt es eine „offizielle“ Art, Homebrew zu deinstallieren, vielleicht sogar ein Deinstallationsprogramm? Dann wäre das zumindest denkbar.

Den gibt es hier:
So lautet zumindest die offizielle Deinstallation (wenn man dem Script vertraut).

/usr/local/ ist Intel-Mac und /opt/homebrew/ ist Apple-Chips

Ich weiß aber nicht, was für einen Mac ruphi hat. Wahrscheinlich Intel, da die Installation schon länger her ist.

Also direkt /usr/local/ oder sowas wie /usr/local/homebrew/?

Ich meine /usr/local/
Die Reparatur der Zugriffsrechte wäre dann
Was bei Macs mit Apple-Chips nicht nötig ist.

PS. Ich finde homebrew super ...
korrigiert!

Bei mir wäre es die Intel-Variante /usr/local/, und wie marm schreibt gibt es den offiziellen Uninstaller.

---EDIT: War zu langsam, Rest gerne ignorieren ---
Aber einfach nur die installierten Dateien zu entfernen, ohne die Zugriffsrechte zu reparieren, würde mir ja keine Sicherheit bringen, sondern nur weniger Funktionalität bescheren.

D.h. die Frage ist: Werden durch den Uninstaller auch die Zugriffsrechte wiederhergestellt?
Alternativ: Gibt es eine Liste der sicherheitskritischen Zugriffsrechte-Veränderungen durch Homebrew, sodass ich sie händisch kontrollieren kann?
Und wenn ja: Sprechen wir hier von einer Handvoll oder eher mehreren Hundert Verzeichnissen ...

Wieso $(whoami)? Das doch gerade nicht, das ist ja die Sicherheitslücke!

Alles in /usr/local/ (bis auf spezielle Ausnahmen, die ruphi vermutlich nicht installiert haben wird) muss root:wheel sein.

Nein, eben nicht. Ich hatte das schon gepostet, aber irgendwie ging der Beitrag nicht durch?? Ich war dem Link von marm nachgegangen.

Also, Kurzform: Der Installer verändert jede Menge Zugriffsrechte, der Uninstaller keine.
Von einem.

Im Prinzip müssten
und sicherheitshalber noch
(nimmt der Gruppe und dem Rest die Schreibrechte)
reichen.

Damit wird halt alles, was sich in /usr/local befindet, so umgestellt, nicht nur das Homebrew-Zeugs. Aber im Regelfall stimmt das auch für alles (d.h. der Rest sollte eh schon so sein), solange ruphi da nicht etwas ganz Spezielles installiert hat.

Warum nicht?

Hab es durchgeführt; besten Dank euch beiden!

Nun, /opt/homebrew/ wird gelöscht und die Rechteänderung durch homebrew von /usr/local/ müsste auf einem M-Mac doch eigentlich unnötig sein.

Ach so, ja, fast. Es gibt auch noch ein paar andere Unix-Installationen, die /opt nutzen, und in so einem Fall darf man natürlich nur /opt/homebrew löschen, aber nicht /opt. Und dann muss man zumindest für /opt (aber nur den Ordner selbst) die korrekten Zugriffsrechte ebenfalls wiederherstellen.
Ja, das ist klar.

ooops, Multitasking ist wirklich nicht mein Ding. Hab in der Eile nicht auf die Ausgabe geachtet und erst jetzt das Terminalfenster nochmal gecheckt: Hat wohl auch ziemlich lange gebraucht bis das kam. Was ist da los?

Kein sudo?

Falls doch sudo: dann schlägt vielleicht SIP zu und markiert diese Hierarchie als nicht veränderbar (wobei chown dann aber auch nicht gehen dürfte).

Oder hast Du von marm kopiert und nicht von mir?

Meine Eingabe war:
Dann Passwort
Dann einige Zeit hörbares Arbeiten am MacBook
Dann obige Meldung:

Wenn ich jetzt die SIP auf den Plan gerufen habe... what now?

Die zweite Sache, , lief problemlos durch.

Kurz SIP ausschalten, chown und chmod, SIP wieder einschalten.

Allerdings frage ich mich in diesem Falle, wie bzw. ob Homebrew die Zugriffsrechte überhaupt verbiegen konnte?

Was sagt denn
?

Ich denke eher, es liegt daran, dass Homebrew nicht alle Ordner in /usr/local verändert. Wenn du nun rekursiv bei allen Ordnern die Rechte ändern möchtest, betrifft das auch die, welche schon "root:wheel" als Berechtigung haben. An dieser Stelle kommt dann "Operation not permitted"

Das wäre:
Ist dann schon alles gut, alles gilt die "root wheel"-Angabe in dieser Übersicht auch rekursiv?

Das weiß ich noch nicht, das wäre eine Riesenliste, das anzuzeigen.

Ich habe eins übersehen; bitte nochmal, aber

Das spuckt aus:

OK, die zusätzliche Option -a sorgt dafür, dass auch das Verzeichnis /usr/local selbst angezeigt wird (als Punkt) und in der Tat ist alles root:wheel.

Es könnte also sein, dass SIP Dich vor den Untaten von Homebrew schlicht bewahrt hat. 🤣 Denkbar wäre das dann, wenn Du nie was aktualisiert hast – denn der Homebrew-Installer selbst muss ja mit root-Rechten ausgeführt werden und kann also in /usr/local, wie es ist, schreiben, ohne irgendwelche Rechte zu verstellen.

Jetzt machen wir die Probe aufs Exempel; der folgende Befehl listet Dir alle Dateien und Ordner innerhalb von /usr/local auf, die nicht root:wheel gehören, so es welche gibt:
Was kommt da raus?

Spannend
Ausgabe lautet jetzt: