Hallo an die Biertrinker!

Ich gedenke, mich mit homebrew auseinanderzusetzen. Das dürften einige von Euch ja schon hinter sich haben. Ich hab da ein paar Fragen:

1) Kann ich homebrew "ohne weiteres" auf mein MBP M1 installieren - /opt ist vorhanden, aber leer, wohl, da ich einen Installationsversuch abgebrochen habe -, so dass es aller Voraussicht nach 1) keine Probleme verursacht und 2) ggf. rückstandsfrei zu deinstallieren ist.
2) Ginge das auch mit einem MBP 2020 Intel, wenn im /usr... schon einiges installiert ist.
3) Wenn homebrew und auch php dann installiert ist, wie bringe ich apache bei, dass dann die homebrew-Version von php zu verwenden ist.
4) Homebrew meint, man "benötige" mind. Mojave für optimalen support. Ginge eine Installation auch unter Sierra? Hat da wer Erfahrung?
5) Gibt es irgendwo eine schöne Anleitung, wie php unter homebrew zu installieren und lauffähig zu machen ist. Auf der homebrew-Seite selbst habe ich schon gestöbert, jedoch nicht "das richtige" gefunden.

1) Ja
2) Ja (wobei ich nie gecheckt habe, ob nicht doch Rückstände wie Nutzdaten oder Configs übrig bleiben)
2) Kommt drauf an, was du erwartest. Homebrew nutzt ja eigene Verzeichnisse für die Binaries. Evtl. ändert sich was durch die neuen Suchpfade, wenn du nachinstallierte Kommandos in Skripten nicht mit absolutem Pfad ansprichst.
3) Wenn du PHP als Modul nutzt, kannst du `LoadModule php5_module /path/to/libphp5.so` in der Config angeben
4) Müsste gehen, aber vieles ist eben nicht getestet. Keine Ahnung, ob es bei MacPorts besser aussieht. Zumindest bieten sie alte Installer an.
5) Was soll "lauffähig" und "das richtige" bedeuten? Nach `brew install php` ist php startklar. Wenn's um einen lokalen Webserver geht, könntest du dir auch Handarbeit sparen und zum Beispiel MAMP, VirtualHostsX oder XAMPP verwenden.

Ich habe homebrew hier auf einigen Macs laufen, vom 2013er MBP bis zum 2021 M1 mini. Klappt hervorragend.
homebrew läuft auch auf älteren Systemen, dafür gibt es entsprechende "bottles". Es kann aber sein, dass einige Pakete nicht oder nur in einer älteren Version für frühere macOS Versionen verfügbar sind.
Normalerweise setzt homebrew während einer Installation symbolische Links dorthin, wo man das Paket unter Linux suchen würde. Klappt das nicht (oder würde es bestehendes überschreiben) erscheint eine entsprechende Meldung. Zu beachten ist, dass die Pfad unter M1 eben an anderer Stelle liegen als bei Intel - solltest du statische Pfade verwenden und Module zu konfigurieren musst du da aufpassen und ggf. anpassen.

Da ich selbst nichts für PHP entwickle, kann ich dir nicht sagen, wo du eine solche Anleitung finden kannst. Aber ich bin mir sicher, dass du mit der Suchmaschine deiner Wahl fündig wirst.
Wenn du es ausreichend getrennt möchtest und dafür auch ein wenig mehr Aufwand in Kauf nehmen würdest, dann kannst du auch mit Docker-Images arbeiten. Da findest du sicher welche, die bereits gut konfiguriert sind und die du nur noch um die Sourcen deines PHP-Projektes ergänzen musst. Auch das Deployment kann da deutlich einfacher werden.

Danke Euch Beiden so weit!

Eigentlich will ich zunächst mal nichts anderes, als daß ich auf einem Sierra-server letztendlich mind. php7 ans laufen bekomme. Der apache auf eben diesen Rechner serviert das dokuwiki, welches ab der nächsten Version nicht mehr unter 5.6.30 läuft, sondern php7 voraussetzt.

@Nebula:
3) Trage ich das dann in der /private/etc/apache2/httpd.conf ein, in der ich bislang bzgl. des bordeigenen apache herumpfusche ?
5) Ja, es geht um einen lokalen webserver. Nach meinen Informationen bleibt aber der apache in macOS zunächst mal erhalten. Jetzt geht es erst um php7, später dann um php-Installationen überhaupt. Ich möchte soweit möglich "alles" mit Bordmitteln machen.

Zur Zeit installiere ich testweise homebrew auf dem MBP Intel 2020:
$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
$ brew install php

Mal abwarten, ob das alles so klappt.

Lies Dir doch mal diesen kleinen Artikel zum Thema Sicherheit bei Homebrew durch...
Sofern sich an der Installationsroutine von Homebrew nichts geändert hat, sollte man vielleicht doch eher MacPorts benutzen.

