Big Sur Systemzugriff

linux

Aktives Mitglied
Thread Starter
Dabei seit
11.02.2008
Beiträge
174
Reaktionspunkte
30
Hallöchen,
da ich gerne zu Big Sur umsteigen möchte folgende Frage:
Wie bekomme ich Zugriff auf /System/Library? Derzeit habe ich keine Schreibrechte.
Csrutil ist disabled.
Ich möchte Big Sur gerne optisch und akkustisch an meine alten Versionen anpassen.
 
Das wird nichts ohne Weiteres. Das Systemvolume ist komplett versiegelt.
 
Mannomann, muß ich erst einmal übersetzten.
 
Dir ist aber schon klar, dass du die Sicherheitsfunktionen deines Systems quasi abschaltest.
 
Mannomann, muß ich erst einmal übersetzten.

Quelle: https://eclecticlight.co/2020/06/25/big-surs-signed-system-volume-added-security-protection/

Die letzten beiden Hauptversionen von macOS haben eine rasante Entwicklung beim Schutz der Systemdateien mit sich gebracht. Bevor ich erkläre, was in macOS 11 Big Sur passiert, fasse ich zusammen, was bisher geschehen ist.

In macOS Mojave 10.14 bootet macOS von einem einzigen APFS-Volume, in dem sensible Systemordner und -dateien mit denen gemischt sind, auf die Benutzer schreiben können. Die wichtigsten Schutzmechanismen für das System stammen von den klassischen Unix-Berechtigungen und werden durch die Software System Integrity Protection (SIP) in macOS ergänzt.



In Mojave muss Malware nur eine Schwachstelle in SIP ausnutzen, um erhöhte Rechte zu erlangen, und schon kann sie mit Systemdateien machen, was sie will.

Catalina 10.15 ändert das, indem es das Boot-Volume in zwei teilt: das System- und das Daten-Volume, die eine APFS-Volume-Gruppe bilden. Unveränderliche Systemdateien befinden sich nun auf dem System-Volume, das nicht nur vollständig durch SIP geschützt ist, sondern normalerweise auch schreibgeschützt gemountet wird.



Das macht es für Malware viel schwieriger, die nicht nur SIP umgehen, sondern auch das System-Volume als beschreibbar einbinden muss, bevor sie Systemdateien manipulieren kann.

Obwohl Big Sur dasselbe geschützte System-Volume und dieselbe APFS-Volume-Group wie Catalina verwendet, ändert es die Art und Weise, wie dieses Volume geschützt wird, um es zu einer noch größeren Herausforderung für die Entwickler bösartiger Software zu machen: Willkommen beim Signed System Volume (SSV).

Jede Datei auf dem System-Volume von Big Sur verfügt nun über einen kryptografischen SHA-256-Hash, der in den Metadaten des Dateisystems gespeichert ist. Wenn Daten aus dem SSV gelesen werden, wird ihr aktueller Hash mit dem gespeicherten Hash verglichen, um zu überprüfen, ob die Datei nicht manipuliert oder beschädigt wurde. Diejenigen, die mit meinen Dateiintegritätstools vertraut sind, werden erkennen, dass dies im Wesentlichen die gleiche Technik ist, die sie verwenden.

Weitere Hashes werden in den Metadaten des Dateisystems selbst verwendet, von den tiefsten Verzeichnissen bis hinauf zum Stammknoten, wo sie als Siegel bezeichnet werden. Dadurch wird sichergestellt, dass diese Hashes das gesamte Volume, seine Daten und seine Verzeichnisstruktur abdecken. Das Siegel wird bei jedem Start des Macs überprüft, vom Bootloader, bevor der Kernel geladen wird, und während der Installation und Aktualisierung der macOS-Systemdateien. Wenn die Überprüfung fehlschlägt, wird der Startvorgang angehalten und der Benutzer wird aufgefordert, macOS neu zu installieren, bevor er fortfährt.

Auch Aktualisierungen werden durch diesen Mechanismus zuverlässiger gemacht: Wenn sie nicht abgeschlossen werden können, wird das vorherige System mit seinem Snapshot wiederhergestellt.

Für die große Mehrheit der Benutzer sollte all dies transparent sein. Sie installieren macOS-Updates genauso wie bisher, und Ihr Mac startet genauso wie früher. Sie können sich voll und ganz darauf verlassen, dass Big Sur nichts an den Daten auf Ihrem Systemvolume verändert hat. Der einzige Fall, in dem Sie wahrscheinlich auf die SSV stoßen werden, ist die Verwendung von bootfähigen macOS-Volumes durch Klonen oder von einem macOS-Installationsprogramm. Was auch immer Sie dafür verwenden, muss alle Hashes und Siegel erhalten, oder das Volume wird nicht bootfähig sein. Jede gute Klon-Software sollte damit gut zurechtkommen.

Wenn Sie eine Kernel-Erweiterung installieren müssen (keine der neueren Systemerweiterungen, DriverKit-Erweiterungen usw.), ist diese nicht mehr in den vorverlinkten Kernel eingebaut, der zum Booten Ihres Systems verwendet wird, sondern in /Library/KernelCollections/AuxiliaryKernelExtensions.kc. Da sich diese Datei auf dem beschreibbaren Datenträger befindet, hat sie keine Auswirkungen auf den Schutz der SSV.

