Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Entwickler>Frage nach Deaktivierung von rootless

Frage nach Deaktivierung von rootless

herzfleisch02.10.1523:30
Ich suche für folgendes Problem eine Lösung: Auf meinem alten MacBook Pro 17 (2009) habe ich nun El Captain installiert; was soll ich sagen: Die Leistung des Geräts wurde dadurch in der Tat enorm beschleunigt. Nun habe ich schon vor Jahren den überflüssigen Dvd-Schacht durch eine zweite Festplatte ersetzt und hatte bislang stattdessen ein Superdrive-Laufwerk benutzt, um Programme von DVDs zu installieren. Um das Superdrive am alten Mac laden lassen zu können brauchte ich lediglich die "com.apple.Boot.plist" mit einen Befehl zu ergänzen. Nun aber, da Apple das El-Captain-System komplett blockiert hat, ist das nicht mehr möglich. Ich meine aber, dass der rootless-Schutz zu reaktiveren ist, ich habe es nur noch nicht herausgefunden, wie. Das also wäre ist meine Frage. Bisher versucht habe ich es vergeblich mit dem Terminal-Befehl "sudo nvram boot-args="rootless=1“; osascript -e 'tell app "loginwindow" to «event aevtrrst»' " und auch der Hinweis, beim Start von der Rettungspartition wäre bei den Dienstprogammen ein neues zu finden, mit dem dieser Extra-Schur systemweit abzuschalten ist, hat mir nicht geholfen. Ich sehe da kein derartiges Tool. Langer rede kurzer Sinn: Kann mir jemand mit der Information helfen, wie der rootless-Schutz zu reaktiveren und dann wieder zu aktivieren ist? Danke
0

Kommentare

herzfleisch02.10.1523:42
P.S.: Das Installationsproblem habe ich übrigens schon an sich so gelöst, dass ich mit einem anderen Rechner, der ein DVD Laufwerk hat, eine DMG-Datei in dem Fall von Filemaker angefertigt habe und diese zur Installation nutze. Dennoch würde ich gerne wissen wollen, wie rootless zu de- bzw. reaktiveren ist.
0
Marcel_75@work
Marcel_75@work03.10.1500:03
Die wichtigsten Optionen des neuen "Configuring System Integrity Protection":
csrutil clear
csrutil disable
csrutil enable
csrutil status
csrutil netboot add <IPv4 address>
csrutil netboot list
csrutil netboot remove

Im laufenden Betrieb kannst Du Dir nur den Status ansehen, die gewünschten Einstellungen setzt Du per Recovery-Modus.

Mit einem PRAM-Reset wird übrigens alles wieder zunichte gemacht, also auf den Standard "enabled" gesetzt.

Mehr Infos:
0
herzfleisch03.10.1500:06
Marcel_75@work
Die wichtigsten Optionen:
csrutil clear
csrutil disable
csrutil enable
csrutil status
csrutil netboot add <IPv4 address>
csrutil netboot list
csrutil netboot remove

Im laufenden Betrieb kannst Du Dir nur den Status ansehen, die gewünschten Einstellungen setzt Du per Recovery-Modus.

Mit einem PRAM-Reset wird übrigens alles wieder zunichte gemacht, also auf den Standard "enabled" gesetzt.

Super, danke! Jetzt habe ich es verstanden und sehe auch, was ich zuvor falsch gemacht habe
0
Marcel_75@work
Marcel_75@work03.10.1500:09
PS: Interessant ist natürlich der Absatz "Note: For certain enterprise configurations that do not allow booting to Recovery OS, System Integrity Protection can be configured by other means."

Weiß denn jemand schon genaueres diesbezüglich? Eine neue Mobile Configuration Option?
0
Marcel Molin
Marcel Molin03.10.1500:13
sudo nvram boot-args="rootless=0"; osascript -e 'tell app "loginwindow" to «event aevtrrst»'
0
Marcel_75@work
Marcel_75@work03.10.1500:27
Marcel Molin
sudo nvram boot-args="rootless=0"; osascript -e 'tell app "loginwindow" to «event aevtrrst»'

Das funktionierte doch so nur in den frühen Betas von 10.11, oder?

Das GUI-Tool kam dann in späteren 10.11er Betas und war im Recovery-Modus verfügbar, genau das ist das Tool, welches herzfleisch suchte und nicht finden konnte ... denn nun, in der finalen Version von 10.11, gibt es das auch nicht mehr im Recovery-Modus sondern eben nur noch csrutil als binary im Terminal.