Gruß
chuby

Zum einen ist der Artikel sehr dünn.

Zum zweiten ist die /usr/local-Hierarchie kein "Systemverzeichnis" im eigentlichen Sinne - im Gegenteil ist das standardmäßig nicht mal in den Systempfaden enthalten. Von Aufweichung der Sicherheit kann also kaum eine Rede sein - das muß schon der Benutzer selbst machen, der (hoffentlich) weiß, was er tut. Das ist bei macports aber nicht anders.

Und zum dritten sollte jemand, der ein Kommando wie
ausführt (auch wenn das zugegebenermaßen so in der Homebrew-Doku steht - allerdings mit einem Warnhinweis) zum Thema "Systemsicherheit" lieber die Füße stillhalten.

Wie kann jemand ohne HOMEBREW leben...

Und inwieweit dient das als Argument gegen den verlinkten Text?
Hast du überlesen, daß MacMark das zitiert und sogar warnrot markiert hat?

Naja, jein. Es ist ein Standardverzeichnis im System (wenn "Systemverzeichnis" das bedeuten soll), aber eben genau jenes, das für eigene zusätzliche Installationen gedacht ist.
Das war mal so; mittlerweile ist es das meines Wissens aber (kann mich auch irren, weil es bei mir natürlich seit eh und je da ist).
Aber hallo! Wenn ein Script, das den Eigentümer der /usr/local/Hierarchie von root:wheel auf realuser:admin umstellt, keine Sicherheitsaufweichung ist, dann weiß ich nicht, was eine wäre.
Aber das ist doch gerade der Punkt, dass Homebrew samt Doku lauter Mist anrichten!?! Das ist doch gerade keine Empfehlung des Artikelautors …

Indem er genug Hirn besitzt, die Unix-Utilities, die er braucht, selbst zu kompilieren und zu installieren, statt sich auf das zu verlassen, was andere sinnvoll finden?

Da hast Du vorher MacPorts installiert und da wurde dann der Ordner /opt/ von MacPorts angelegt …

Danke, dass ihr nochmal den Sicherheitsaspekt rausgekramt habt. Ich dachte, das sei mittlerweile Geschichte, aber hier malt jemand ein mögliches Szenario aus:

Zusammengefasst: Durch das Umbiegen der Rechte sei es ein Leichtes, ein Fake-sudo einzurichten, dass dann zum Beispiel das Admin-Passwort abfischt.

Hier ergeben sich für mich einige Fragen.

1. Müsste ein Angreifer überhaupt auf Homebrew hoffen und könnte er nicht auch mit alias ein sudo abfangen?
2. Nutze ich Homebrew nur via Admin-Account und arbeitet sonst mit einem anderen Account, dürften die umgebogenen Rechte ja nicht dazu führen, dass sich dort ungefragt etwas installiert
3. Malware kommt ja oft in Huckepack mit anderen Sachen, für die man evtl. bereitwillig sudo behelligt oder das Adminkennwort eingibt. Insofern bieten die Original-Rechte doch kaum mehr Schutz
4. Ist es nicht gerade ein Sicherheitsgewinn, dass vieles bei Homebrew ohne sudo klappt und Schadsoftware dann auch geringere Rechte hat, wenn sie über eine Homebrew-Installation mitkommt?
5. Homebrew selbst sagen, dass sie Sandboxing nutzen, was nur ohne sudo funktioniert. Weiß jemand was genau damit gemeint ist? Laufen alle installierten Tools in ihrer Sandbox? Dann müsste ich doch Probleme haben, mit nachinstallierten Tools auf bestimmte Pfade zuzugreifen oder von macOS um Erlaubnis gebeten werden. Über so ein Verhalten bin ich noch nicht gestolpert, außer beim Terminal selbst.

Und das völlig zu Recht.

Ich mochte Homebrew noch nie, aber dass es die Zugriffsrechte der /usr/local/-Hierarchie ändert (was ich noch nicht wusste), macht mich fassungslos.

Um es ganz unzweideutig zu sagen:

1. Über einen Package Manager, der die Zugriffsrechte der /usr/local/-Hierarchie auf Joe User abändert, braucht man keine Sekunde weiter nachzudenken; der gehört sofort auf den Müll.

2. Die Autoren eines Package Managers, der die Zugriffsrechte der /usr/local/-Hierarchie auf Joe User abändert, haben ihre Inkompetenz derart grell unter Beweis gestellt, dass ich ihnen auch sonst keinen Millimeter mehr in irgendetwas über den Weg trauen würde.