Was definitiv viel komplexer wird, ist das Ändern von irgendetwas auf der SSV, denn Sie können Ihren Mac nicht mehr einfach von einem "Live"-System-Volume booten: das wird diese neuen Prüfungen nicht bestehen. Apple hat die Funktionen des csrutil-Befehls erweitert, um Änderungen an der SSV vornehmen zu können. In groben Zügen müssen Sie im Wiederherstellungsmodus booten und den Befehl

csrutil authenticated-root disable

verwenden, um die kryptografische Verifizierung zu deaktivieren, dann das Systemvolume mounten und dessen Änderungen vornehmen. Um es wieder bootfähig zu machen, müssen Sie einen neuen Snapshot des Volumes mit einem Befehl wie dem folgenden blessen.

sudo bless --folder /[mountpfad]/System/Library/CoreServices --bootefi --create-snapshot

Sie können dann mit dem neuen Snapshot als Systemvolume und ohne SSV-Authentifizierung neu starten.

In Catalina sollten Sie Änderungen am Systemvolume nicht ohne triftigen Grund vornehmen. In Big Sur ist dies der letzte Ausweg.


Übersetzt mit www.DeepL.com/Translator (kostenlose Version) und leicht editiert von mir.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: iWetterstein, don_michele1, Gwadro und 2 andere
@Macschrauber, mein neuer bester Freund, danke fürs Übersetzen. Die Probleme hatte ich auch schon zu meiner Hackintoshzeit weil die meisten links und Verknüpfungen in englisch sind. Da komme ich mit meinem Hauptschulenglisch nicht weit. (ähnlich ist es bei OC)
Wenn ich jetzt alles richtig verstanden habe:
Die möglichen Änderungen betreffen "nur" das Bootvolume und nicht den NVRAM oder Bootrom, d.h. wenn etwas schief geht ist das System im Eimer und nicht der Mac.
Das Ausschalten der Sicherungsmaßnahmen läßt sich rückgängig machen.
 
Für Sounds wäre der einfache und verträglichere Weg seine eigenen Soundfiles in [Home-Verzeichnis > cmd+shift+.] ~/Library/Sounds abzulegen.
Die werden dann dort gelistet, wo sie "verbaut" worden sind; bsw. Mail.app > ankommende neue eMail.
Und halt andere Apps oder Optionen, wo diese Sounds aus diesem Verzeichnis verwendet werden können.
 
@Macschrauber, mein neuer bester Freund, danke fürs Übersetzen. Die Probleme hatte ich auch schon zu meiner Hackintoshzeit weil die meisten links und Verknüpfungen in englisch sind. Da komme ich mit meinem Hauptschulenglisch nicht weit. (ähnlich ist es bei OC)
Wenn ich jetzt alles richtig verstanden habe:
Die möglichen Änderungen betreffen "nur" das Bootvolume und nicht den NVRAM oder Bootrom, d.h. wenn etwas schief geht ist das System im Eimer und nicht der Mac.
Das Ausschalten der Sicherungsmaßnahmen läßt sich rückgängig machen.

von wegen Bootrom, auch wenn ich mich immer wieder wiederhole (ist nun mal mein Thema):

Bootrom sichern und vor allem beim Crossflash 4.1 -> 5.1 wäre ein Neuaufbau anzuraten.

Du krebst noch mit dem 4.1 Bootloader rum bzw einem Zwitterding zwischen 4.1 und uraltem 5.1 Bootlader sowie Variablen im NVram die noch vom 4.1er stammen und nicht rausgehen, auch noch nicht mit noch so vielen nvram resets.

Es gibt einen "privaten" Bereich im NVram in dem Firmwarevariablen gespeichert werden die nicht gelöscht werden. Diese und der meistens inkorrekte zweite VSS Stream beim Crossflash können die Garbage Collection (das Aufräumen im nvram) durcheinander bringen. Dazu noch den ganzen Kram den Systeme schreiben die nie für das kleine, 64kb große NVram (der erste VSS1 Stream) des Mac Pro vorgesehen waren können bei den 4.1->5.1 zum Brick führen.

Das NVram füllt sich bei jedem Booten um ca. 5 Kilobytes (von ca. 64), wenns voll ist schreibts eine Kopie in den zweiten Stream, leert sich und schreibt die Kopie in den ersten Stream. Wenn das nicht klappt dann "zerstört" sich die Firmware selber.

Dann hilft nur noch löten, Backplane raus, Flash raus, neuen extern mit dem Backup (!) programmieren, wieder reinlöten. Das sind zwei Stunden Arbeit für jemanden der das alle paar Wochen macht und eine Katastrophe für jemanden der darauf nicht vorbereitet ist.

btw: auch die Flash ICs gehen kaputt, das schreiben auf immer wieder die gleichen Zellen im NVram verschleißt die Dinger, es gibt kein Wear Leveling wie bei SSDs. Eine Bit einer Zelle kaputt und das war's.

Ich schreib das nicht nur für @linux, das Thema geht ja alle an die mit den alten Kisten noch arbeiten. Deshalb auch der Link zum Faden:

Thema 'Mac Pro 5.1 Rom / Firmware Backup Beschreibung und technischer Hintergrund'
 
Zurück
Oben Unten