Deshalb eben meine Frage, wie das nun nach wie vor laut Apple auch ohne Recovery-Modus funktionieren soll (denn ohne EFI-Kennwort kommt man ja z.B. nicht in den Recovery-Modus).
0
Marcel_75@work
Marcel_75@work03.10.1500:52
Noch etwas mehr Lesefutter für die Interessierten unter euch:



Im Ars Technica Review (wie immer lesenswert: ) wurde SIP ja auch schon näher betrachtet, aber Rich Trouton legt wie so oft noch eine Schippe drauf. *Daumen hoch*
0
sierkb03.10.1501:03
Marcel_75@work:

Ich ergänze um:

Apple: Mac Developer Library: System Integrity Protection Guide

Apple: Mac Developer Library: Configuring System Integrity Protection
(Du hast es oben bereits genannt und verlinkt)

Apple: WWDC15: Security and Your Apps (PDF)

Apple: WWDC15: Security and Your Apps (video)
0
Marcel_75@work
Marcel_75@work03.10.1501:31
sierkb: Danke Dir.

PS: Was sagst Du eigentlich hierzu?

Ob Apple erst noch das GateKeeper-Problem klären will?
0
sierkb03.10.1503:51
Marcel_75@work
PS: Was sagst Du eigentlich hierzu?

Was soll ich dazu sagen außer Dir und den anderen Kommentatoren da beizupflichten? Ganz klar Unverständnis, Kopfschütteln, Daumen runter in Richtung Apple. Die sollen rüberkommen mit den Security-Fixes für die anderen OS-Versionen. Jeder Tag Verzug ist da ein verlorerner Tag. Dieses arrogante und bornierte 'laissez faire, laissez aller' und dieser sanfte Druck in die von ihnen gewünschte Richtung, damit es für Apple am Bequemsten und Lukrativsten ist unter Inkaufnahme verminderter Sicherheit einer nicht kleinen Anzahl ihrer Nutzer kann Apple sich nicht länger leisten, sollten die Nutzer ihnen nicht länger durchgehen lassen.
Ob Apple erst noch das GateKeeper-Problem klären will?

Das scheint mir dringend renovierungsbedürftig, so wie es derzeit ist, das gesamte Konzept inklusive dem AppStore-Konzept als Co-Bestandteil, ist es leicht auszuhebeln, ist im Grunde ein Placebo, Augenwischerei ("Wardle describes as "trivial to bypass" and, in his opinion, "completely broken."" ).
Apple hat/hätte an der Front und an anderen soviel zu klären…
Gut gemeint ist eben nicht automatisch auch gut gemacht.

Apple soll einfach mal zusehen, dass sie in die Puschen kommen und die dringens ausstehenden Fixes an die Nutzer weiterreichen. Und wenn sie dafür zusätzlich Leute einstellen oder woanders wegkaufen müssen, um das bewerkstelligen zu können, Geld genug, die an Land zu ziehen, haben sie schließlich als reichstes Unternehmen des Planeten. Bei der Produktion ihrer Geräte schafft Apple es ja schließlich auch, sich gewisse Kontingente bei den Fertigern per Vertrag zu sichern und diese sich zu reservieren, um dem Bedarf und dem selbst gesetzten Zeitplan gerecht zu werden. Alles eine Frage des Wollens und der Prioritätensetzung – andere schaffen das schließlich auch und meistern ihre Hausaufgaben teilweise besser und schneller, bei viel geringerem Personal und viel geringerem Budget und vergleichsweise ähnlich großer oder noch größerer und wichtigerer Nutzerbasis. Apple spart da am falschen Ende. Zulasten ihrer Nutzer.
0
dom_beta03.10.1508:31
sierkb
Die sollen rüberkommen mit den Security-Fixes für die anderen OS-Versionen. Jeder Tag Verzug ist da ein verlorerner Tag. Dieses arrogante und bornierte 'laissez faire, laissez aller' und dieser sanfte Druck in die von ihnen gewünschte Richtung, damit es für Apple am Bequemsten und Lukrativsten ist unter Inkaufnahme verminderter Sicherheit einer nicht kleinen Anzahl ihrer Nutzer kann Apple sich nicht länger leisten, sollten die Nutzer ihnen nicht länger durchgehen lassen.

ich glaube schon, dass Apple das so durchzieht oder die Updates kommen verspätet.

Das erinnert an den einen Bug unter 10.6 (Thunderbolt SW Update), da meinte Apple auch:

"Möchten Sie nicht doch upgraden?"
„...“
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.