Fort damit!
Mit was für einem Alias? Unix-Programme verstehen Mac-Aliases überhaupt nicht, und falls Du einen Softlink meinst, verstehe ich ebenfalls nicht, was Du dir da vorstellst. Der Softlink, der meinetwegen auf irgendwas außerhalb von /usr/local/ verweist, müsste ja seinerseits erst in /usr/local/ installiert werden; wer das kann, kann dann aber ja auch gleich das Schadprogramm selbst in /usr/local/ installieren.
admin:admin zu werden ist leichter, als root:wheel zu werden; insofern ist der Schutz zwar besser, aber immer noch schlechter als mit root. Außerdem müsstest Du dann nur wegen diesem Homebrew-Müll Deinen Aufenthalt im Admin-Konto so knapp wie möglich halten; so ist das aber gar nicht gedacht. Und außerdem ist in Systemeinstellungen → Benutzer rasch mal ein Haken bei Der Benutzer darf diesen Computer verwalten gesetzt.
Wenn Du das bereitwillig tust, bist Du das Sicherheitsrisiko. Gegen Brain 0.9 ist überhaupt gar keine Sicherheitsschranke gefeit.
Das ist ein absurdes Argument. Original-Rechte bieten nach wie vor Schutz vor böswilligen Programmen, nur vor leichtsinnigen Nutzern nicht. Wenn dieser Unterschied bei Dir „kaum“ merklich ist, bist Du das Sicherheitsrisiko.
Nein. Die Rechte, die ein Programm während seiner Ausführung hat, haben in der Regel (es gibt Ausnahmen) nichts mit den Rechten zu tun, mit denen sie installiert wurden. Die Datei-Zugriffsrechte der Programme schützen davor, dass die Programmdateien selbst verändert werden.
Falls Du dich damit auf den FAQ-eintrag Why does Homebrew say sudo is bad? beziehst: Da bleibt völlig unklar, was sie meinen. Aber der ganze Eintrag ist wirr und strotzt vor Unverständnis. (Ja, man sollte root zum Eigentümer von /Applications/TextMate.app machen und nein, selbst wenn man das nicht tut, heißt das noch lange nicht, dass sich das auch auf Unix-Utilities übertragen lässt, denn die können ihrerseits unbemerkt aus Skripten aufgerufen werden; würde ein Skript „heimlich“ eine Cocoa-Applikation mit GUI starten, würde das mehr als auffallen.)

Dem Faß den Boden ins Gesicht schlägt aber der Satz If you need to run Homebrew in a multi-user environment, consider creating a separate user account especially for use of Homebrew. Will da jemand die Unix-Architektur neu erfinden? Und wer nutzt ein Unix schon als Multi-User-System? Meine Güte, was für … ach, ich nutze lieber keine Worte.

Das ist ja alles unfassbar übel.

Jau, aber mittlerweile ist ja alles auf HomeBrew migriert. Ich hab da:

Danke an euch beide für eure Hinweise und Kommentare. Ich freue mich jedes mal wenn ich hier wieder etwas lernen kann.
Mit meinem zaghaften Hinweis auf den Artikel von MacMark wollte ich @virk eigentlich nur anregen sich auch mit dem Sicherheitsaspekt einer Homebrew Installation zu befassen. Die -3 die ich mir dafür von einigen Spezialisten eingefangen habe nehme ich dafür gern in Kauf...verstehen kann ich sie nicht.

Bei mir jedenfalls läuft MacPorts.

Danke und Gruß
chuby

ich schreibe auch mal was.

Homebrew installieren ist super easy und auch ziemlich sinnvoll wenn man mal etwas anderes machen will damit.

Homebrew ist M1 kompatibel und sucht auch "apps" für die Architektur wenn sie vorhanden ist, Dank Rosetta2 aber auch kein Problem wenn es Intel ist.

warum Du negative Bewertung bekommen hast für die Frage ist mir ein Rätsel.

Ich nutze Homebrew für openCBM und meine App dafür und es funktioniert sehr gut.

Diesen Eindruck erweckt auch die Homepage des Projekts: "Alles easy" sozusagen. Dabei solle man hippes Gequatschte (ist nicht auf Dich bezogen) nicht mit Kompetenz oder Verantwortungsbewusstsein gleichsetzen. Schon der auf der Homepage des Projekts prominent angeführte Terminal-Befehl zur Installation von homebrew:
" "
... funktioniert nämlich nicht (auch nicht mit sudo), wenn man ihn von einem normalen User-Account aus ausführt:
==> Checking for `sudo` access (which may request your password).
Sorry, user <User> may not run sudo on <Computer>.

Schon peinlich, wenn der erste Befehl mit dem man in Kontakt kommt, so nicht funktioniert und die Problematik auch nicht - oder zumindest nicht prominent angesprochen wird. Weia hatte das ja in seinem Beitrag ausführlicher angesprochen.
Bei mir hatte die Installation dann eine etwa zweistündige Terminal-Orgie nach sich gezogen, um homebrew in einem normalen Nutzeraccount nutzen zu können. Die homebrew-Macher scheinen offensichtlich ganz selbstverständlich vorauszusetzen, dass man standardmäßig mit Admin-Rechten unterwegs ist. Macht das Kraut dann aber auch nicht mehr fett.

