Angepinnt El Capitan und die System Integrity Protection - Was ist das und wie kann ich es ändern?

Forum Unterstützen

Wenn Du unsere Arbeit unterstützen möchtest, würden wir uns über eine Spende sehr freuen! :-)

Team

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    El Capitan und die System Integrity Protection - Was ist das und wie kann ich es ändern?

    Zusammen mit dem bevorstehenden Release von El Capitan führt Apple auch ein neues Sicherheitsfeature ein welches das System weitestgehend für dem Zugriff von aussen abschotten soll. Natürlich ist hier die Rede von der System Integrity Protection oder, wie das feature anfangs auch genannt wurde, dem Rootless Mode. So ganz neu wie man vielleicht meinen mag ist die SIP aber eigentlich gar nicht denn sie wurde bereits mit OS-X Yosemite eingeführt und von da an konsequent weiterentwickelt. Der allseits bekannte kext-dev-mode ist nämlich bereits ein Teil der SIP und wenn man genauer hinschaut erkennt man, dass der Kernel von Yosemite auch alle anderen Features der SIP unterstützt diese jedoch nicht zum Einsatz kommen. Aber was ist diese SIP denn nun eigentlich genau?

    Die System Integrity Protection sichert, wie bereits geschreiben, das System weitestgehend vor dem Zugriff von aussen ab. Dies wird erreicht indem sensible Bereiche des System nicht mehr verändert werden können. Nach der Installation von El Capitan ist die System Integrity Protection standartmäßig aktiviert was zur Folge hat, dass...

    -> Diverse Systemverzeichnisse besonders geschützt und ausgeblendet sind (/System, /bin, /sbin, /usr...)
    -> Nicht signierte Extensions nicht mehr geladen werden
    -> Im Festplattendienstprogramm die Optionen zum reparieren der Berechtigungen fehlen
    -> Der Inhalt von Systemverzeichnissen nicht mehr verändert werden kann
    -> Der Inhalt des NVRAMs nicht mehr verändert werden kann

    Per Design lässt die System Integrity Protection also keinerlei Veränderungen an systemrelevanten Dateien zu und zwar weder durch Benutzer noch durch Programme und selbst der root User ist davon nicht ausgenommen. Für den Otto normalanwender also eigentlich ein durchaus sinnvolles Feature denn das System läuft bei normaler Benutzung mit aktiver SIP nicht anders oder schlechter als ohne nur eben sicherer. Für die Hackintosh Community ist das freilich kein akzeptabler Zustand denn die SIP in der Form in der Apple sie implementiert hat ist für uns eher lästig als nützlich denn sie verhindert zuverlässig, dass unsere Hacks booten da essentielle Extensions wie etwa die FakeSMC jetzt nicht mehr geladen werden. Glücklicherweise lässt sich das Feature sehr fein konfigurien aber dazu muss man erstmal verstehen wie es funktioniert. Die SIP umfasst folgende Restriktionen:

    -> Apple Internal
    -> Kext Signing
    -> Filesystem Protection
    -> Debugging Restrictions
    -> Dtrace Restrictions
    -> NVRAM Protections

    und kennt neben an und aus auch noch eine Menge individuelle Konfigurationen die es uns ermöglicht den Schutzgrad unseren Bedürfnissen entsprechend einzustellen. Aber wie funktioniert das Ganze nun? Beim Start des Systems wertet der OS-X eigene Bootloader (boot.efi) bzw. der Kernel den inhalt einer bestimmte NVRAM Variable aus (CSRActiveConfig) und stellt das Schutzlevel entsprechend ihres Inhalts ein. Ist die Variable nicht vorhanden oder enthält den Wert 0 bedeutet dies das die System Integrity Protection komplett aktiv ist, weicht der Wert von der 0 ab wird der Schutzgrad entsprechen der Konfiguration eingestellt. Folgende Übersicht veranschaulicht die möglichen Konfigurationen:

    Quellcode

    1. hex n/a nvram dtrace intern debug pid fs kexts
    2. csrutil enabled --no-internal 00 0 0 0 0 0 0 0 0
    3. csrutil enabled 10 0 0 0 1 0 0 0 0
    4. csrutil enable —-without kext 11 0 0 0 1 0 0 0 1
    5. csrutil enable —-without fs 12 0 0 0 1 0 0 1 0
    6. csrutil enable —-without debug 14 0 0 0 1 0 1 0 0
    7. csrutil enable —-without dtrace 30 0 0 1 1 0 0 0 0
    8. csrutil enable —-without nvram 50 0 1 0 1 0 0 0 0
    9. csrutil disabled 77 0 1 1 1 0 1 1 1
    10. Other settings
    11. disabled (no internal) 67 0 1 1 0 0 1 1 1

    Hier wird deutlich, das sich das Schutzlevel sehr fein einstellen lässt. Für einen typischen Hackintosh Fall (Post install) würde es zum Beispiel reichen vorübergehend den Filesystem Schutz auszuschalten und das laden unsignierter Extensions zu erlauben. Folgt man dem oberen Beispiel ergibt sich hieraus also:

    Quellcode

    1. hex n/a nvram dtrace intern debug pid fs kexts
    2. No FileSystem,Kext 03 0 0 0 0 0 0 1 1

    Also ein binärwert von 00000011 oder eben ein hex Wert von 03 setzten lässt sich der Wert nun abhängig vom Bootloader auf unterschiedliche Art und Weise. Bei Clover erreicht man das indem man den Wert in den Bereich RT-Variables unter den Punkt CsrActiveConfig in die config.plist einträgt was dann in etwa so aussieht:

    Quellcode

    1. <key>RtVariables</key>
    2. <dict>
    3. <key>CsrActiveConfig</key>
    4. <string>0x03</string>
    5. </dict>
    unter Ozmosis gelingt es indem man den Wert mit dem folgenden Kommando in den NVRAM schreibt

    Quellcode

    1. nvram 7C436110-AB2A-4BBB-A880-FE41995C9F82:csr-active-config=%03
    oder an der entsprechenden Stelle in die defaults integriert. Allerdings funktioniert das nicht mehr, wenn El Capitan bereits läuft. Um den Wert zu setzen muss man dann entweder die EIF Shell aus dem Bios starten (HermitShell) und den Wert mittels SetVar Befehl setzen oder aber Yosemite booten und die Einstellung vor der Installation von El Capitan dort vornehmen. Prüfen wie die SIP eingestellt ist kann man dann anschließend im laufenden El Capitan durch die Eingeabe des folgenden Befehls ins Terminal:

    Quellcode

    1. csrutil status
    die Antwort sieht bei komplett abgeschalteter SIP dann so aus

    Quellcode

    1. System Integrity Protection status: enabled (Custom Configuration).
    2. Configuration:
    3. Apple Internal: disabled
    4. Kext Signing: disabled
    5. Filesystem Protections: disabled
    6. Debugging Restrictions: disabled
    7. DTrace Restrictions: disabled
    8. NVRAM Protections: disabled
    9. This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
    Für diejenigen unter Euch, die es lieber grafisch mögen gibt es aber auch ein Tool zum setzen der Einstellungen. Das SIPUtility läuft sowohl auf Yosemite als auch auf El Capitan und lässt komfortable Änderungen an der Konfiguration zu solange der NVRAM beschreibbar ist.

    Das Programm habe ich Euch angehangen :)
    Dateien
    • SIPUtility.zip

      (509,66 kB, 416 mal heruntergeladen, zuletzt: )
    System 1 (iMac 13,1) PowerMac G5 Case: GA-Z77-DS3H, Clover, Intel XEON E3-1235V2 @ 3.2 GHz, 32GB DDR3, Powercolor R9-290X , Samsung 850 EVO 500GB + WD Caviar Blue 1TB, OS X 10.13.3
    System 2 (MacBook Pro 8.1): ThinkPad T420s, i5-2520M @ 2.5 GHz, 4GB DDR3, IntelHD 3000, Toshiba Q300 240GB SSD, Sandisk 128GB SSD, Triple Boot MacOS Siera 10.12.6,MacOS HighSierra 10.13.3, Windows10 Pro 64Bit

    Gute Erklärung :danke:
    Meine Systeme


    Spoiler anzeigen
    HackBooks:
    T420 * i5 2540M * HD3000 * 8GB DDR3 * 10.13.5 + Win10 Pro
    Clover 4558

    Lenovo IdeaPad Z710 i5 4200M, 8GB, 525GB Crucial MX300,10.14 beta + Win 10 Pro
    Clover 4558
    ***********************
    iMac 18.3:
    MSI Z370 PC PRO - i7 8700 K 6x 3,7 GHz -16GB Ram - Gigabyte RX 560 - WLAN+BT: BCM94360CD
    Clover 4617 - 10.13.6 (17G65) + 10.14 Beta (18A347e)
    Win10 pro auf Samsung 850 evo

    iPhone5 Black 64GB

    wie finde ich heraus ob auf meinen Notebook der NVRam beschreibbar ist?
    Hardware: MacBook Pro 13" Retina Erly 2015
    Intel Core i5-5257U i5-5287U
    Intel Iris Pro 6100
    8GB RAM

    Endlich ein Neues (on)Board

    Lenovo ist nicht mehr =(
    @Griven hatte dazu mal was geschrieben:

    Um zu testen, ob das NVRAM beschreibbar ist, folgendes ins Terminal eingeben:
    sudo nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:test=OK

    anschließend das Terminal schließen und den Rechner neu starten. Jetzt
    wieder ein Terminal öffnen und den folgenden Befehl eingeben:
    nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:test

    sieht das Ergebnis so aus:
    4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:test OK
    ist der NVRAM beschreibbar,

    sieht es hingegen so aus:
    nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:test': (iokit/common) data was not found
    ist er nicht beschreibbar.
    "Meine Systeme"
    Mobil: GrizzlyPad T430 / I7-3612QM / 8 GB RAM / HD4000 / 480 GB SanDisk Ultra + 250 GB Crucial mSASA/ AR9280 (rebranded als Intel n6205) / DVD / Clover 3300 / 10.11.6
    Mobil2: BuBuBear X230 / I5-3320M / 8 GB RAM / HD4000 / 240 GB SanDisk Ultra / UltraBase 3 mit DVD-Brenner / AR9280 (rebranded als Intel n6205) / Clover 3300 / 10.11.5
    Old Faithful (Server): EP43-UD3L / C2D Q6600 / 4 GB RAM / 8800GT 512 MB / div HDDs / DWA-547 / Chameleon / 10.7.5
    Quicksilver 2014: H87M-D3H / i7-4790 / 8 GB RAM / HD4600 / 240 GB SSD / DVD-Brenner
    / Apple BCM94360 / Ozmosis167X / 10.11.3 / QuickSilver PowerMac-CaseMod
    BlackDeath: Z97E-ITX/ac / i5-5675C / 16 GB RAM / HD6200 / 240 GB SSD / BCM94352HMB / Clover / 10.11.4 - in progress


    "Aber macOS ist manchmal eine Elb gewordene Vulkanette..."
    - Griven

    Du hast dringende Fragen zur Installation deines Systems? Dann poste in einem themenverwandten Thread und nutze die geballte Power des Forums anstelle meines Postfaches. Ich bin vielleicht Moderator, aber nicht allwissend oder unfehlbar - sondern moderiere Diskussionen
    Yay Danke Yogi =)

    Hab keinen beschreibbaren NVRAM
    "nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:test': (iokit/common) data was not found"
    Hardware: MacBook Pro 13" Retina Erly 2015
    Intel Core i5-5257U i5-5287U
    Intel Iris Pro 6100
    8GB RAM

    Endlich ein Neues (on)Board

    Lenovo ist nicht mehr =(
    Der von Yogi gepostete Check bezieht sich in erster Linie auf OZMOSIS Systeme. Bei Systemen die mit Clover gebootet werden oder bei echten Macs existiert die Adresse so nicht. Prüfen ob die NVRAM Emulation funktioniert (sofern installiert) oder NVRAM gar so beschreibbar ist kann man aber auch hier zum Beispiel durch die Eingabe von

    Quellcode

    1. sudo nvram test="Test"
    prüfen ob es geklappt hat geht dann analog mit

    Quellcode

    1. nvram test
    die Antwort bei Erfolg sollte dann auch Test sein.
    System 1 (iMac 13,1) PowerMac G5 Case: GA-Z77-DS3H, Clover, Intel XEON E3-1235V2 @ 3.2 GHz, 32GB DDR3, Powercolor R9-290X , Samsung 850 EVO 500GB + WD Caviar Blue 1TB, OS X 10.13.3
    System 2 (MacBook Pro 8.1): ThinkPad T420s, i5-2520M @ 2.5 GHz, 4GB DDR3, IntelHD 3000, Toshiba Q300 240GB SSD, Sandisk 128GB SSD, Triple Boot MacOS Siera 10.12.6,MacOS HighSierra 10.13.3, Windows10 Pro 64Bit

    Danke für die Aufklärung. :thumbup:
    iMac16,2 (Late 2015): Gigabyte Z97X UD3H - Intel Core i5 5675C - 16GB DDR3 - GTX 960 2GB - 10.11.6 - Clover r4509
    iMac14,2 (Late 2013): ASRock Z87 Pro4 - Intel Core i5 4670 - 16GB DDR3 - GTX 760 2GB - 10.13.3 - Ozmosis + Clover r4359
    iMac13,2 (Late 2012): ASRock Z77 Pro4 - Intel Core i5 3550 - 8GB DDR3 - GTX 660 2GB - 10.13.3 - Ozmosis + Clover r4359

    Metzger für angewandte Mettologie
    Hallo und schönen guten Abend,

    hätte mal zwei Fragen. Macht es Sinn nach der Installation SIP wieder zu aktivieren? Lassen sich die Berechtigungen mit Bordmitteln reparieren?

    thommel
    MfG thommel

    meine Systeme
    Hexa Core Intel i7 970,3,2 GHz,Gigabyte GA-EX58-UD5,12 GB DDR3-SDRAM,NVIDIA GeForce GTX 660 2048 MB,Sound: Realtek ALC889A, Clover- OS X 10.11

    IBM ThinkPad T61, Middelton Bios, Intel Core2Duo T7500@ 2.2 GHz, 4GB DDR2 (667Mhz), nVidia 140M 128 MB (0.95V), SanDisk SSD 120GB, WLAN Dell DW1510, Clover- OS X 10.11.1

    IBM ThinkPad T61p, Middelton Bios, Intel Core2Duo T9300@ 2.5 GHz, 4GB DDR2 (667Mhz), nVidia Quadro FX570 M 256 MB (0.95V), SanDisk SSD 120GB, WLAN Apple Airport Extreme, Clover- OS X 10.11.1
    Natürlich macht es zum einen Sinn, die SIP ist nicht zum "Schutz" gegen eines Hackintosh. Sondern viel mehr um das System vor ungewollten Zugriffen zu schützen.
    Die SIP wie schon Griven erklärt kannst du dir so konfigurieren wie es du brauchst :)

    Welche Berechtigungen meinst du nun, wenn du die Permissions von den Kexts meinst, kannst du dies mit dem Festplattendienstprogramm tun, oder einfach das Kext Utility verwenden (repariert automatisch).


    Gesendet von iPhone mit Tapatalk
    Desktop PC: i7 3770, Z77MX-QUO-AOS, 32GB Corsair Vengeance LP, PowerColor RX480 8GB, 1TB SSD, 10.12, Ozmosis
    Ahoi zusammen,
    wenn ich mit OZMOSIS arbeite und eine NVRAM-Variable setzen möchte, dann muss dieser elendig lange Hex-Code immer vorangestellt werden. Ist dieser Hex-Code, der Wert, den man beim Systembericht unter Hardware Übersicht -> Hardware-UUID sieht? Wenn ich mein OZMOSIS nun individualisiere, ändert sich dann diese UUID oder wodurch wird diese UUID generiert? Falls ich eine OzmosisDefaults auf meiner EFI-Boot Partition verwende, ist diese UUID dann auch der Wert, der beim Booten ausgewählt wird, um die Konfigurationsparameter für genau diesen Rechner zu übernehmen?
    --
    May The Force Be With You...

    Wenn Du mit elendig langem Hex-Code das hier meinst: 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 dann hat das nichts mit der Hardware-UUID zu tun. Dieser Wert dient Ozmosis dafür einzusortieren was es mit den Werten anfangen soll. Alle Werte unter 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102 zum Beispiel dienen dazu das SMBIOS zu definieren. OZ greift die Informationen dann an der Stelle im NVRAM ab und baut daraus des SMBIOS zusammen. Wenn Du Dir die Defaults.plist von OZ mal anschaust wirst Du die Struktur auch dort wiederfinden.
    System 1 (iMac 13,1) PowerMac G5 Case: GA-Z77-DS3H, Clover, Intel XEON E3-1235V2 @ 3.2 GHz, 32GB DDR3, Powercolor R9-290X , Samsung 850 EVO 500GB + WD Caviar Blue 1TB, OS X 10.13.3
    System 2 (MacBook Pro 8.1): ThinkPad T420s, i5-2520M @ 2.5 GHz, 4GB DDR3, IntelHD 3000, Toshiba Q300 240GB SSD, Sandisk 128GB SSD, Triple Boot MacOS Siera 10.12.6,MacOS HighSierra 10.13.3, Windows10 Pro 64Bit

    Zum Thema "Security" möchte ich gerne wissen, ob ein Hackintosh *dieselbe* Sicherheit gewährleisten kann wie ein normaler Mac. Oder wird diese Sicherheit etwa durch die bootflags von Clover irgendwie beeinträchtigt? Kennt sich jemand damit aus?
    Ich bin mir sicher, die Fragen könnten interessieren :).

    Vielen Dank im Voraus.
    S.
    El Capitan 10.11.5 (Clover 3599) – Gigabyte Z97X-UD5H F11b mod – Intel I7-4790k – MSI GTX 1070 Gaming X – Corsair Ballistix 16gb – 2x Samsung 850 Pro 128gb – 1x Samsung 850 Pro 256gb