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:



    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:

    Code
    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:

    Code
    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

    Code
    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:

    Code
    1. csrutil status

    die Antwort sieht bei komplett abgeschalteter SIP dann so aus

    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, 740 Mal heruntergeladen, zuletzt: )

    3 Mal editiert, zuletzt von al6042 ()

  • 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

    Mein Ryzentosh: ASRock B450M Pro4/ Ryzen 5 2600 / Ballistix 3600 CL16 / Asus Strix RX 580 8GB / (GC-WB1733D-I Bloetooth 5 Wlan 2x2 802.11ac)

    Bruder PC: ASUS Z170-P D3/ i5-6600K/ Intel HD 530/ BRCM4352/ ALC 887/ Intel Ethernet Server Adapter I350-T2

  • 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.


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


    Du hast dringende Fragen zur Installation deines Systems? Dann poste in einem themenverwandten Thread und [size=12]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

    Mein Ryzentosh: ASRock B450M Pro4/ Ryzen 5 2600 / Ballistix 3600 CL16 / Asus Strix RX 580 8GB / (GC-WB1733D-I Bloetooth 5 Wlan 2x2 802.11ac)

    Bruder PC: ASUS Z170-P D3/ i5-6600K/ Intel HD 530/ BRCM4352/ ALC 887/ Intel Ethernet Server Adapter I350-T2

  • Bei meinen Macs ( i und Minis) kommt diese Meldung (vorheriger Post) auch.


    Gruß. PJH

  • Wo ist denn der bedanken Button ? ;D

    Lenovo Thinkpad T440s


    - Intel Core i5-4210U 2x1,7 GHz
    - Intel HD4400
    - 12GB RAM
    - 1x SSD mit OSX Yosemite


    Working:
    - QeCi
    - Touchpad mit Gestures
    - Sound (VoodooHDA)
    - WLAN: Edimax
    - LAN
    - Sleep
    - USB 3
    - DisplayPort

  • 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

    Code
    1. sudo nvram test="Test"

    prüfen ob es geklappt hat geht dann analog mit

    Code
    1. nvram test

    die Antwort bei Erfolg sollte dann auch Test sein.

  • 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


  • 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.

  • 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