Nehme das mal bitte nicht persönlich, ich kenne ja weder Dich noch Dein System aber (und da muss ein aber sein)
Ich habe Homebrew schon auf mehreren Rechnern installiert. niemals Sudo niemals etwas anderes.
Wenn man aber nicht vernünftig liest und einfach nur blind einen Link kopiert und denkt das "HOMEBREW" einfach so funktioniert dann liegt der Fehler unmittelbar vor dem Bildschirm.

Ohne Xcode und dessen Terminal-Tools funktioniert das nun mal nicht. Steht so aber auch in der Anleitung.

Thema Sicherheit. Wie bei allem MUSS man sich im Klaren sein was man tut. Installiert werden auf älteren Systemen zwar im usr Folder aber dieser ist nicht das System und kann auch nicht einfach auf das System zugreifen darum ja die Xcode Installation.
in der neusten Version wird es im opt Folder installiert. Das geht alles ohne die Sicherheit des Systems schwächen zu müssen. Kein Sudo kein gehacke.

Also die von Dir wohl gemeinten DAUs, die ohne Sachverstand etwas installieren sind nur eine Seite der Medaille. Ich habe jedoch von der anderen Seite gesprochen: auch komplexe Software darf ruhig einfach funktionieren. Kann es sein, dass bei Dir die homebrew-Standardinstallation immer geklappt hat, weil Du eben überall als Admin unterwegs bist? Nicht persönlich nehmen Xcode ist bei mir übrigens installiert

Du hast offenkundig das Problem überhaupt nicht verstanden.

Wenn der Eigentümer von /usr/local oder jetzt /opt der reale Nutzer ist (also Du), dann kann alles, was Du Dir während Deiner normalen (= nicht-Admin-)Tätigkeiten an Deinem Mac möglicherweise einfängst, problemlos Veränderungen in /usr/local oder jetzt /opt vornehmen, die ab da dauerhaft alle Tätigkeiten im Terminal, alle Skripte, die laufen (auch die im Hintergrund), potentiell beeinflussen können. Damit hast Du dank Homebrew eine der größten denkbaren Sicherheitslücken auf Deinem System, die man sich überhaupt vorstellen kann.

ohne die Sicherheit des Systems schwächen zu müssen – von wegen! Das ist eine erhebliche Schwächung der Systemsicherheit.

Und sudo ist kein „Gehacke“, sondern das Gegenteil davon: es ist der Schlüssel, der es ermöglicht, dass Du Deine Installation schützt, aber selbst – dank Schlüssel – noch bearbeiten kannst, wenn Du möchtest.

Anders ausgedrückt: Dank sudo kannst Du Deine Wohnungstüre abschließen, kommst selbst aber mit Deinem sudo-Schlüssel immer noch in Deine Wohnung hinein.

Ohne sudo hast Du keinen Wohnungsschlüssel, musst also Deine Wohnungstüre sperrangelweit offenstehen lassen, damit Du selbst Deine Wohnung noch betreten kannst. Das ist die Homebrew-Variante. Klar geht da alles reibungslos – es ist viel einfacher, direkt in die Wohnung zu gehen, ohne erst den Wohnungsschlüssel rausfummeln und aufschließen zu müssen. Wenn da nur nicht dieses klitzekleine Sicherheitsproblem wäre …
Dann nimm Dir das bitte auch zu Herzen.

Ich hab´mich eben entschlossen, homebrew wieder zu deinstallieren.
Sollte ja mit
funktionieren. Hat jemand Erfahrung, ob das aktuelle Script, das curl da herunterlädt, keinen Schaden anrichtet? (Hab keine Ahnung, wie häufig das Skript geändert wird).

Ob da Schaden angerichtet wird kann ich so leider nicht ohne genaue Analyse sagen.

Das Skript uninstall.sh entfernt Homebrew nicht vollständig!
In https://raw.githubusercontent.com/Homebrew/install/master/install.sh wird unter anderem mit chown (Benutzer / Gruppen ändern), chgrp (Gruppen ändern) und chmod (Berechtigungen für Benutzer / Gruppe / Andere) gearbeitet. Diese Anweisungen finden sich so nicht im Uninstaller.

Wenn Homebrew also in /usr/local installiert wurde bleiben dessen Rechte auch nach Deinstallation verändert. Man wird Homebrew, anders als MacPorts, nur äußerst schwer wieder los.

Meines Ermessens nach sollte eine saubere Neuinstallation durchgeführt werden um die Rechte wieder in den Soll-Zustand zu versetzen. Vielleicht gibt es auch Werkzeuge um die Rechte zu reparieren - manuell geht's auf jeden Fall auch. Aber da sollte man dann wissen was man tut.

Danke für die Infos.

