Mac OSX: So schützen Sie eine .app oder einen anderen Ordner mit einem Passwort vor dem Löschen/Verschieben durch Benutzer/Admin/Root

Ich arbeite an einem Sicherheitsagenten. Wobei ich keinem Benutzer/Administrator/Root erlauben möchte, meine Sicherheitsagentenanwendung normal zu löschen.

Wenn Benutzer/Admin/Root versuchen, die .app-Datei zu löschen, sollte das Betriebssystem den Passwortdialog anzeigen. Wenn der Benutzer das Passwort kennt, sollte nur dieses gelöscht werden.

Jeder Hinweis darauf wäre hilfreich.

Sie können root nicht daran hindern, irgendetwas zu tun (oder sudo rm), da Benutzer sich die Unix-Dateiberechtigungen ansehen
sudo würde nach einem Passwort fragen.
Bei allem Respekt, Mark liegt falsch; siehe meine Antwort unten. Das sudo-Passwort ist Admin-Benutzern bekannt, daher sind Unix-Dateiberechtigungen keine Antwort auf die Frage von op.

Antworten (1)

Haftungsausschluss

Diese Antwort ist nicht als Sicherheitshinweis für normale Benutzer gedacht. Wenn Sie die Sicherheitsstufe Ihres Mac auf 1 setzen, kann dies möglicherweise zu Fehlfunktionen bestimmter Software- oder Hardwaretreiber führen. Ich empfehle daher, Ihre eigene Due Diligence sowie unabhängige Nachforschungen und Tests durchzuführen, um festzustellen, ob die Ausführung dieser Schritte unerwünschte Folgen haben könnte.

Abschnitt 5.4.2 des unten verlinkten Artikels über die Funktionen von BSD in Bezug auf Sicherheitsbeschränkungen für den Superuser ist ein guter Ausgangspunkt. http://docstore.mik.ua/orelly/other/puis3rd/0596003234_puis3-chp-5-sect-4.html

Für den Fall, dass der Link in Zukunft unterbrochen wird, listet der wichtigste Abschnitt des Artikels die Auswirkungen der Einstellung auf kern.securelevel=1:

Der Schreibzugriff auf die Raw-Festplattenpartitionen ist verboten. (Dies zwingt alle Änderungen an der Festplatte, das Dateisystem zu durchlaufen.)

Raw-Zugriff auf den SCSI-Bus-Controller ist verboten.

Dateien mit gesetztem Immutable-Flag können nicht geändert werden. Dateien, bei denen das Nur-Anhängen-Bit gesetzt ist, können nur angehängt und nicht anderweitig geändert oder gelöscht werden.

Der Inhalt von IP-Paketen kann nicht protokolliert werden.

Raw I/O an die Systemkonsole ist verboten.

Raw-Schreibvorgänge in den Systemspeicher oder E/A-Gerätecontroller von Benutzerprogrammen sind verboten.

Ein Teil des Zugriffs auf das Linux /proc-Dateisystem wird verweigert.

Zusätzliche Kernelmodule können nicht geladen werden.

Die Systemuhr kann nicht zurückgestellt werden. Außerdem kann sie nicht mehr als maximal eine Sekunde vorgestellt werden, und sie kann nur einmal pro Sekunde vorgestellt werden (effektiv kann die Uhr höchstens auf die doppelte Zeit vorgeschoben werden).

Diese Liste ist nicht vollständig.

TLDR: Die Einstellung kern.securelevel=1könnte mehr Konsequenzen haben als in den folgenden Schritten beschrieben. Vorsichtig sein.

Allerdings habe ich diese Schritte auf einem normalen iMac mit OS X 10.10.2 getestet und dadurch keine Probleme festgestellt. In der Vergangenheit securelevel 1war dies die Standardeinstellung für OS X, und Manpages in OS X 10.10 weisen immer noch indirekt darauf hin, dass dies 1die Standardeinstellung ist (sie sagen, dass Sie im Einzelbenutzermodus neu starten müssen, um schg zu entfernen, was securelevel 0) erfordert.

