Legen Sie es auf eine CD oder eine DVD. Die einmal beschreibbaren, nicht die löschbaren. Oder eine andere Art von Nur-Lese-Gerät.
Ok, ich nehme an, Sie wollen eine Softwarelösung, also hier sind einige Ideen:Sie könnten möglicherweise einen SELinux-Regelsatz erstellen, der den Systemaufruf chattr deaktiviert verwendet, sogar für root. Eine andere Möglichkeit wäre die Nutzung von Capabilities:Setzen von +i erfordert den CAP_LINUX_IMMUTABLE Wenn Sie also die Fähigkeitsbegrenzungsmenge aller Prozesse so einrichten können, dass sie diese nicht enthält, kann niemand diese Flags ändern. Aber Sie brauchen Unterstützung von init dass dies für alle Prozesse gilt. Systemd kann das, aber ich denke, es müsste für jeden Dienst separat gemacht werden.
Wenn Sie dies jedoch tun, denken Sie daran, dass ein normaler Root das Dateisystem vom Raw-Gerät modifizieren kann (das ist, was debugfs ist für), also müssten Sie auch das verhindern, ebenso wie das Verändern des Kernels (Laden von Modulen). Das Laden von Modulen kann mit dem kernel.modules_disabled verhindert werden sysctl, aber ich bin mir nicht sicher, ob ich den Zugriff auf Raw-Geräte verhindern soll. Und machen Sie alle relevanten Konfigurationsdateien auch unveränderlich.
Wie auch immer, danach müssten Sie auch verhindern, dass Sie die Art und Weise ändern, wie das System bootet, sonst könnte jemand das System mit einem Kernel neu starten, der es erlaubt, die obigen Einschränkungen zu überschreiben.
Es gibt keine Möglichkeit, dies zu tun. JEMAND wird immer in der Lage sein, die Datei in einen beschreibbaren Status zurückzusetzen, es sei denn, sie befindet sich auf einem schreibgeschützten Medium wie einer CD-ROM. root können Sie effektiv verhindern davon abhalten, dies mit SELinux-Berechtigungen zu tun (ich weiß nicht, wie das geht, oder ich würde ein Beispiel geben), aber dann könnte der Benutzer, der Berechtigungen hat, immer noch Dinge rückgängig machen.
Was Sie wollen, ist eine obligatorische Zugriffskontrolle. Es erlaubt Ihnen, eine Reihe von Berechtigungen anzugeben, deren Überschreiben der Kernel nicht zulässt, nicht einmal von Root. SELinux ist ein bekanntes derartiges System, Smack ist ein weiteres Beispiel und AppArmor ist ein drittes derartiges System. In Linux werden sie als Linux-Sicherheitsmodule implementiert, eine Allzweckeinrichtung zur Steuerung des Zugriffs außerhalb des traditionellen UNIX-ähnlichen Sicherheitsmodells. Zusätzlich zu den vorhandenen Allzwecksystemen können Sie natürlich auch Ihre eigenen für einen speziellen Zweck erstellen.
Natürlich hat root die Möglichkeit, die gesamte Einrichtung ein- oder auszuschalten oder die MAC-Berechtigungen von Dateien zu ändern, und einige dieser Systeme erlauben es sogar, dass diese Fähigkeiten Nicht-Root-Benutzern gewährt werden. Je nach System ist es jedoch auch möglich, diese Fähigkeit zu deaktivieren. Ich weiß, dass SELinux und Smack dies ermöglichen; Ich bezweifle, dass alle LSMs dies tun. Nach der Deaktivierung besteht die einzige Möglichkeit, die Fähigkeit wiederzuerlangen, darin, den Kernel neu zu starten. Sie möchten dann, dass Ihr Boot-Prozess die Funktion deaktiviert, bevor der Benutzerzugriff aktiviert wird. Wenn Ihr Kernel und Ihr Boot-Prozess sicher sind, könnte eine solche Konfiguration (zumindest theoretisch) nur geändert werden, indem Sie das Speichermedium physisch entfernen, um es zu ändern.
Wenn Sie beispielsweise SMACK verwenden, könnten Sie Folgendes tun:
chsmack -a _ <file>
Dies würde die Datei so einstellen, dass sie das spezielle Label "_" hat, das nur Lese- oder Ausführungszugriff erlaubt, aber niemals Schreibzugriff. Jetzt kann nicht einmal root diese Datei schreiben (sobald SMACK aktiviert und die Fähigkeit zum Überschreiben der Sicherheit, wie oben erwähnt, deaktiviert wurde).
Sie müssen jedoch auch sicherstellen, dass Ihr Kernel sicher ist. Standardmäßig ist es für root einfach, den Kernel zu unterwandern, weil der Kernel dem Root-Benutzer vertraut. Wenn root das Sicherheitsmodul einfach entfernen kann, hilft das nicht viel. Eine Liste solcher Methoden finden Sie hier, aber beachten Sie, dass eine solche Liste niemals wirklich vollständig für alle Umstände sein kann.
Schließlich müssen Sie je nach Ihren Umständen möglicherweise Ihren Startvorgang sichern. Für eine Maschine, auf die Sie nur physischen Zugriff haben, ist dies möglicherweise nicht erforderlich, aber für maximale Sicherheit möchten Sie wirklich verschlüsselte Dateisysteme und eine sichere Methode zum Booten des Kernels, z. B. UEFI Secure Boot.