Es gab doch zumindest früher in macOS irgendwo die Möglichkeit, ein Reparieren der Rechte (Repair Permissions) anzustoßen; ich erinnere aber nicht mehr, wo. Diese Funktion wurde von Unkundigen laufend als Allheilmittel in allen möglichen und unmöglichen Problemzusammenhängen vorgeschlagen, wo von der Sache her vollkommen unklar war, warum das helfen sollte. Hier wäre aber tatsächlich mal ein Einsatzzweck für genau diese Funktion. Weiß jemand, ob und wo es die noch gibt? (Ich selbst bin heute nicht am Mac und kann nicht nachsehen.)

Das scheint in neueren OS-Versionen seitens Apple nicht mehr vorgesehen zu sein. Lediglich die Zugriffsrechte für das Verzeichnis des angemeldeten Nutzers scheinen reparierbar zu sein. Apple legt bei Problemen nahe, das System neu zu installieren:

Ein sehr fachkundig geschriebener Artikel hierzu von Howard Oakley, dem Macher u.a. von SilentKnight:

Lade es halt runter, lies und versteh es und führe bei Gefallen dann die lokale Kopie aus. Dann kann dir egal sein, wie oft es verändert wird. Und das Erlesen von Skripten, die man ausführen will, ist eine Tugend, die man sich gerne aneignen kann.

Das Rechtereparieren im FPDP war schon immer für Dateien vorgesehen, die mit dem systemeigenen Installer installiert worden waren, nicht für Benutzerdaten (woher soll das System wissen, was der Benutzer da haben will?). Und es war keine "Reparatur" sondern einfach ein Zurücksetzen auf den ursprünglichen Zustand (der in irgendeiner Datei gespeichert war).
Da seit BS das System versiegelt ist, ist eine derartige Reparatur für Systemdateien sowieso nicht mehr machbar. Und wenn sich dennoch etwas verstellt haben sollte, muß man mit ein einem größeren Problem rechnen.

Das stimmt, aber /usr/local/ sind ja nun gerade keine Benutzerdaten im eigentlichen Sinne. Ich würde vermuten, dass das „Reparieren der Zugriffsrechte“ da zumindest alles auf den Eigentümer root:wheel gesetzt und die Schreibbarkeit für others entfernt hätte. Aber klar, das kann man natürlich auch einfach selbst machen:

Vielleicht liest Du dich noch einmal ein wenig schlau über die Unix Struktur im allgemeinen.

Sicherlich und das habe ich auch geschrieben, muss man sich im Klaren sein was man sich in das Haus lässt.
ABER und das ist das entscheidende, wenn ich es nicht zulasse kann nichts an meinem System verändert werden. Auch nicht im Hintergrund. System und User sind im OS klar voneinander getrennt, aktuell sogar durch eine "partition".

Die Sicherheit die Du ansprichst ist nur dann gewährleistet wenn man den Rechner komplett aus hat.

Um das abzukürzen denn ich kann mir vorstellen was kommen wird, ich schätze Deinen Inhalt den Du hier postest und ich will Dir auch keinerlei Kompetenzen absprechen allerdings unterscheiden sich unsere Ansichten extrem voneinander so das ich wenig Sinn in einer Diskussion sehe. Der Threatersteller soll sich seine eigene Meinung bilden können und da sind viele unterschiedliche Sichtweisen sehr hilfreich.

Ich habe Kurse rund um das macOS besucht und mir so ein solides Grundwissen über die Sicherheit angeeignet. Wie ich schon schrieb rede ich von der Sicherheit des Systems. Man muss immer wissen was man sich da installiert.

Nein. Ganz normaler User ohne extra Einstellungen. Xcode alleine hilft nicht. Es geht um die Command Line Tools (CLT) for Xcode


Die werden nicht mit der normalen Xcode Installationen installiert. Und das ist auch schon der ganze Trick.
Darum finde ich Homebrew ja so gut. Kein SU oder Root oder sonst etwas nötig.

Aber genau das macht Homebrew: Es (und damit Du, wenn Du es installierst) lässt zu, dass etwas an Deinem System verändert wird, was nicht ohne Deine explizite Einwilligung verändert werden dürfte!

Veränderung am System heißt doch nicht zwangsweise, etwas in den Ordner /System oder die Unix-Hierarchien außer /usr/local bzw. /opt zu schreiben. Die sind sauber getrennt und mittlerweile nicht einmal mehr schreibbar, das ist sicher richtig.

Aber darauf kommt es überhaupt nicht an, denn die Systemdateien interagieren doch mit dem Rest.

Einfaches Beispiel:

• Praktisch jeder, der mit der Kommandozeile in Terminal arbeitet, benutzt häufig ls zum Auflisten eines Ordnerinhalts.
• Jetzt nimm an, Du arbeitest als Nutzer auf Deinem Mac und fängst Dir irgendetwas ein, durch einen Trojaner, eine Drive-by-Sicherheitslücke in Safari, Social Engineering, was auch immer. Das spielt letztlich keinerlei Rolle, denn bestünde überhaupt keine Gefahr, dass Du dir etwas einfängst, gäbe es auch keine Sicherheitsprobleme bzw. die Systemsicherheit wäre egal.
• Da Du Homebrew installiert hast, kann der eingefangene Schädling problemlos unbemerkt in /usr/local bzw. /opt schreiben, weil Homebrew die dortigen Schreibrechte auf Dich als Eigentümer umgestellt hat.
• Der Schädling legt nun in /usr/local/bin bzw. /opt/bin ein Unix-Programm ab, das den Namen ls trägt, de facto aber nicht den Inhalt der ihm als Argumente übergebenen Ordner auflistet, sondern stattdessen diese Ordner samt Inhalt löscht.
• Von all dem bekommst Du nicht das Geringste mit, da Dich aufgrund der verstellten Zugriffsrechte ja kein sudo mehr nach Deinem Admin-Passwort fragt.
• Wenn Du nun das nächste Mal arglos ls ~/meinOrdnerMitUnersetzlichenDaten aufrufst, wird, da /usr/local/bin bzw. /opt/bin an erster Stelle in der Aufrufhierarchie der Terminal-Shell stehen, das vom Schädling installierte Programm statt /bin/ls aufgerufen und meinOrdnerMitUnersetzlichenDaten gelöscht, ehe Du dich versiehst.

/bin/ls in dem sauber getrennten, nicht schreibbaren Systemteil von macOS muss also gar nicht verändert werden, um maximalen Schaden anzurichten, wenn Homebrew installiert ist. Das Verändern der Zugriffsrechte, das Homebrew vornimmt, ist vollkommen unverantwortlich!
Aber es geht hier nicht um Ansichten. Es geht um Fakten und nur eine von zwei konkurrierenden Aussagen über diese Fakten kann korrekt sein.

Da wäre ich jetzt nicht darauf gekommen. Danke für diesen erleuchtenden Hinweis.

Ich gehe jetzt mal nicht davon aus das die HB Community es zulässt das Pakete die Systemeigenen Tools wie "ls" austauscht. (Es gibt ja keinen Grund) Doch Du sprichst wieder den Fall an der zwar nicht unmöglich ist aber nicht in der Schuld der HB-Com liegt.
Es ist wie bei 90% der "Virus"-Fälle auf dem Mac. Es gehört immer das zutun des Nutzers dazu diese Schadsoftware auch zu installieren.
Wenn ich im Auto ertrinke MUSS ich zuerst aktiv in das Wasser gefahren sein.

Es ist ein Fall den Du da beschreibst der zwar möglich ist doch darum eine ganze Sache zu verteufeln?
Und das meine ich mit Ansichten denn ich bin der Ansicht das wenn man sich nur ein wenig schlau macht man dank der gesamten Architektur sehr sicher Tools installieren kann die es nicht in den App-Store schaffen.

Ich verstehe ja den Gedanken dahinter, aber ein wenig dreht sich hier die Argumentation im Kreis.

Du setzt eine Sicherheitslücke im System/Safari voraus um aufzuzeigen, dass Homebrew eine Sicherheitslücke darstellt, die es nicht gäbe, wenn Homebrew nicht installiert wäre.
Ich setze Safari deshalb mit "System" gleich, da Pegasus uns ja gelehrt hat, dass auf den Systemen viele Frameworks ineinandergreifen und weitreichende Folgen für das gesamte System haben. Da Apples Betriebssysteme nun auch nicht als kugelsicher gelten, kann man davon ausgehen, dass Angreifer sich nicht auf die Installation von Homebrew verlassen, sondern Wege finden, die überall funktionieren.

Wie gesagt, ich verstehe deinen Ansatz. Ja, Homebrew öffnet das System ein wenig. Und ja, für "gezielte Angriffe" macht es Homebrew etwas leichter. Ich glaube aber auch, dass du das Problem etwas zu genau nimmst, denn wie schon oben geschrieben, setzt du ja schon eine Reihe von Fehlern in anderer Software oder bei Benutzern voraus um auf die Gefahren von Homebrew hinzuweisen.

Homebrew tauscht generell keine vorhandenen Versionen aus sondern weist bei der Installation darauf hin, dass du explizit die von Homebrew installierte Version aktivieren musst, wenn du sie verwenden willst.

@Weia: Es würde helfen, sich mit der Software auszukennen, die mann versucht schlechtzureden.