In Wirklichkeit securelevel 0ist dies jedoch die Standardeinstellung seit OS X 10.5. Als die Online-Community erfuhr, dass Apple den Standardwert stillschweigend auf 0 geändert hatte, nannten es einige Systemadministratoren in Apple-Diskussionsthreads "skrupellos" von Apple, dies zu tun. Ich habe auch einige Sicherheitsleitfäden online gefunden, die besagen, dass die Einstellung kern.securelevel=1ein wichtiger Schritt ist, um Ihren Mac zu sichern. YMMV.

Zusammenfassung der Antwort

Solange Sie ein Firmware-Passwort auf einem Mac festlegen, können Sie jede Datei auf diesem Mac für niemanden löschbar machen, indem Sie einfach diesen einfachen Terminal-Befehl verwenden:

sudo chflags schg /path/to/file

Stellen Sie als Nächstes sicher, dass Ihr Mac immer auf Sicherheitsstufe 1 bootet, indem Sie Folgendes tun:

sudo vi /etc/sysctl.conf

Geben Sie im vi-Editor ein, ium in den Einfügemodus zu wechseln, und geben Sie dann kern.securelevel=1. Drücken Sie als Nächstes die Eingabetaste, dann den Doppelpunkt, geben Sie dann ein wqund drücken Sie die Eingabetaste.

Zuletzt im Terminaltyp:

sudo chflags schg /etc/sysctl.conf
sudo sysctl kern.securelevel=1

Jetzt, da Securelevel 1 ist und das schgFlag gesetzt ist, kann die Datei nicht gelöscht werden, es sei denn, das System wird im Einzelbenutzermodus neu gestartet.

Wenn ein Firmware-Passwort festgelegt wurde, benötigen Sie dieses Passwort, um in den Einzelbenutzermodus zu gelangen. Außerdem benötigen Sie es, um in den Zielfestplattenmodus zu gelangen oder die Startfestplatte zu ändern.

Mit gesetztem schg-Flag kann sogar root die Datei nicht löschen. Niemand kann es vom Finder oder Terminal aus ändern. Es erscheint im Finder gesperrt, aber das gesperrte Kontrollkästchen bleibt immer ausgegraut, egal was passiert, auch mit einem Admin-Passwort. Im Terminal sudo rm /path/to/fileschlägt es nun fehl mit der Meldung "Operation nicht erlaubt". Außerdem sudo SetFile -a l /path/to/fileschlägt der Vorgang mit „ERROR: Unexpected error. (-5000)“ fehl. :D

Um diese Datei zu löschen, muss jemand das Firmware-Passwort verwenden, um im Einzelbenutzermodus neu zu starten, und dann das schg-Flag mit diesem Befehl zurücksetzen:

sudo chflags noschg /path/to/file

Danach kann es gelöscht werden.

UPDATE: Wichtige zusätzliche Schritte, die für Answer to Work erforderlich sind

Update hinzugefügt Mi. 18. März 2015 ~13:20 PDT: In den Kommentaren zu dieser Antwort wurde ich darauf aufmerksam, dass jemand mit sudo-Zugriff auf dem System die geschützte Datei löschen könnte, indem er das Verzeichnis /private/etc umbenennt und dann seinen gesamten Inhalt kopiert, außer die Datei sysctl.conf in ein neues Verzeichnis /private/etc und Neustart. Dies würde bewirken, dass das Sicherheitsniveau auf Null zurückkehrt.

Um dies zu verhindern, sollten Sie nach Ausführung der obigen Schritte auch die folgenden Befehle ausführen:

sudo chflags schg /private
sudo chflags -h schg /etc

Der erste Befehl bewirkt, dass das Verzeichnis /private und seine Unterverzeichnisse nicht umbenannt werden können. Der zweite Befehl macht es unmöglich, den symbolischen Link auf Root-Ebene zu /private/etc umzubenennen oder zu löschen. (Das -hArgument bewirkt, dass chflags auf den symbolischen Link selbst wirken, anstatt auf das Ziel des symbolischen Links.)

