Thema: Doku tyndur

[Svenska]

Wenn root dem nicht zugestimmt hätte, hätte die Datei kein SUID-root-Flag.

Beweis?

Beweis, dass dein Privilegierungsservice nicht manipuliert wurde?

Spätestens wenn jemand physischen Zugang zum Computer hat und nen USB-Stick anschließen kann oder wenn das Dateisystem per LAN gemountet wird oder wenn bei einem Micro-Kernel-OS ein beliebiges Programm selber ein Dateisystem (das nur die eigene Executable um SUID-root-Flag bereichert enthält) anbietet und dem VFS-Service unterschiebt (in Linux gibt es FUSE) oder .....

Wenn jemand physisch vom USB-Stick bootet, hast du verloren. Das SUID-Flag kannst du nur als Root setzen, via LAN wird es ebenfalls nicht exportiert (höchstens bei NFS, aber da ist normalerweise root==nobody, geht also auch nicht). Und es gibt Mountoptionen wie z.B. nosuid oder noexec, die nicht vertrauenswürdige Dateisysteme vor SUID-Root-Dateien schützen.

Konkret musst du als Administrator dafür sorgen, dass bestimmte Dateisysteme vertrauenswürdig immer sind (da ist schließlich das System drin), das musst du bei deiner Lösung aber auch. Alle anderen Dateisysteme (USB-Sticks, CDs, ...) müssen immun sein. Und da sonst keiner am Flag rumspielen kann, ist die Angriffsfläche nicht besonders groß - der Nutzen aber sehr groß bei simplem System.

Ich halte dieses Konzept immer noch für einen Designfehler. Mir ist klar das typische Computer zu der Zeit als POSIX erdacht wurde noch in einem extra Raum standen und die normalen User nur per Terminal ran konnten.

Wie willst du dein OS denn schützen? Mit einem ersetzbaren Trusted-Computing-Server, am besten noch "exec" mittels TPM-Modul an das System binden?

Bisher wurde jedes System geknackt.

Der Vorteil eines permanent laufenden Services ist der das man dafür keinen Mechanismus benötigt der es ermöglicht einen Kind-Prozess mit root-Rechten zu erstellen obwohl man selber keine root-Rechte hat und auch root dem nicht explizit zugestimmt hat.

Ich finde den Gedanken, jeden Pups in einen Service auszulagern falsch. Auch mit modernen Ideen wie Start/Stop "on demand" oder sowas. Sowas ist Ressourcenvergeudung und treibt den Aufwand hoch. Insbesondere Basisfunktionalität, die du speziell ausschließlich einem einzigen Service zur Verfügung stellen müsstest ist da m.M.n. falsch aufgehoben.

Die Idee, das im Dateisystem zu regeln, finde ich garnicht so verkehrt.

Ich schon, das Dateisystem ist IMHO dafür da die Daten zuverlässig zu speichern und nicht dafür Rechte durch zu setzen.

Och, so rechte wie "lesbar", "schreibbar", Eigentümer gehören schon an die Dateien gebunden. Oder möchtest du für jeden Nutzer ein eigenes Dateisystem (Container) benutzen?

Ich bin mir nicht sicher ob mein Lösungsansatz besser ist aber der Weg über das Dateisystem bereitet mir einfach etwas subjektives Bauchweh.

Er ist aufwändiger und tut im Endeffekt das gleiche.

Du hast nur einen Angriffspunkt mehr: Den Privilegienservice. Ansonsten kann man trotzdem die privilegierten Anwendungen angreifen, das ändert also nix.

PS: Hab gestern nacht ständig einen HTTP 503 bekommen...

Gruß,
Svenska

[erik.vikinger]

Hallo,


wie mein Boot-Device intern genau aussehen soll hab ich mir noch nicht bis ins letzte Detail überlegt aber im wesentlichen soll es da eine hardware-verwaltete Möglichkeit geben OS-Images abzulegen. Die Hardware stellt sicher das niemand ein Image lesen kann (außer der UrBoot-Loader der unmittelbar nach dem Reset kommt und den gesamten Flash sperrt nachdem er das gewünschte Image in einen RAM kopiert hat um es danach dann auszuführen) und Schreiben soll man ein Image auch nur einmal können (unmittelbar nach dem Anlegen). Das neu Anlegen von Images soll im Prinzip ganz problemlos gehen und das Löschen eines Images nur mit einem Passwort (das beim Anlegen mit angegeben werden muss). Für das Lösch-Password sind 512 Bit sicher ausreichend. Die Hardware, zusammen mit dem UrBoot-Loader (der in einem echten ROM liegt), stellen dem nicht manipulierbaren OS-Image also eine saubere Start-Umgebung zur Verfügung, was das OS dann macht ist seine Angelegenheit.

Das einzigste was mir noch etwas Kopfzerbrechen bereitet ist wie man z.B. Chain-Loading hinbekommen kann. Ich würde es gerne ermöglichen das der UrBoot-Loader ein Image startet aber dieses gar kein OS sondern eine Art Boot-Manager enthält welcher den User fragt welches OS-Image er denn gerne gestartet haben möchte (dazu muss dieser Boot-Manager natürlich alle benötigte Hardware selber in Betrieb nehmen und am Ende wieder deaktivieren, so wie der UBoot das macht). Es muss also eine Möglichkeit geben das System zu reseten (damit es sich wieder in einen garantiert sauberen Zustand befindet) und eine einmalige Image-Auswahl dem UrBoot-Loader unter zu schieben. Auch müsste man diesen Auswahl-Mechanismus von Außen (mit zusätzlicher Hardware) manipulieren können um z.B. ein nicht funktionsfähiges OS-Image abzuwählen. Wenn man dann noch Dinge wie Suspend-to-RAM/Disk unterstützen möchte, wo es wichtig ist das der UrBoot-Loader beim nächsten Anfahren wieder genau das selbe OS-Image startet wie zuletzt, wird es einigermaßen kompliziert. Hier muss ich wohl noch ein wenig grübeln.

Wenn man das ganze ordentlich umsetzt sollte dieses System schon recht sicher sein, man müsste auf jeden Fall einen enormen physischen Aufwand treiben um da was umgehen zu können. Trotzdem wird man mit Sicherheit auch dieses Konzept knacken können, da gebe ich mich keinerlei Illusionen hin, wichtig ist mir nur das der Aufwand möglichst hoch ist damit sich das nicht lohnt bzw. damit das nicht unbemerkt durchgeführt werden kann (damit wenigstens nicht heimlich der BND oder die neugierige Ehefrau einen Key-Logger installieren können).


Das mit dem permanent laufenden Service für Dinge wie passwd ist wohl insgesamt auch keine so gute Idee (Ressourcenverschwendung usw.), da erscheint mir momentan eine simple White-List im exec-Service (der ja Teil des geschützten OS-Image ist) noch die geschickteste Wahl. Die Auswahl der Programme mit gesetztem SUID-root-Flag wird root doch sicher nicht andauernd ändern wollen.


Grüße
Erik


PS.: ich hatte gestern Abend nur 2 oder 3 mal einen 503