Fakt ist doch nun mal, das die Homebrower die Rechte „vom System“ vorgegebenen Ordnern änder damit „alles einfacher“ ist und beim deinstallieren das nicht rückgängig macht. Das ist schmal ein simpler Handwerklicher Fehler.
Das es Rechte von Ordnern, die es nicht selber anlegt, ändert ist dann schon ein Fehler im Design. Wer das macht, macht was kaputt, was sich andere (hoffentlich nicht grundlos) ausgedacht haben. Das ist also ein echtes NoGo.
Ob das nun eine direkte oder indirekte Sicherheitslücke ist, kann man leider auch nicht streiten. Es bleibt eine Sicherheitslücke. Weil hat ja nur ein Beispiel aufgeführt wie es passieren könnte.

Für mich ist das damit gestorben. Ich würde es versuchen, ohne Zusatzsoftware schauen, ob sich php7 nicht direkt installieren läßt und mir notieren, Weile ggf Vorraussetzungen an weiterer Software vorher installiert werden muß. Hab ich zumindest für fetchmail und OpenSSL selber so gemacht

Bitte lies dich doch mal ein.
So wie Du es schreibst ist es nicht. Du als Benutzer hast auf dem System Admin-Rechte von Haus aus. Diese sind unter anderem für die Ordner /usr/local und /opt vom System her schon so angelegt.

So schwer kann mein Beispiel doch nicht zu verstehen sein.

Die „HB Community“ muss überhaupt nichts „zulassen“. Sobald der Eigentümer der /usr/local-Hierarchie auf den normalen Mac-Nutzer umgestellt ist, kann jedes x-beliebige Schadprogramm eine ls-Version dort ablegen. Mein Beispiel geht doch nicht davon aus, dass Homebrew selbst das tut. Es öffnet nur die Türen für diesen Missbrauch.
Doch, daran ist ausschließlich Homebrew schuld: Weil es die Zugriffsrechte verstellt.
Nicht zwingend (siehe Drive-by-Infektionen von Websites und Angriffe von außen), aber selbst wenn:

Alle Sicherheitsvorkehrungen dienen nur dazu, den Schaden bei Fehlverhalten des Nutzers (oder Drive-by-Infektionen von Websites oder Angriffen von außen oder anderen Problemen) zu begrenzen; das ist ihre ganze Aufgabe. Gäbe es kein Fehlverhalten von Nutzern und keine Angriffe (und keine wildlaufenden Programme oder andere Probleme – Probleme gibt es in der IT immer), bräuchte es überhaupt keine Sicherheitsvorkehrungen.
Oder aktiv von einem Angreifer von der Straße abgedrängt, oder die Lenkachse ist gebrochen, oder …

Die Schuldfrage spielt keinerlei Rolle, das ist nur Rechthaberei und Schuldzuweisung. darum geht es nicht. Es geht einzig allein um Schadensbegrenzung bei einem möglichen Problem, völlig egal, woher das Problem kommt. Und einen ganz wesentlichen Teil der Schadensbegrenzung schaltet Homebrew einfach ab.
Du scheinst die Dimension des Problems einfach nicht zu verstehen. Das ist keine Nebensächlichkeit, hier wird in Gestalt der Zugriffsrechte der elementarste Schutz von Unix ausgehebelt.
Ja, Du bist offenkundig dieser Ansicht, aber die ist eben schlicht falsch. Würde man sich tatsächlich schlau machen, würde man begreifen, dass das eben nicht sicher ist. Und mit den Beschränkungen des Mac App Stores hat das nun überhaupt nichts zu tun; da geht es um Sandboxing, das ist etwas vollkommen anderes. Es gibt beliebig viele Programme, die mangels Sandboxing nicht über den Mac App Store vertrieben werden dürften, aber niemals die Unix-Zugriffsrechte verstellen würden, wie das Homebrew tut (unter der Maßgabe, dass diese Information stimmt).

@ Weia: 👍🏻

Zur definitiven Klärung der Situation: Könnte bitte jemand von denjenigen unter Euch, die Hombrew installiert haben, die folgenden beiden Terminal-Befehle ausführen und das Ergebnis hier posten? Nur, damit die Fakten klar sind.

Zugriffsrechte in /usr/local:

Aufrufhierarchie:

Danke!

Nö, tut sie nicht.
Ich kann nur wiederholen: Gäbe es die Sicherheit, dass keine Sicherheitsbedrohungen auftreten (durch unbeabsichtigte Sicherheitslücken, gezielte Angriffe, wildlaufende Programme, verwirrte Nutzer, whatever), gäbe es überhaupt keinen Grund für Schutzmaßnahmen jeglicher Art.

Schutzmaßnahmen dienen stets der Schadensbegrenezung bei Problemen, ganz egal, woher die kommen.

Und vielfach genäht hält da besser. Umso mehr Schutzvorkehrungen, umso besser. Und Homebrew hebelt eine elementare davon aus. Natürlich setze ich voraus, dass zuvor an anderer Stelle Probleme auftragen, denn genau dagegen sollen Schutzvorkehrungen wie Zugriffsrechte doch helfen. In einer idealen Welt braucht es keine Schutzvorkehrungen.