Wichtigste Vorbehalte

  1. Wenn Sie auf einem Hackintosh oder Mac Pro mit einer inoffiziellen PC-Grafikkarte sind, die nicht mit offizieller Apple-Firmware oder etwas funktional Identischem geflasht wurde, funktioniert dieser Trick nicht. Ich bin mir nicht sicher, ob sie im Einzelbenutzermodus booten können. Wenn Sie also die Datei sysctl.conf erstellen und auf schg setzen, kann dies für immer so bleiben. Das bedeutet, dass Dateien, die auf schg gesetzt sind, niemals gelöscht werden können.

  2. Es kann einige physische Möglichkeiten geben, das Firmware-Passwort zurückzusetzen, indem Sie RAM entfernen oder die Datei löschen, indem Sie die SSD/HDD entfernen und an einen anderen Computer anschließen.

Erklärung der Antwort

Um ein Firmware-Passwort für Ihren Mac festzulegen, verwenden Sie die Schritte, die beim Googlen angezeigt werden, „So legen Sie ein Firmware-Passwort auf einem Mac fest“. Die Schritte sind kurz:

  • Neustart im Wiederherstellungsmodus

  • Wählen Sie Firmware Password Utility aus dem Menü Utilities und legen Sie das Passwort fest

  • ...

  • PROFITIEREN!

Erläuterung der Vorbehalte

Beachten Sie, dass ein Hacker auf Macs mit entfernbarem RAM möglicherweise Ihr Firmware-Passwort zurücksetzen kann, indem er die Größe des RAM ändert und dann Ihren PRAM einige Male löscht. Treffen Sie also auf solchen Macs geeignete physische Sicherheitsmaßnahmen, um den manuellen Zugriff auf die internen Komponenten des Computers zu verhindern.

Es genügt zu sagen, dass Sie auf Securelevel 0 kommen müssen, damit chflags noschges funktioniert, und normalerweise ist der einzige Weg, um auf Securelevel 0 zurückzukehren, ein Neustart im Einzelbenutzermodus. Auch dies ist möglicherweise nicht möglich, wenn Ihrem Mac die Apple-Firmware fehlt. Wenn Sie paranoid/unsicher sind, können Sie Ihr aktuelles Sicherheitsniveau sehen, indem Sie sysctl kern.securelevelTerminal eingeben; Es sollte immer 1 sein, nachdem die Schritte befolgt wurden, es sei denn, Sie befinden sich im Einzelbenutzermodus!

Weitere Hinweise

Soweit ich weiß, und korrigieren Sie mich, wenn ich falsch liege, aber die einzige Möglichkeit, ein Firmware-Passwort zu umgehen (außer es durch den RAM-Entfernungstrick zurückzusetzen), besteht darin, die primäre Festplatte oder SSD aus dem betreffenden Computer zu entfernen, und Greifen Sie von einem anderen Computer mit einem SATA-zu-USB-Adapter oder ähnlichem darauf zu. (Regierungsbehörden und/oder Apple haben möglicherweise eine geheime, geheime Hintertür ... aber wenn sie hinter Ihnen her sind, möchten Sie wahrscheinlich Dateien löschen, nicht deren Löschung verhindern :D.)

Technisch gesehen löst die Einstellung schg Ihr Problem also nur dann wirklich mit 100% Unfehlbarkeit, wenn Sie auf einem der neueren Macs ohne austauschbaren RAM und ohne austauschbare Festplatte (dh ein Retina MacBook Pro, MacBook Air usw.) und Sie sind Legen Sie Ihr EFI-Passwort fest, da dies die einzigen Macs ohne entfernbaren RAM oder entfernbare SSD sind. (Natürlich, wenn jemand Ihr Laufwerk herausnimmt, nur um eine Datei zu löschen, haben Sie wahrscheinlich wieder schlimmere Probleme, wie, Alter, wo ist meine Festplatte?)

Das Fehlen von „vom Benutzer austauschbarem“ RAM des 21,5-Zoll-iMac macht es viel schwieriger, das EFI-Passwort zu umgehen und RAM zu stehlen, was wahrscheinlich der Grund dafür ist, dass Apple es so gemacht hat, da es stark für den Einsatz in Schulen gedacht ist, wo Kinder es umgehen können und werden irgendwelche Sicherheitsmaßnahmen :D (Ich weiß, weil wir zu meiner Zeit direkt an AtEase auf System 7 vorbei gehackt haben, um Marathon zu spielen ...)