Was Du schreibst, ist das Äquivalent zu: Du setzt die Existenz von Dieben voraus um aufzuzeigen, dass eine unverschlossene Wohnungstüre eine Sicherheitslücke darstellt, die es nicht gäbe, wenn die Wohnungstüre verschlossen wäre. Ja, natürlich, und wo ist in diesem Gedankengang ein Fehler?
Schädlingsprogramme testen oft auf zahllose Lücken gleichzeitig. Es ist doch absurd zu denken, den Hintereingang im Garten schließe ich nicht ab, der Dieb wird schon versuchen, durch die Haustüre zu kommen.
Nein, nicht ein wenig, sondern sperrangelweit. Wenn es sich tatsächlich so verhält, wie ich jetzt hier gelesen habe (ich warte noch auf die Bestätigung durch die Terminal-Befehle), dann ist Homebrew der absolute Sicherheits-GAU.
Nochmals: Alle Sicherheitsmaßnahmen haben ihren Grund ausschließlich darin, dass sie voraussetzen, es könnten an anderer Stelle Probleme entstehen. Bestünde diese Gefahr nicht, bedürfte es keiner Schutzmaßnahmen.

Und wie aktiviert man die?
Du hast aber schon verstanden, dass mein Beispiel überhaupt keine von Homebrew installierten Unix-Programme verwendet?
Wo habe ich etwas missverstanden?

nachdem ich diesen blog-post gelesen hatte, war fuer mich der entscheid zugunsten MacPorts schnell gefaellt:

ja, der artikel ist zwei jahre alt. ich denke jedoch, dass er nach wie vor gueltigkeit hat.

Und zum wiederholten Male möchte man Dir nahelegen, Deinen eigenen Ratschlag zu berücksichtigen. 🙄
Schon da stehen mir die Haare zu Berge. Deine alltäglichen Arbeiten solltest Du niemals mit Admin-Rechen ausführen, sondern in einem Nutzerkonto mit Standardrechten.

Ja, ich weiß, Apple legt dieses Fehlverhalten nahe. Das halte ich auch für falsch. Allerdings hat Apple im Gegenzug zumindest deutlich beschränkt, was ein Admin machen kann.
Nein, das ist definitiv falsch. Die Ordner gehören ausschließlich root:wheel und sind zudem nur für den Eigentümer schreibbar. Als Admin-Nutzer kannst Du da überhaupt nichts verändern; Du musst erst explizit Dein Admin-Passwort in einem Dialogfenster angeben (das GUI-Pendant zu sudo), um root zu werden.

weia
Ich werd' das Ergebnis dieser Aufrufe hier nicht komplett reinstellen, aber das Ergebnis ist:

In meinem $PATH erscheint /usr/local/bin dann auch vor z.B. /usr/bin.

Ich bin aber trotzdem nicht der Meinung, dass unter dem von Dir beschriebenen Szenario der Einsatz von Homebrew eine Sicherheitslücke öffnet, die ohne nicht da wäre.

Denn: Wenn ein Schadprogramm bei mir auf dem Rechner etwas in /usr/local/bin ablegen kann, dann könnte es genausogut etwas in ~/.bin ablegen und mir einen entsprechenden Eintrag in $PATH anlegen, der ebenso vor /usr/bin kommt. Ob Homebrew jetzt installiert ist, ändert also nichts wenn Schadsoftware erstmal schreibenden Zugriff auf mein System hat.

Danke! Damit ist jedenfalls klar, dass Homebrew tatsächlich die Zugriffsrechte wie vermutet verbiegt.
Das stimmt für den befallenen Nutzer. Es stimmt nicht für alle übrigen Nutzer des Systems. Zugriffsrechte dienen ja generell dazu, dass Probleme in einem Nutzerkonto nicht auf andere Nutzerkonten oder das System übergreifen können. Innerhalb seines eigenen Nutzerkontos können Zugriffsrechte einen einzelnen Nutzer prinzipbedingt vor gar nichts schützen; das liegt in der Natur der Sache. Insofern ist diese Feststellung trivial und ändert nichts an dem Sicherheits-GAU, den Homebrew darstellt.

Hattest Du denn Homebrew jetzt schon installiert? Denn bei Dir ist ja auch das allermeiste auf Dich als Eigentümer umgebogen und damit die Sicherheitslücke da.

Ja,homebrew ist auf (m)einem Testrechner bereits seit letztem Freitag installiert.

Auf meinem "Produktiv"-M1-MBP ohne homebrew sieht es folgendermaßen aus:

Ja, und so wie auf Deinem Produktivrechner muss es auch sein und unbedingt bleiben! Also vergiss Homebrew und installiere PHP entweder direkt oder via MacPorts, das ja wohl besser sein soll (genau kenne ich es nicht).

Hm (Big Sur auf Intel):