Bei iMacs ohne 21,5" können Sie den Trick des RAM-Entfernens/Firmware-Passwort-Zurücksetzens verhindern, indem Sie 40-50 $ in ein Schloss der Marke Maclocks für iMac investieren. Es wird in den Sicherheitsport gesteckt und hat eine Metallplatte, die die Stromversorgung abdeckt Socket, wo sich die Freigabe für die RAM-Luke befindet. Mit dieser physischen Sperre würde jemand eine Diamantsäge oder ähnliches benötigen, um Ihre schg-geschützte Datei zu löschen ... und wenn Leute Diamantsägen zu Ihren Computern bringen, dann haben Sie eine Menge schlimmere Probleme, über die man sich Sorgen machen muss, als wenn eine Datei gelöscht wird, wie, Alter, wo ist mein Computer?

sudo chflags noschg /path/to/file; sudo rm /path/to/filefunktioniert für mich auch ohne Rückgriff auf den Einzelbenutzermodus.
Was für einen Mac verwendest du? Wenn es sich um einen Mac Pro oder Hackintosh handelt, welche Art von GPU hat er? Welche Version von OS X hast du? Was ist das Ergebnis der Ausführung sysctl kern.securelevelim Terminal?
Das System ist ein Mac mini Ende 2012 mit 10.10.2, kern.securelevelist 0. Siehe pastebin.com/b2LNg7S1 für das Transkript.
Haben Sie Ihr EFI-Firmware-Passwort festgelegt?
Nein, planen Sie die Vanilla-Installation und führen Sie einfach die Befehle im Pastebin-Transkript aus.
OK, lassen Sie mich das überprüfen, es wird ein weiterer Schritt erforderlich sein, um das Sicherheitsniveau auf 1 zu setzen.
OK, ich habe die Antwort aktualisiert, sie wird jetzt für Sie funktionieren. Ich habe mich geirrt, als die EFI-Firmware das Securelevel einstellte. Sie müssen dies mit einer Datei namens /etc/sysctl.conf tun. Die erforderlichen zusätzlichen Schritte bestehen darin, diese Datei zu erstellen, sie dann mit chflags schg zu schützen und dann das Sicherheitsniveau festzulegen. Ich denke, dass ältere OS X-Versionen standardmäßig auf Securelevel 0 eingestellt sind. Ich weiß nicht, ob das Setzen auf 1 die Funktionalität des Systems beeinträchtigen könnte, da es mehr tut, als nur noschg zu verhindern. Siehe docstore.mik.ua/orelly/other/puis3rd/…
Was können Sie tun, wenn Sie von einer Wiederherstellungspartition booten – oder von einem Arcade-USB-Laufwerk?
Ich kann mir ein paar Möglichkeiten vorstellen, dies zu umgehen. Erstens, während die Datei möglicherweise gesperrt ist, wäre es immer noch möglich, das Verzeichnis, in dem sie sich befindet, umzubenennen und es durch ein Beinahe-Duplikat zu ersetzen (wobei nur die "gesperrte" Datei fehlt). Um dies zu verhindern, müssten Sie mindestens jedes andere Verzeichnis in seinem Pfad sperren ... und das Sperren von / oder eines der darunter liegenden Ordner der obersten Ebene würde wahrscheinlich Probleme verursachen. Zweitens würde ich denken, dass eine Kernel-Erweiterung in der Lage wäre, den Teil des Dateisystems zu umgehen, der das schg-Flag erzwingt, und Root kann Erweiterungen laden.
@Gordon - Ich denke auch in die gleiche Richtung. Erstellen einer Kernel-Erweiterung. Aber ich habe es noch nie geschrieben, also weiß ich nicht, wie ich damit anfangen soll. Wie genau wird es funktionieren? Können Sie eine URL posten, um darauf zu verweisen?
@Mark In Bezug auf einen USB-Stick weiß ich nicht, ob das System es Ihnen erlaubt, Ihr Startvolume zu ändern, nachdem das EFI-Firmware-Passwort festgelegt wurde. Was die Wiederherstellungspartition betrifft, sind Sie sich auch nicht sicher, bitte testen Sie und lassen Sie es uns wissen?
@Gordon: Sie können das Verzeichnis umbenennen, in dem es sich befindet, aber Sie können das Verzeichnis nicht ersetzen. Und wen kümmert es schließlich, wenn Sie das Verzeichnis umbenennen, in dem es sich befindet? Verwenden Sie einfach eine fileReferenceURL oder einen Finder-Alias, es ist ihnen egal, ob sich ein Pfad ändert. Was eine Kernel-Erweiterung betrifft, die die Sicherheitsstufe umgeht, gibt es Möglichkeiten, um zu verhindern, dass Personen Kernel-Erweiterungen auf Ihr System schleichen.
@Omkar Ich habe noch nie eine Kernel-Erweiterung geschrieben, daher kann ich nicht viele Ratschläge geben, außer zu sagen, dass Ihre Erweiterung gute Chancen hat, Sicherheitsprobleme zu verursachen , wenn Sie mit dem Kernel nicht besonders vertraut sind.
@CommaToast es hängt genau davon ab, wie es geladen wird. Wenn es sich um ein Element in /Library/LaunchDaemons handelt, wäre es der Pfad, nicht eine fileReferenceURL oder ein Alias. Außerdem könnte Ihr Gegner /Library/LaunchDaemons ersetzen und auf diese Weise deaktivieren, oder /private/etc ersetzen und somit die Securelevel-Einstellung beim nächsten Neustart entfernen.
@Gordon Gute Punkte. Aber alles, was Sie tun müssen, ist, /private auf schg zu setzen. Weder es noch seine direkten Kinder können geändert werden, aber seine Enkel (außer sysctl.conf) können es immer noch. Der Inhalt von /private ändert sich also nie, keine große Sache, oder? Was die Funktionsweise von Kernel-Erweiterungen betrifft, bin ich mir nicht sicher, warum wir überhaupt über sie sprechen. Nicht klar, was Okmar zu erreichen versucht.
Basierend auf dem Fehler, auf den @GordonDavisson hingewiesen hat, habe ich die Hauptantwort mit zusätzlichen Schritten aktualisiert, um das Umbenennen von /private/etc oder des /etc-Symlinks zu verhindern, mit dem die Datei sysctl.conf umgangen und festgelegt werden könnte, ohne dass dies erforderlich securelevel 0ist Firmware-Passwort. Ich habe auch einen Haftungsausschluss hinzugefügt, damit zufällige Leute, die darauf stoßen, sich keine Probleme machen.
@CommaToast Wow, ich hatte keine Ahnung, dass securelevel=1 so weitreichende Auswirkungen hat (und ich frage mich, wie viel davon auf OS X zutrifft - ich muss möglicherweise einige Tests durchführen). Das Sperren von /private und /etc sollte meine Sorge um das Ersetzen von /private/etc beseitigen, aber ich sehe keinen vernünftigen ähnlichen Weg, um zB ein Element in /Library/LaunchDaemons zu sperren. Ein System gegen einen Angreifer mit Root-Zugriff zu sperren ist wirklich sehr schwierig , und ich denke, irgendwann muss man es einfach gut genug nennen. Übrigens, Apple hat eine Hintertür, um Firmware-PWs zurückzusetzen, sie erfordern nur einen Eigentumsnachweis, bevor sie entsperrt werden.
@GordonDavisson Sobald Sie /private und den /etc-Symlink sperren und den anderen Schritten in der Antwort folgen, können Sie andere Dinge so sperren, dass sie ohne das EFI-Passwort nicht entsperrt oder gelöscht werden können. Wenn Sie also einen LaunchDaemon haben, den Sie sperren möchten, dann sperren Sie ihn einfach auf diese Weise und legen ihn in /System/Library/LaunchDaemons ab, dann sperren Sie /System/Library. Sie könnten es auch /Library/LaunchDaemons setzen und /Library sperren, aber das könnte Probleme verursachen, wenn Sie versuchen, Software zu installieren, die Dinge in /Library ablegen möchte. Aber wenn Sie sich Sorgen um die Sicherheit machen, ist das wahrscheinlich gut.