Lowlevel
Lowlevel => OS-Design => Thema gestartet von: ehenkes am 27. May 2009, 23:39
-
Wo finde ich eine ausfuehrliche Hintergrund-Dokumentation fuer tyndur? Was sind die grundsaetzlichen Design-Prinzipien dieses OS?
-
Trial & Error ;)
Richtige Design-Dokus gibts bislang leider nicht. Wenn du was spezielles Wissen möchtest, schau einfach im IRC vorbei (oder frag hier, aber dann brauch das mit der Antwort womöglich länger ;)).
-
Im Wiki (http://lowlevel.brainsware.org/wiki/index.php/Tyndur) gibts einen spannenden Artikel, der demnächst auch verfilmt wird.
-
Ich weiß schon wer
die Roadmap das Drehbuch schreibt. :-D :mrgreen:
-
wiki artikel ist ein guter einstieg. die design prinzipien (z.B. gemaess tanenbaum, modern os, 3rd ed.) werden aber IMHO nicht ausreichend ausfuerlich erklaert. der begriff rpc sollte verlinkt werden.
-
Ich habe bis jetzt mehr Text von Torvalds als von Tanenbaum gelesen und weiß insofern auch nicht, was letzterer genau unter Designprinzipien versteht (von ersterem weiß ich es übrigens auch nicht). Ich habe auch nicht unbedingt vor, das Buch jetzt extra zu kaufen. Vielleicht solltest du daher deine Frage etwas detaillierter und ohne Bezug auf andere Quellen formulieren, wenn du die Antwort erhalten möchtest, die du suchst.
Je nachdem du den traditionellen kernel in tyndur anschaust oder was kernel2 mal werden soll, gibt es natürlich auch Unterschiede. Die aktuelle Implementierung von kernel2 liegt irgendwo dazwischen drin.
Beim Design kann man in einem Kernel wohl auf zwei verschiedene Dinge abheben: Einmal auf die innere Struktur, die verschiedenen Einheiten, die zusammen den Kernel bilden; zum anderen die Schnittstelle zu den Userspace-Programmen, also die Syscalls.
Fangen wir mal mit dem ganz grundsätzlichen an: tyndur benutzt einen Mikrokernel, Hardwaretreiber laufen üblicherweise als ganz gewöhnliche Userspace-Prozesse. Die drei großen Einheiten im Kernel sind, wie ich das auch im Einführungsartikel im Wiki (http://lowlevel.brainsware.org/wiki/index.php/OS-Dev_für_Einsteiger#Die_Aufgaben_des_Kernels) dargestellt habe, die Speicherverwaltung, Prozessverwaltung und IPC. Dazu kommen natürlich noch so Geschichten wie Low-Level-Interrupthandling und Verwaltung der IO-Ports, also Zeug, was direkt Einfluss auf die CPU hat.
Die Speicherverwaltung benutzt auf i386 (kernel2 sieht theoretisch auch andere Architekturen vor) die hier üblichen und als richtig dargestellten Mechanismen. Speicherschutz wird über Paging erreicht, jeder Prozess hat seinen eigenen Speicherkontext, und Segmentierung wird nicht benutzt.
Die Prozessverwaltung macht nichts aufregendes - sie verwaltet eben Tasks. In kernel gibt es nur Prozesse, kernel2 kann auch Threads. Der Scheduler ist eine einfache Round-Robin-Variante. Der Kernel läuft in Ring 0, die Tasks in Ring 3. Ring 1 und 2 sind wie üblich unbenutzt.
Etwas interessanter ist vielleicht die IPC, bei einem Mikrokernel ist es ja nicht ganz unwichtig, wie die Prozesse miteinander kommunizieren. Hier sind zwei Möglichkeiten unterstützt, zum einen Shared Memory und zum anderen RPC. RPCs sind asynchron und können Daten als Parameter enthalten. Für den aufgerufenen Prozess sieht das ähnlich aus wie ein Signal unter *nix: Er wird unterbrochen, wo er gerade ist, bekommt die RPC-Daten auf den Stack gepackt und macht mit seinem RPC-Handler weiter. Wenn er fertig ist, springt er wieder zurück, wo er herkommt. Damit in kritischen Abschnitten nichts böses passiert, kann der RPC-Empfang auch blockiert werden.
Das war's eigentlich schon, was die zentralen Themen angeht. Vielleicht noch einen Blick auf die List der Syscalls (http://git.tyndur.org/?p=tyndur.git;a=blob;f=src/include/syscallno.h;h=b56ad45801c88d3140ea019c2278d6824b859fb9;hb=HEAD). Viel aufregendes ist dort nicht zu sehen, mehr oder weniger sind das die erwarteten Funktionen für den beschrieben Umfang. Was vielleicht noch interessant ist, ist der Start von Programmen und das Interrupthandling.
Der Loader für die Programme sitzt ebenfalls im Userspace und zwar momentan in init. Was der Kernel bereitstellt ist eine Funktion, um einen "leeren" Task zu erstellen. Der Loader lädt anschließend das Programm erst einmal in seinen Speicher und tritt die entsprechenden Pages dann an den neuen Task ab. Wenn er damit fertig ist, lässt er ihn loslaufen.
Für Hardware-Interrupts registriert sich der Treiber beim Kernel als zuständig. Wenn die Hardware jetzt einen IRQ feuert, sendet der Kernel einen RPC an den Treiber, der die passenden Maßnahmen ergreift, gleichzeitig sendet er aber auch ein EOI an den PIC. Damit der Interrupt nicht sofort wieder feuert, wird er maskiert. Erst wenn der Treiber aus dem RPC-Handler zurückkehrt und damit den Grund für den Interrupt hoffentlich behoben hat, wird der Interrupt wieder demaskiert.
Ansonsten könnte man zu LostIO, dem VFS, auch noch ganze Romane schreiben. Es spielt eine ziemlich zentrale Rolle, weil in tyndur sehr viel über das Dateisystem läuft. Momentan ist es komplett im Userspace (wird über RPCs implementiert), wandert aber in Zukunft als letztendlich fast wichtigste IPC-Variante in tyndur nach kernel2.
Soweit mal ein grober Überblick. Was fehlt dir noch? ;)
-
Danke, das ist genau das, was ich suche. Kannst Du noch etwas ueber pmm, vmm, swapping, heap etc. sagen? Warum ist die Speicherverwaltung im Kern? Bei MINIX z.B. im user space.
-
Naja, tyndur ist nicht so aufgebaut wie es ist weil ich ein überzeugter Mikrokernelverfechter wäre, sondern weil es uns damals praktisch erschienen ist, um saubere Schnittstellen zu kriegen und damit letztendlich besser im Team dran gearbeitet werden kann. Heute sehe ich das etwas anders, aber der Vorteil mit den klaren Einheiten bleibt trotzdem. Und das zieht sich eigentlich so durch: Wir haben das gemacht, was uns praktisch erschienen ist oder einfach genug war. Und Speicherverwaltung im Kernel kommt mir einfach wesentlich unproblematischer vor als extern.
Das physische Speichermanagement basiert auf einer Bitmap. Das virtuelle besteht halt aus dem Paging-Code wie du ihn sicher auch selbst hast. Interessanter würde das werden, wenn man tatsächlich mal Swapping einbaut, aber das haben wir noch nicht. Für malloc/free haben wir mehrere Implementierungen, die seit längerem benutzte und stabile ist liballoc. Dabei gibt es vielleicht noch zu sagen, dass wir keinen Heap im UNIX-Sinn mit brk/sbrk haben, sondern einzelne Pages beim Kernel anfordern.
-
Speicherverwaltung im Kernel kommt mir einfach wesentlich unproblematischer vor als extern.
Sehen wohl die meisten so, aber bei einem Hobby-OS koennte man auch momentan noch ineffiziente Designziele verfolgen.
Wie sieht es mit Copy-on-write - analog Linux - und eingeblendeten Dateien aus? Wie mit POSIX? Gibt es bei der zukuenftigen Thread-Verwaltung auch das pid = clone(...) von modernem Linux (seit dem Jahr 2000)?
-
Speicherverwaltung im Kernel kommt mir einfach wesentlich unproblematischer vor als extern.
Sehen wohl die meisten so, aber bei einem Hobby-OS koennte man auch momentan noch ineffiziente Designziele verfolgen.
Ich meinte auch mehr vom Entwicklungsaufwand. Was die Performance angeht, kann man natürlich auch mal eine interessantere, aber langsamere Variante wählen. Aber ganz ehrlich: Einen gcc am Laufen zu haben und ihn trotzdem kaum benutzen zu können, weil I/O so langsam ist, nervt schon tierisch, auch wenn es nur ein Hobby-OS ist.
Wie sieht es mit Copy-on-write - analog Linux - und eingeblendeten Dateien aus? Wie mit POSIX? Gibt es bei der zukuenftigen Thread-Verwaltung auch das pid = clone(...) von modernem Linux (seit dem Jahr 2000)?
Naja, erstmal sollte man festhalten, dass tyndur insbesondere aus Kernelperspektive kein Unix ist. POSIX-Funktionen werden teilweise in den Userspace-Bibliothek bereitgestellt und eben mit den nativen Funktionen emuliert.
fork() (und damit letztendlich auch clone()) ist ein ziemlich unixspezifisches Konzept, das in die native tyndur-Welt nicht reinpasst. Nur ein Beispiel, warum das nicht so richtig klappen kann: Der tyndur-Kernel hat keine Ahnung, welche Dateien ein Prozess geöffnet hat. Das Dateisystem läuft komplett im Userspace ab. Dateideskriptoren klonen wird da für den Kernel schwer.
Bei eingeblendeten Dateien sehe ich im Moment nicht den großen Nutzen, könnte man aber wohl irgendwie über Shared Memory machen. CoW kann unter Umständen auch Sinn ergeben, gab bislang aber ebenfalls keinen Bedarf dafür. Bei diesen zwei Dingen würde ich sagen, sie werden implementiert, wenn sie jemand (du?) für wichtig genug hält, es zu machen - und sonst eben nicht.
-
Danke fuer die ausfuehrlichen Antworten. Ich werde mir tyndur intensiver anschauen. :-)
-
Moin
Sorry das ich diesen Thread nochmal wieder aufwärem aber ich hab da mal ne kleine Frage.
fork() (und damit letztendlich auch clone()) ist ein ziemlich unixspezifisches Konzept, das in die native tyndur-Welt nicht reinpasst. Nur ein Beispiel, warum das nicht so richtig klappen kann: Der tyndur-Kernel hat keine Ahnung, welche Dateien ein Prozess geöffnet hat. Das Dateisystem läuft komplett im Userspace ab. Dateideskriptoren klonen wird da für den Kernel schwer.
LostIOv2 wird soweit ich weiß in den Kernel verlegt, würde dadurch nicht das "Wissen" erlagen was er bräuchte um die Dateidiskriptoren zu clonen bzw. würde sich der Aufwand ein fork() bzw. clone() zu implementieren dadurch nicht nicht stark verkleinern?
PNoob
-
Doch, das geht dann.
-
Dann will ich auch mal ;)
Also, dass der Kernel keine Dateidiskriptoren kennt und daher kein fork() geht ist nur ne faule Ausrede ;) Ich würde es einfach so lösen, dass ein fork() einfach ein RPC an den VFS-Service ist und dieser alles in die Wege leitet.
Was ich aber viel mehr interessiert, ihr habt also euren Loader im UserSpace. Wenn man nur fertig gelinkte Dateien ausführen will kann das so klappen, aber wie wollt ihr shared-Libraries (die zur Laufzeit nachgeladen werden können und lazy-linking) umsetzen?
Daran scheitert nämlich meine Idee irgendwie. Ich möchte es nämlich eigentlich genauso machen, der Kernel kann nur nen neuen leeren Task erstellen und der Loader erstellt dann das Prozess-Image. Soweit kein Problem, aber wie macht dann halt so Dinge wie Plug-ins oder halt lazy-linking (Adresse einer Funktion wird erst aufgelöst, wenn sie auch benötigt wird)?
-
Ich glaube, ich habe nie behauptet, dass man so etwas wie fork() nicht nachbauen kann. Aber es ist dann eben nicht die native Kernel-API zum Starten eines Prozesses, sondern etwas darauf aufgesetztes.
Und wegen Shared Libs, was spricht dagegen, zur Laufzeit ein paar neue Pages nachzuladen? Ich muss zugeben, dass ich mich damit nicht gut auskenne, aber ein Problem, das die Architektur dabei macht, sehe ich nicht.
-
Das Problem was ich da sehe, ist dass du ja die Symbole von dem Prozess brauchst und wo speicherst du die? Wenn du lazy-linking benutzen willst, muss dann immer auch der Teil, der das kann, vom Loader im Prozess mit gemappt sein, damit er das Symbol auflösen kann.
Der Loader müsste dann auch ein sehr spezieller Prozess sein. Denn er müsste in der Lage sein, die shared-Library zu laden, mehr oder weniger das Image zu erstellen (damit er weiß wie groß das Image ist). Dann muss er sich einen Speicherbereich, der groß genug ist, aus dem eigentlichen Prozess-Adressraum holen (er braucht die genaue Adresse, jenachdem ob du PIC oder relocateable Code nutzt), die Symbole entsprechend auflösen und dann das Image in den Prozess "geben".
Die Symboltabelle würde ich gerne im Prozess selber speichern, aber die sollte dann möglichst für den Prozess read-only sein und die muss dann auch zum Loader.
Was machst du wenn ganz viele Prozesse mit einmal den Loader benötigen (da wäre dann echt mal ein fork() zu gebrauchen)? Lässt du das alles in dem Prozess vom Loader abarbeiten oder wie wollt ihr das lösen?
Ich suche nur Anregungen ;)
-
Hm, wie wäre es, wenn der Loader selber eine Shared Lib wäre und damit außer beim Prozessstart im Kontext des Prozesses selbst läuft?
-
Das ist ja das was Linux macht (ld.so).
Nur hast du dann den Loader nicht zweimal, einmal als Programm und einmal als shared-Library?
Zumal das für mich keine Lösung ist (was ja für euch nicht weiter tragisch ist ;)), da ich es mir vorbehalten wollte, den Loader auch per Plug-Ins/Add-ons erweiterbar zu machen (so dass ich mehrere Dateiformate unterstützen kann).
Das wäre ja alles nicht so das Problem, wenn ich den Loader in den Kernel packen würde, aber das will ich halt nicht.
Eine Lösung wäre halt den Loader als einen Server/Service zu implementieren (so wie ihr es im Endeffekt ja schon irgendwie habt) und wenn ein neues Programm gestartet wird, erstellt der Loader praktisch das Image, macht nen Syscall nach der Art createNewProcess(startAddrProcess,startAddrImage,sizeImage) und wenn der Prozess dann mal dynamisch eine shared-Library nachladen will, ruft er eine Funktion auf (unter Linux glaub ich dlopen oder sowas), die in einer Library ist (das wäre der Teil der in jedem Prozess gemappt wäre vom Loader), und diese Funktion übernimmt dann die ganze Kommunikation mit dem Loader:
sagen welche Library, der Loader erstellt dann, soweit es geht, ein Image und sagt der Funktion wie groß das Image ist, die Funktion liefert dann einen Bereich (mit der virtuellen Adresse im Adressraum des Prozesses) zurück, in den dann der Loader das Image "schreiben" kann (und mit Hilfe der virtuellen Adresse kann er auch die Symbole auflösen), dann müsste noch nen Pointer (virtuelle Adresse im Sinne des Prozesses) auf die Symboltabelle an die Funktion zurückgeliefert werden
Könnte funktionieren, erscheint mir im Moment nur nicht sehr performant, aber ich hätte den Loader so als eigentständigen Prozess.
-
Das ist ja das was Linux macht (ld.so).
Nur hast du dann den Loader nicht zweimal, einmal als Programm und einmal als shared-Library?
Ist das Programm wesentlich mehr als ein dünner Wrapper um die Lib?
Zumal das für mich keine Lösung ist (was ja für euch nicht weiter tragisch ist ;)), da ich es mir vorbehalten wollte, den Loader auch per Plug-Ins/Add-ons erweiterbar zu machen (so dass ich mehrere Dateiformate unterstützen kann).
Hm, wo ist das Problem, solange das eine Format, das für die Loader-Plugins benutzt wird, immer geladen ist?
-
Ist das Programm wesentlich mehr als ein dünner Wrapper um die Lib?
Naja, wenn man es hinbekommt.
Man würde dann vom Boot-Loader den Prozess des Loaders erstellen lassen. Dieser würde aus nem Programm, welches eigentlich nur nen Service bereitstellt und ansonsten aus der Library des Loader besteht, zusammengesetzt werden. Soweit so gut. Man könnte dann die Plug-Ins vom Loader selbst laden lassen und die Symbole würde über die Library-Funktionen aufgelöst werden, würde also auch funktionieren. Aber ... wie bekommst du, außer der "Haupt"-Library, die Plug-Ins in die anderen Prozesse (die normale würdest du dort reinbekommen, indem ja alle Libraries, die benötigt werden, auch geladen werden, aber die Plug-Ins tauchen ja nicht als Library irgendwo auf)?
-
Hallo,
@FlashBurn:
Ich würde das so lösen: einen Loader für ein simples Executable-Format direkt in den Kernel, der dann aus einem Image einen neuen Prozess erstellen kann, (dieser Loader wäre auch schon während des bootens nutzbar) und im User-Space dann ein Programm das normale Executables und Librarys usw. nimmt und daraus dann das simple Format baut/zusammenlinkt und per extra Syscall dem Kernel übergibt. Für das simple Format kann man IMHO auch ELF nehmen wenn man alle nicht absolut zwingend benötigten Features, wie z.B. Relozierbarkeit, weg lässt.
Grüße
Erik
-
@erik
Eine interessante Lösung insbesondere deswegen, weil ich eine ähnliche Lösung für ein ganz anderes Problem bekommen habe und auch dort schon nicht verstanden habe, wozu ein Zwischenformat?
Was ich mir bei deiner Lösung noch schwierig Vorstelle, wie wird dann die Eltern-Kind-Beziehung geregelt? D.h. man könnte auch einfach irgendwelchen Code im Programm haben und diesen als neues Programm ausführen lassen? Was ist mit der Sicherheit (obwohl mein Gedanke wahrscheinlich kompletter Unsinn ist)?
Ich möchte es eigentlich so regeln das wirklich nur der Loader neue Prozesse starten kann. Alle die einen neuen Prozess starten wollen, müssen den Loader als ne Art Service in Anspruch nehmen. Interessant wäre es mal wie "richtige" Mikrokernel das gelöst haben, weil laut Definition gehört der Loader ja nicht in den Kernel (egal in welcher Form).
Außerdem will ich dahin kommen, das der Kernel damit nichts zu tun hat. Der Loader soll halt nur ein außergewöhnliches Programm sein, das ein paar mehr Rechte hat. Das mit den Rechten kann man ja auch irgendwie anders lösen als nachgucken ob das Programm der Loader ist, wenn ja darf er den Syscall ausführen.
-
Hallo,
also ich möchte ganz genau diesen Weg gehen und bei mir ist der Loader (heißt bei mir exec) einer der Prozesse die bereits existieren wenn der Kernel zum Leben erwacht. Den speziellen Syscall zum Erstellen eines neuen Prozess aus einem simplifizierten Executable-Format darf nur dieser Prozess aufrufen und die Parent-PID gibt exec dem Syscall als Parameter mit, selber bekommt er die PID vom IPC-Aufruf (der Kernel soll bei mir immer auch die PID des Aufrufers dem PopUp-Thread als Parameter mitgeben).
Ich finde dieses Konzept eigentlich recht gut, u.a. weil man keine Henne-Ei-Probleme hat, und ob das nun unbedingt einem Micro-Kernel nach Lehrbuch entspricht ist mir persönlich recht egal. Sicherheitsprobleme sehe ich erstmal auch keine, solange es gewährleistet ist das den speziellen Syscall nur der extra Loader-Prozess benutzen darf. Vor allem könnte der User-Space-Loader auch eine Menge an Sicherheitskram und Rechteverwaltung erledigen und dem Kernel nur noch die paar Dinge übergeben die zwingend der Kernel selber managen/durchsetzen muss.
Die Kunst dürfte im passend simplifiziertem Executable-Format liegen das der Kernel nativ unterstützen muss. Ich denke das man ELF so weit abspecken kann dass das mit ruhigem Gewissen zu vertreten ist einen solchen kleinen Loader im Kernel zu haben (er nützt ja auch was beim booten). Und wenn man mal neue Executable-Formate oder zusätzliche Features unterstützen möchte dann muss man nur den User-Space-Loader anpassen.
Grüße
Erik
-
D.h. man könnte auch einfach irgendwelchen Code im Programm haben und diesen als neues Programm ausführen lassen? Was ist mit der Sicherheit (obwohl mein Gedanke wahrscheinlich kompletter Unsinn ist)?
[...]
Außerdem will ich dahin kommen, das der Kernel damit nichts zu tun hat. Der Loader soll halt nur ein außergewöhnliches Programm sein, das ein paar mehr Rechte hat. Das mit den Rechten kann man ja auch irgendwie anders lösen als nachgucken ob das Programm der Loader ist, wenn ja darf er den Syscall ausführen.
Welches Sicherheitsproblem löst du hier? Entweder einen neuen Prozess starten ist nicht böse, warum braucht man dann ein Recht dazu? Oder es ist böse, dann würdest du den Programmen besser auch nicht erlauben, dass sie den Loader damit beauftragen, für sie was böses zu machen.
Vor allem den ersten Absatz verstehe ich nicht: Code aus dem Speicher als neues Programm starten ist böse, aber Speicher erst in eine temporäre Datei schreiben und dann den Loader diese Datei ausführen lassen ist in Ordnung?
-
Den speziellen Syscall zum Erstellen eines neuen Prozess aus einem simplifizierten Executable-Format darf nur dieser Prozess aufrufen
Das war genau das was ich meinte. Du lässt also auch nur deinen Loader diesen Syscall ausführen.
Wie taljeth, aber schon anmerkte. Was ist eigentlich so schlimm daran, wenn das auch normale Prozesse dürfen? Ich weiß es auch nicht, fand aber die Idee besser, das es nur eine Stelle darf, die ich kenne und nicht jedes dahergelaufene Programm ;)
Die Kunst dürfte im passend simplifiziertem Executable-Format liegen das der Kernel nativ unterstützen muss.
Naja, was mehr als Code, Daten, Bss und read-only Daten würden dir denn einfallen? Das würde sich doch wesentlich einfacher als über ELF lösen lassen und wenn man es dann so weit wie nur möglich vereinfacht hat, ist man wieder da angekommen, dass man kein Format braucht, sondern dem Loader einfach die Rechte gibt, Pages in den neuen Prozess zu "geben" und das wäre dann auch eine Sache, die ich nur den Loader machen lassen möchte und das wäre dann das Sicherheitsproblem was es geben könnte.
-
Hallo,
Wie taljeth, aber schon anmerkte. Was ist eigentlich so schlimm daran, wenn das auch normale Prozesse dürfen? Ich weiß es auch nicht, fand aber die Idee besser, das es nur eine Stelle darf, die ich kenne und nicht jedes dahergelaufene Programm ;)
Zum einen könnte sich dieser Syscall ja mal ändern und da der Loader-Prozess speziell zum Kernel gehört ist das gar kein Problem. Zum anderen möchte ich das mein exec-Service auch einen großen Teil der Rechte-Verwaltung mit übernimmt. Da dieser Service alle Prozesse im System kennt könnte z.B. das VFS dort nachfragen unter welcher User-ID o.ä. ein bestimmter Prozess läuft, auch möchte ich darüber z.B. das Recht verwalten ob ein Prozess direkt mit der Hardware kommunizieren darf (dieses Recht muss den Kernel mitgeteilt werden). Der pci-Service z.B. hat zwar nicht das Recht selber mit der Hardware zu kommunizieren aber er als einzigster hat das Recht Prozesse zu starten die mit der Hardware kommunizieren dürfen. Das ließe sich sicher noch um einiges erweitern, der Vorteil ist das es im User-Space liegt (der Kernel also nur ein paar elementare Rechte selber managen/durchsetzen muss) und schön zentral ist so das alle anderen Services bequem darauf aufbauen können. In wie weit sich das alles für ein Hobby-OS überhaupt lohnt ist natürlich eine andere Frage.
Naja, was mehr als Code, Daten, Bss und read-only Daten würden dir denn einfallen? Das würde sich doch wesentlich einfacher als über ELF lösen lassen und wenn man es dann so weit wie nur möglich vereinfacht hat, ist man wieder da angekommen, dass man kein Format braucht, sondern dem Loader einfach die Rechte gibt, Pages in den neuen Prozess zu "geben"
Aber diese unterschiedlichen Dinge benötigen Pages mit unterschiedlichen Attributen (z.B. Execute-Only für .code) und wie ein Prozess intern genau aufgebaut sein sollte ist meiner persönlichen Meinung nach auch eher Aufgabe des Kernels. Diesen Code benötigt man genau ein einziges mal und ob der nun im User-Space oder im Kernel-Space liegt ist da fast nebensächlich so das ich ihn lieber da haben möchte wo er thematisch hin passt und das ist IMHO im Kernel (was dann auch fürs booten ein paar Vorteile bringt).
Grüße
Erik
-
dem Loader einfach die Rechte gibt, Pages in den neuen Prozess zu "geben" und das wäre dann auch eine Sache, die ich nur den Loader machen lassen möchte und das wäre dann das Sicherheitsproblem was es geben könnte.
Also ich komm mir ja langsam blöd vor - aber wo ist das Sicherheitsproblem? ;)
Wenn man damit was böses anstellen kann, dann sehe ich eher ein Designproblem mit dem Syscall. Bugs existieren und wenn es eine Berechtigung gibt, dann wird irgendein Bug auch mal dazu führen, dass man die Berechtigung kriegt, obwohl man nicht sollte. Da hast du dann ein Sicherheitsproblem.
In tyndur darf den Syscall zum Mappen von Pages jeder Prozess benutzen, aber nur, wenn er den anderen Prozess selber erstellt hat und der andere Prozess noch nicht läuft. Dieser Syscall ist also völlig harmlos und man muss die Rechte nicht auf den Loader einschränken.
-
Aber diese unterschiedlichen Dinge benötigen Pages mit unterschiedlichen Attributen (z.B. Execute-Only für .code) und wie ein Prozess intern genau aufgebaut sein sollte ist meiner persönlichen Meinung nach auch eher Aufgabe des Kernels.
Naja, deswegen meinte ich ja auch, dass es im einfachsten Fall reicht wenn der Loader Pages in den neuen Prozess mappen darf. Was natürlich mit den entsprechenden Page-Rechten passieren sollte.
Aber was meinst du mit internem Aufbau des Prozesses? Meinst du da, wo der Code hinkommt, wo die Daten usw.? Das sollte eigentlich egal sein bzw. macht es aus der Sicht mehr Sinn, das der Kernel nicht angefasst werden muss um neue Features (ASLR oder so) zu implementieren, sondern das kann man dann schön im Loader machen.
In tyndur darf den Syscall zum Mappen von Pages jeder Prozess benutzen, aber nur, wenn er den anderen Prozess selber erstellt hat und der andere Prozess noch nicht läuft. Dieser Syscall ist also völlig harmlos und man muss die Rechte nicht auf den Loader einschränken.
Naja, ich würde das aber auch meinen Loader machen lassen, wenn der Prozess schon läuft und "einfach" nur nen Plug-In laden will.
Und ich sag mal das Recht das nur ein ganz bestimmter Prozess nen Syscall machen darf, lässt sich leichter, performanter und bug-freier implementieren, als wenn man das mit irgendwelchen Rechten (Mehrzahl!) machen würde. Denn du willst doch sicher auch nicht das jedes Programm ein neues Programm starten darf oder?
Das liegt jetzt auch ein wenig daran, wie man die Rechte oder allgemein die Sicherheit umsetzen möchte.
Es kann auch durchaus sein, das ich mal wieder ein Problem sehe wo keins ist, aber wie gesagt, eine mir bekannte und genau definierte Stelle ist mir lieber als alle dürfen ran ;)
-
Hallo,
.... Dieser Syscall ist also völlig harmlos und man muss die Rechte nicht auf den Loader einschränken.
Das sehe ich anders. Der Syscall zum Erstellen eines neuen Prozesses muss diesem Prozess auch immer ein paar Rechte mitgeben, z.B. ob er auf Hardware zugreifen darf (damit der Prozess eben HW-Speicher einblenden oder sich für IRQs registrieren kann) oder ob er root-Rechte hat (um z.B. vom OOM-Killer etwas länger verschont zu werden oder sich ausführliche Infos über laufende Prozesse holen zu können). Bei einem Micro-Kernel-OS, wo von der ganzen Rechteverwaltung möglichst wenig in den Kernel soll, ist es IMHO sehr sinnvoll im User-Space dafür eine zentrale Stelle zu haben und da bietet sich meiner Meinung nach so ein exec-Service geradezu an, eben weil der z.B. jeden Prozess im System kennt (hat ja auch alle angelegt und eine eigene Liste gepflegt).
Wenn es nur um das bloße Erstellen neuer Prozesse geht dann ist es sicher nicht sinnvoll das auf einen einzigen Prozess zu beschränken aber wenn man auch nur simples Rechtemanagement implementieren will dann ist es gut wenn man all diese Dinge an einer Stelle hat.
Naja, deswegen meinte ich ja auch, dass es im einfachsten Fall reicht wenn der Loader Pages in den neuen Prozess mappen darf. Was natürlich mit den entsprechenden Page-Rechten passieren sollte.
Okay, für ein Flat-Memory-System sollte das wohl tatsächlich ausreichen aber für meine Segmentierung ist etwas mehr nötig und ich möchte eben auch das mein Kernel explizit über das Speicher-Layout innerhalb der Prozesse bestimmt (was bei mir vor allem die Verwaltung der LDT und die Vergabe von Selectoren betrifft, beides Dinge die ich nur ungerne in den User-Space geben möchte weil dann der Kernel externe Abhängigkeiten bekommt was für einen nicht unterbrechbaren Kernel schnell in einem Deadlock enden kann). Ich sehe aber noch das Problem das wenn der Kernel nicht selber in der Lage ist neue Prozesse zu erstellen das dann das Booten etwas schwieriger wird (Henne-Ei-Probleme usw.).
Grüße
Erik
-
Habe gar nicht an dein Segmented-Memory-System gedacht. Gut da sollte der Kernel ein wenig mehr Einfluss haben, aber müsste sich das nicht genauso implementieren lassen? So dass der Loader die "Pages" in den neuen Prozess mappt?
Was das Henne-Ei-Problem mit dem Loader betrifft. Da ich ja schon den Loader brauche (zumindest dann in deinem Fall in einem vereinfachten Format) muss ich meinem Bootloader eh die Möglichkeit mitgeben, Prozesse zu erstellen. Bei mir werden das eh ein paar mehr (Kernel, Loader und mind. noch der Storage-Server).
Du willst doch eh ne lebend Geburt machen. Ich könnte sogar soweit gehen, das ich alle benötigten Prozesse vom Bootloader erstellen lasse (da kommt dann zumindest noch der Device-Server mitdazu) und alle anderen, die nicht unbedingt gestartet werden müssen, werden dann von dem "lauffähigen" System gestartet.
-
Denn du willst doch sicher auch nicht das jedes Programm ein neues Programm starten darf oder?
Wie viele Programme kennst du, die grundsätzlich nie ein anderes Programm starten? Hello World mal ausgenommen bleibt da nicht viel übrig.
-
Berechtigter Einwand, aber ich gehe mal von aus das ein Office-Programm kein anderes Programm aufruft oder ein Spiel ;)
Aber du hast schon Recht. Bleibt trotzdem die Rechteverwaltung, wo dann der Loader sagen kann, du darfst kein Programm starten.
-
Ich würde davon ausgehen, dass dein Office-Programm zum Beispiel mal lpr aufrufen möchte. Oder ein Makro, das ein externes Tool benutzt, um irgendwelche Daten zu verarbeiten. Vielleicht sind Import-/Exportfilter externe Programme. Aber wenn du es genau wissen willst, lass halt mal strace mitlaufen, wenn du OpenOffice benutzt. ;)
-
Also was das Drucken betrifft, wäre ich da wieder den Client-Server-Weg gegangen. Sprich du startest kein Programm (das ist der Unix-Weg, für alles nen Kommandozeilen-Programm zu haben und dann ne GUI drumherum zu schreiben ;)), sondern sendest eine Anfrage an einen Service.
Auch irgendwelche Makros sollten innerhalb des Office-Programms bleiben (kann natürlich sein, das ich hier total an der Wirklichkeit vorbei denke, habe nun nicht so die Erfahrung mit irgendwelchen Office Erweiterungen), sprich es sollte als Plug-In implementiert sein.
-
Hallo,
ich denke auch das erstmal jedes Programm ein neues Programm starten können sollte, solange keine rechtlichen Einschränkungen dagegen sprechen (ein Programm das unter einem normalen User läuft sollte nicht /sbin/kill aufrufen dürfen).
Aber als Beispiel für Programme die normalerweise nicht andere Programme starten möchte ich mal HW-Treiber anführen, da wäre es vielleicht wirklich ein Sicherheitsgewinn wenn solchen Prozessen dieses Recht verwehrt wird schließlich sind sie von außen erreichbar und damit ein lohnendes Angriffsziel (ein speziell präparierter Ethernet-Frame hat schon in so manchem LAN-Treiber zu lustigen Ereignissen geführt). Grundsätzlich bin ich immer der Meinung das man nur die Dinge erlauben sollte die auch wirklich benötigt werden und da wäre das Starten von neuen Programmen von Treibern ein Punkt wo ich denke das sich hier diese Erlaubnis nicht lohnt.
Habe gar nicht an dein Segmented-Memory-System gedacht. Gut da sollte der Kernel ein wenig mehr Einfluss haben, aber müsste sich das nicht genauso implementieren lassen? So dass der Loader die "Pages" in den neuen Prozess mappt?
Auch das wird nicht gehen, selbst wenn der Loader versucht ganze Segmente in einen neuen Prozess zu überführen. Zum fertig Relozieren des Codes und von vorinitialisierten Pointern werden die echten Selectoren benötigt und die bestimmt erst der Kernel (u.a. weil nur er Zugriff auf die LDT hat). In meinem konkreten Fall sehe ich keinen Vorteil darin diesen Code im User-Space zu haben und da kann ich ihn eben auch im Kernel lassen.
Was das Henne-Ei-Problem mit dem Loader betrifft. Da ich ja schon den Loader brauche (zumindest dann in deinem Fall in einem vereinfachten Format) muss ich meinem Bootloader eh die Möglichkeit mitgeben, Prozesse zu erstellen. Bei mir werden das eh ein paar mehr (Kernel, Loader und mind. noch der Storage-Server).
Du willst doch eh ne lebend Geburt machen. Ich könnte sogar soweit gehen, das ich alle benötigten Prozesse vom Bootloader erstellen lasse (da kommt dann zumindest noch der Device-Server mitdazu) und alle anderen, die nicht unbedingt gestartet werden müssen, werden dann von dem "lauffähigen" System gestartet.
Die Prozesse die bei mir noch vor der Lebendgeburt erstellt werden müssen, also vom Bootloader, müssen natürlich schon in dem simplifiziertem Format vorliegen aber das ist doch auch kein Problem. Fürs erste werden bei mir alle Executables in diesem Format vorliegen und exec muss damit nichts weiter machen als an den Kernel durchreichen. Später könnte man dann überlegen ob Librarys u.ä. mal interessant wären. Die genaue Anzahl an Prozessen die ich schon während des Bootvorgangs anlege spielt eigentlich keine Rolle für die Position des Loader-Codes, solange ich überhaupt Prozesse vom Bootloader erstellen lassen möchte ist es IMHO einfach praktisch wenn der Loader im Kernel ist. Mein Bootloader wird aus etwas Code (den ich so klein wie möglich halten möchte) und angehängten Kernel-Image + mehreren Simple-Executable-Images bestehen.
Grüße
Erik
-
Ich habe ein Problem mit dem vereinfachten Format bzw. der Umweg über ein Zwischenformat. In deiner Situation (Segmente) kann ich es nachvollziehen, dass alles im Kernel sein muss. Aber warum packst du dann nicht den eigentlichen Loader komplett in den Kernel und lässt dein exec-Prozess die Rechte und sonstige Verwaltung machen?
Ich verstehe halt einfach nicht den Sinn, wieso man ein Zwischenformat nutzen sollte, wenn man es auch gleich richtig machen kann. Bevor ich solch ein Zwischenformat nutze, packe ich alles gleich an eine Stelle.
Und desto weniger man im Kernel hat, desto weniger Bugs sind auch im Kernel. An Minix werde ich vom Code her nicht herankommen, mein Kernel ist jetzt schon wesentlich größer und noch immer nicht vollständig.
-
ich denke auch das erstmal jedes Programm ein neues Programm starten können sollte, solange keine rechtlichen Einschränkungen dagegen sprechen (ein Programm das unter einem normalen User läuft sollte nicht /sbin/kill aufrufen dürfen).
Was ist denn /sbin/kill? Ich kenne nur /bin/kill, und das sendet einfach ein Signal an Programme per kill(). Und kill() funktioniert nur auf den eigenen Programmen des Benutzers. Wenn du POSIX-Programmen kill() verbietest, funktionieren sie möglicherweise nicht mehr. Ich kenne nicht besonders viele Programme sehr detailliert, aber z.B. qemu wäre dann kaputt.
Aber als Beispiel für Programme die normalerweise nicht andere Programme starten möchte ich mal HW-Treiber anführen, da wäre es vielleicht wirklich ein Sicherheitsgewinn wenn solchen Prozessen dieses Recht verwehrt wird schließlich sind sie von außen erreichbar und damit ein lohnendes Angriffsziel
Ja, das klingt sinnvoll. Wobei diese Rechteverwaltung nicht unbedingt von außen kommen muss, sondern der Treiber kann während der Initialisierung erstmal alle Rechte droppen, die er nicht braucht.
-
Wobei diese Rechteverwaltung nicht unbedingt von außen kommen muss, sondern der Treiber kann während der Initialisierung erstmal alle Rechte droppen, die er nicht braucht.
Du kannst mir jetzt bestimmt ein Bsp nennen wo es sinnvoll ist, aber wieso sollte sich das Programm um die Rechte kümmern, die es nicht haben "will"? Alle Rechte wo du von ausgehst das sie nicht benötigt werden bzw. das sie mehr Ärger als alles andere bringen, sollten gar nicht erst dem Programm gegeben werden.
Weil so gehst du ja immer von nem netten Programm aus und du weißt wir vertrauen keinem Programm als MCP ;)
-
Wenn das Programm das nicht selber machst, brauchst du irgendeine Instanz, die entscheidet, welche Rechte das Programm beim Start maximal bekommen darf. Wonach soll sie das entscheiden? Nach dem Programmnamen?
-
Hallo,
Aber warum packst du dann nicht den eigentlichen Loader komplett in den Kernel und lässt dein exec-Prozess die Rechte und sonstige Verwaltung machen?
Mein Kernel weiß nichts über Dateien usw., das kann in meinem Konzept nur ein User-Mode-Prozess erledigen, und er soll auch nichts von dynamisch linkbaren Librarys und all dem anderen Kram wissen. Nur ASLR soll bei mir der Kernel selber machen. Das mit dem Zwischen-Format ist also eine Art Kompromiss aus den zwingend im Kernel benötigten Fähigkeiten und all dem was ich lieber nicht im Kernel haben möchte/kann. Außerdem macht dieses Zwischenformat den Bootprozess einfacher weil die ersten paar Prozesse (die schon zur Lebendgeburt vorhanden sein sollen) einfach nur in diesem Format vorliegen brauchen und schon benötigt der Bootloader keine eigenen Fähigkeiten was das Erstellen von Prozessen angeht.
Mit /sbin/kill meinte ich die Möglichkeit andere Prozesse hart zu killen (das sollte Prozessen die mit root-Rechten laufen vorbehalten bleiben) und ihnen nicht nur einfache Signale zu schicken.
Wenn die Treiber erst anfangen müssten unbenötigte Rechte zu droppen dann müssen die auch wissen was für Rechte es überhaupt gibt und welche davon sie alles haben und nicht benötigen, das finde ich irgendwie umständlich und es wäre Code der in jedem Treiber drin sein müsste (also Redundant).
Welche Rechte ein neues Programm haben soll sollte sein Ersteller festlegen und wenn der Ersteller das nicht explizit tut dann werden dessen Rechte einfach an den neuen Prozess weiter vererbt. Wenn der pci-Service z.B. einen Treiber startet dann wird er diesem neuen Prozess zwar das Recht geben HW anzusprechen (was er selber nicht darf) aber eben auch das Recht nehmen neue Prozesse zu starten. Wenn eine Konsole neue Prozesse startet dann wird die sich darum einfach gar nicht kümmern und damit einfach die eigenen Rechte vererben. Der logon-Prozess wird seinem Kind sicher die root-Rechte entziehen und ihm eine andere User-ID verpassen.
Ich denke das ist so insgesamt recht Sinnvoll.
Der Grund warum ich die Rechte-Verwaltung auch im User-Sapce haben möchte ist einfach der das sich mein Kernel nicht mit sowas rumplagen muss. Man könnte z.B. auch neue Rechte deklarieren ohne den Kernel anfassen zu müssen. Der Kernel wird sicher nichts von User-IDs oder z.B. dem Recht neue Prozesse zu starten wissen (beides managed der exec-Service). In meinem Konzept ist vorgesehen das der Kernel für jeden Prozess 2 Integerwerte hat in denen die Rechte des Prozess als simple Bit-Maske drin sind. Einer der Integerwerte wird für die CPU benutzt (und auch immer beim laden eines Threads in ein Controll-Register geladen) und enthält z.B. ein Bit dafür ob der Prozess den HLT-Befehl benutzen darf (ist nur beim idle-Prozess gesetzt) oder ob der Prozess kurzzeitig die IRQs sperren darf (darf üblicherweise jeder weil es ja für Critical-Sections von Vorteil ist). Der andere Integerwert enthält Dinge die der Kernel in Software durchsetzen muss, z.B. ob der Prozess die Syscalls für das Einbinden von Hardware benutzen darf (ist nur bei Treibern gesetzt) oder ob der Syscall zum Erstellen neuer Prozesse benutzt werden darf (ist nur bei exec gesetzt). Da der exec-Service diese 2 Integer beim Syscall immer mitgeben muss muss sich der Kernel darauf verlassen können das diesen Syscall auch nur vertrauenswürdige Prozesse benutzen können und der exec-Service muss auch immer exakt zum Kernel passen. Der Vorteil der Integerwerte ist der das diese recht einfach zu benutzen sind, im Gegensatz zu einer ASCII-basierten Rechtebeschreibung o.ä., die Gefahr von Bugs ist damit einfach ziemlich klein.
Wie wird das mit den Rechten von Kind-Prozessen eigentlich bei POSIX gemacht?
Ich vermute mal zwischen fork() und exec() mit ein paar weiteren Syscalls oder einfach gar nicht und dann wird bestimmt auch einfach vererbt.
Grüße
Erik
-
Mit /sbin/kill meinte ich die Möglichkeit andere Prozesse hart zu killen (das sollte Prozessen die mit root-Rechten laufen vorbehalten bleiben) und ihnen nicht nur einfache Signale zu schicken.
Ich fände es ehrlich gesagt auch doof, einen Admin rufen zu müssen, wenn ich mein eigenes Programm abschießen will.
Wenn die Treiber erst anfangen müssten unbenötigte Rechte zu droppen dann müssen die auch wissen was für Rechte es überhaupt gibt und welche davon sie alles haben und nicht benötigen, das finde ich irgendwie umständlich und es wäre Code der in jedem Treiber drin sein müsste (also Redundant).
Den Code in jedem Aufrufer drin zu haben ist nicht weniger redundant. ;)
Und du kannst ja eine Whitelist nehmen, also eine API, die alle Rechte droppt außer den ausdrücklich angegebenen.
Wenn der pci-Service z.B. einen Treiber startet dann wird er diesem neuen Prozess zwar das Recht geben HW anzusprechen (was er selber nicht darf) aber eben auch das Recht nehmen neue Prozesse zu starten.
Hm, wenn pci Treiber nachstartet, sollte der von pci gestartete USB-Treiber dann nicht analog seine Treiber nachstarten können? Wobei du mal erwähnt hast, dass es bei dir nur PCI gibt - tauchen USB-Geräte dann durch irgendwelche Magie als PCI-Geräte auf und pci kümmert sich um das Nachstarten?
Einer der Integerwerte wird für die CPU benutzt (und auch immer beim laden eines Threads in ein Controll-Register geladen) und enthält z.B. ein Bit dafür ob der Prozess den HLT-Befehl benutzen darf (ist nur beim idle-Prozess gesetzt) oder ob der Prozess kurzzeitig die IRQs sperren darf (darf üblicherweise jeder weil es ja für Critical-Sections von Vorteil ist).
Was heißt "kurzzeitig" und wie erzwingst du das?
Wie wird das mit den Rechten von Kind-Prozessen eigentlich bei POSIX gemacht?
Ich vermute mal zwischen fork() und exec() mit ein paar weiteren Syscalls oder einfach gar nicht und dann wird bestimmt auch einfach vererbt.
Ja, bei POSIX passiert alles interessante grundsätzlich zwischen fork() und exec(). ;)
-
Wenn das Programm das nicht selber machst, brauchst du irgendeine Instanz, die entscheidet, welche Rechte das Programm beim Start maximal bekommen darf. Wonach soll sie das entscheiden? Nach dem Programmnamen?
Ich sags mal so, ich habe mich noch nie um irgendwelche Rechte bei meinen Programmen kümmern müssen. Wie wird das denn unter Linux und Windows und anderen Betriebssystemen gemacht?
Ich würde es so handhaben, das der Prozess der exec aufruft die Rechte regelt und nicht der Prozess der durch exec gestartet wurde. Ich meine stell dir das mal vor, natürlich gibt der Wurm seine ganzen Rechte ab, damit er im System nichts anrichten kann ;)
Ich fände es ehrlich gesagt auch doof, einen Admin rufen zu müssen, wenn ich mein eigenes Programm abschießen will.
Ich habe das jetzt so verstanden dass das nicht jedes Programm darf, sprich der Virus darf nicht einfach mal das Anti-Viren-Programm und die Firewall beenden, aber du als Nutzer bist ja in dem Sinne kein Programm und wenn du die Rechte hast auf den Taskmanager (Windows-Welt und ja ich habe schon oft an PCs gesessen, wo man die Programme nicht per Taskmanager beenden durfte) zuzugreifen, dann kannst du dein Programm auch beenden ohne nen Admin rufen zu müssen.
-
Hallo,
Den Code in jedem Aufrufer drin zu haben ist nicht weniger redundant. ;)
Hä, diesen Code (zur expliziten Angabe welche Rechte der Kind-Prozess haben soll) muss man doch nur dort einbauen wo er auch benötigt wird. Im pci-Service wird das drin sein und im logon-Prozess sicher auch aber die meisten anderen Programme werden sich dafür nicht interessieren und müssen daher nichts beachten und auch keinen unnützen Code enthalten. Die API, die der exec-Service per IPC anbietet, wird die Angabe von Rechten beim Start neuer Prozesse als optional vorsehen.
Hm, wenn pci Treiber nachstartet, sollte der von pci gestartete USB-Treiber dann nicht analog seine Treiber nachstarten können? Wobei du mal erwähnt hast, dass es bei dir nur PCI gibt - tauchen USB-Geräte dann durch irgendwelche Magie als PCI-Geräte auf und pci kümmert sich um das Nachstarten?
Nein, vom pci-Service werden nur die ?HCI-Treiber gestartet welche sich dann am usb-Service anmelden, der usb-Service seinerseits darf wieder neue Prozesse erstellen und kann natürlich auch die eigentlichen USB-Geräte-Treiber starten (welche ihrerseits dieses Recht wohl nicht bekommen).
Was heißt "kurzzeitig" und wie erzwingst du das?
http://forum.lowlevel.eu/index.php?topic=2611.msg29543#msg29543 (http://forum.lowlevel.eu/index.php?topic=2611.msg29543#msg29543) ungefähr in der Mitte meines Beitrags wird das kurz beschrieben
Ja, bei POSIX passiert alles interessante grundsätzlich zwischen fork() und exec(). ;)
Also im Prinzip das selbe Verhalten was ich auch haben möchte, per Default wird einfach vererbt und wer was anderes will muss sich explizit drum kümmern.
Grüße
Erik
-
Wenn das Programm das nicht selber machst, brauchst du irgendeine Instanz, die entscheidet, welche Rechte das Programm beim Start maximal bekommen darf. Wonach soll sie das entscheiden? Nach dem Programmnamen?
Ich sags mal so, ich habe mich noch nie um irgendwelche Rechte bei meinen Programmen kümmern müssen. Wie wird das denn unter Linux und Windows und anderen Betriebssystemen gemacht?
Windows - keine Ahnung. Linux - der neue Prozess erbt die Rechte und kann sie dann droppen. Wobei man natürlich beachten muss, dass der neue Prozess mit dem fork() entsteht und man die Recht auch vor dem exec() droppen kann, also zwar im neuen Prozess, aber noch im alten Programm.
Programme, die besondere Privilegien brauchen, sind oft SUID root (das heißt, kriegen ihre Privilegien vom Kernel, nicht vom Aufrufer) und droppen danachdie Rechte, die sie nicht brauchen.
Ich würde es so handhaben, das der Prozess der exec aufruft die Rechte regelt und nicht der Prozess der durch exec gestartet wurde. Ich meine stell dir das mal vor, natürlich gibt der Wurm seine ganzen Rechte ab, damit er im System nichts anrichten kann ;)
Und du meinst, das brave Programm, das den Wurm gestartet hat, würde ihm die Rechte wegnehmen? ;)
Davon abgesehen kann ein Aufrufer natürlich nie mehr Rechte weitergeben als er selber hat.
Ich fände es ehrlich gesagt auch doof, einen Admin rufen zu müssen, wenn ich mein eigenes Programm abschießen will.
Ich habe das jetzt so verstanden dass das nicht jedes Programm darf, sprich der Virus darf nicht einfach mal das Anti-Viren-Programm und die Firewall beenden, aber du als Nutzer bist ja in dem Sinne kein Programm und wenn du die Rechte hast auf den Taskmanager (Windows-Welt und ja ich habe schon oft an PCs gesessen, wo man die Programme nicht per Taskmanager beenden durfte) zuzugreifen, dann kannst du dein Programm auch beenden ohne nen Admin rufen zu müssen.
Erik hat ausdrücklich von root-Rechten geredet. Ich hoffe, dass ich als normaler Benutzer keinen Zugriff auf einen Taskmanager mit root-Rechten habe...
-
Hallo,
sind oft SUID root (das heißt, kriegen ihre Privilegien vom Kernel, nicht vom Aufrufer)
Könntest Du das Bitte etwas näher erläutern, also das in Klammern.
Ich weiß, wir driften immer Weiter vom ursprünglichen Thema dieses Threads ab.
Davon abgesehen kann ein Aufrufer natürlich nie mehr Rechte weitergeben als er selber hat.
Was auch der Grund ist warum sich die meisten Programme nicht dafür interessieren (und dementsprechend auch keinen passenden Code enthalten), sie haben einfach keine Rechte bei denen es sich lohnen würde sie zu droppen.
Grüße
Erik
-
Vielleicht ungeschickt ausgedrückt. Eine ausführbare Datei mit SUID root (also mit gesetztem chmod-Bit 04000 und UID 0) wird mit root-Rechten gestartet, auch wenn das ausführende Programm ein unprivilegierter Benutzer ist.
-
Hallo,
Eine ausführbare Datei mit SUID root (also mit gesetztem chmod-Bit 04000 und UID 0) wird mit root-Rechten gestartet, auch wenn das ausführende Programm ein unprivilegierter Benutzer ist.
Ich nehme mal an dass das im Dateisystem (oder in der Executable selber) gespeichert ist, so dass das jeder mit physischem Zugang zum Computer ändern kann.
Das prinzipiell ein Programm root-Rechte bekommen kann ohne das der Admin da ein (Pass-)Wörtchen mitzureden hat empfinde ich persönlich als Design-Fehler. Die einzigste Situation wo das für mich Okay ist ist unmittelbar beim Booten, das die ersten paar Prozesse automatisch root-Rechte bekommen ist logisch aber dass das auch zur Laufzeit möglich ist erscheint mir eher ungeschickt.
Grüße
Erik
-
Dann implementier mal (auf Linux) Programme wie su oder passwd ohne das...
-
Hallo
ich kenne diese Tools nicht so genau aber kann man deren Funktionsweise nicht auch nach einen Client-Server-Konzept umsetzen? (der Service wurde von init mit root-Rechten gestartet und bietet dann seine Dienste an und führt natürlich auch Tests bezüglich der Rechtmäßigkeit der Anfragen aus)
Ich empfinde es einfach als ungeschickten Design-Fehler wenn es überhaupt möglich ist root-Rechte zu erlangen ohne das root dem explizit zugestimmt hat, ist aber nur mein persönliches subjektives Empfinden.
Grüße
Erik
-
Wenn root dem nicht zugestimmt hätte, hätte die Datei kein SUID-root-Flag.
Und wie prüft dein Service die "Rechtmäßigkeit"? Oder meinst du nicht einen Service, der dann passwd startet, sondern dass immer ein passwd-Service läuft, egal ob du grad dein Passwort ändern willst oder nicht? Und wo ist der Vorteil dabei - es läuft doch dann so oder so als root?
-
Hallo,
du möchtest also im Hintergrund einen Service mit root-Rechten ausführen, der beliebige Programme auf Zuruf mit root-Rechten starten kann? Das ist ein wunderbarer Angriffspunkt.
Alternativ kannst du einfach die Programme, die Root-Rechte benötigen (und dazu gehören su, passwd, login oder ping nun mal), immer als root starten lassen. Wenn das Programm bestimmte Rechte nicht benötigt, kann es sie selbst droppen. Dazu muss es die Rechte aber erstmal bekommen. Das kann man pro Programm im Dateisystem regeln (d.h. man muss das Dateisystem schützen), man kann einen Service haben (dann muss man den Service schützen) oder eine privilegierte Instanz haben.
Die Idee, das im Dateisystem zu regeln, finde ich garnicht so verkehrt. Prozesse, die aber so einen Freibrief bekommen, müssen damit verantwortungsvoll umgehen. Deswegen funktioniert das SUID-Flag z.B. nicht bei Shellscripten und es ist auch nicht auf Root beschränkt.
Gruß,
Svenska
-
Hallo,
Wenn root dem nicht zugestimmt hätte, hätte die Datei kein SUID-root-Flag.
Beweis?
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 .....
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.
Und wie prüft dein Service die "Rechtmäßigkeit"?
So wie das derzeitige passwd Programm auch, ich vermute mal das es seinen Auftrag per Kommandozeilenparameter erhält und diesen auch erst einmal auf "Rechtmäßigkeit" prüft bevor er ausgeführt wird.
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.
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.
Prozesse, die aber so einen Freibrief bekommen, müssen damit verantwortungsvoll umgehen.
Ganz genau, und deswegen könnte ich als Admin ruhiger schlafen wenn ich wirklich sicher sein kann das nur die Programme die ich erlaubt habe auch root-Rechte bekommen.
Ich bin mir nicht sicher ob mein Lösungsansatz besser ist aber der Weg über das Dateisystem bereitet mir einfach etwas subjektives Bauchweh.
Grüße
Erik
-
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 .....
Wo ist jetzt der große Unterschied, ob jemand das SUID-root-Flag für seine Datei setzt oder ob er dann eben exec mit einer manipulierten Version überschreibt? Wenn jemand physisch an den Rechner kommt und solche Dinge tun kann, hast du verloren. Punkt. Egal, welches Design.
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.
Und der Nachteil, dass du einen Service laufen hast, der an 364 Tagen im Jahr nur Ressourcen verbrät, aber nicht benutzt wird. Ein passwd-Service allein wird zwar nicht besonders groß sein, aber die Argumentation setzt sich ja auf andere privilegierte Programme fort, und Kleinvieh macht auch Mist.
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.
Wenn du auf Rechte im Dateisystem verzichtest, hast du aber sehr schnell deine privilegierten Programme durch manipulierte Versionen überschrieben. Das Dateisystem soll sich ja schließlich nicht um Rechte kümmern, freies Überschreiben für alle!
-
Hallo,
Wo ist jetzt der große Unterschied, ob jemand das SUID-root-Flag für seine Datei setzt oder ob er dann eben exec mit einer manipulierten Version überschreibt? Wenn jemand physisch an den Rechner kommt und solche Dinge tun kann, hast du verloren. Punkt. Egal, welches Design.
Ja, Du hast ja Recht, bei physischen Zugang zum Computer ist eh alles zu spät, außer man gibt die Kontrolle über den eigenen Rechner per Trusted-Computing an eine fremde Macht ab.
Wie sieht das eigentlich mit Dingen wie FUSE aus? Oder bei USB-Sticks (die können auch mit ext? formatiert sein)? Werden da solche Flags immer ignoriert?
Und der Nachteil, dass du einen Service laufen hast, der an 364 Tagen im Jahr nur Ressourcen verbrät ....
Dann eben eine White-List im exec-Service (eventuell noch mit den SHA256-Summen der Executables ergänzt), die kostet fast gar nichts.
.... freies Überschreiben für alle!
Ja, freier Speicher für freie Bytes! ;)
Grüße
Erik
-
Wie sieht das eigentlich mit Dingen wie FUSE aus? Oder bei USB-Sticks (die können auch mit ext? formatiert sein)? Werden da solche Flags immer ignoriert?
Im Detail kenne ich mich da nicht aus, vor allem was FUSE angeht, aber es gibt eine nosuid-Mountoption und die wird da angeschaltet sein. Wer genau dafür verantwortlich ist, dass das passiert, weiß ich nicht. Aber ich könnte dir auch nicht näher erklären, welche Services wie kommunizieren, damit dein USB-Stick überhaupt gemountet wird, also hat das nicht viel zu sagen. ;)
Dann eben eine White-List im exec-Service (eventuell noch mit den SHA256-Summen der Executables ergänzt), die kostet fast gar nichts.
Und die Whitelist ist wo gespeichert? Doch nicht etwa auf einem Dateisystem? Skandal! ;)
-
Hallo,
aber es gibt eine nosuid-Mountoption und die wird da angeschaltet sein
Dann müsste die aber bei vielen mounts ausgeschaltet sein. Früher als Dateisysteme noch von einer unzugänglichen Festplatte oder einem vertrauenswürdigen LAN kamen war die Welt noch in Ordnung aber Heute ist das etwas komplexer. Wimre gibt es ZFS für Linux nur als FUSE und da wäre ein permanentes nosuid sicher auch eine Einschränkung. Ich vermute mal das im Linux-Kernel (und dessen Umfeld) einige Anstrengungen unternommen werden um zu beurteilen welches Dateisystem nun vertrauenswürdig ist und welches nicht.
Mein Bauchweh bleibt erstmal. :(
Und die Whitelist ist wo gespeichert? Doch nicht etwa auf einem Dateisystem? Skandal! ;)
So wie meine derzeitige Planung meiner Plattform aussieht wird so eine White-List wohl ins OS-Boot-Image rein müssen und das liegt in einem Flash (ich hab ja (noch) kein BIOS das ein OS von einer HDD o.ä. laden könnte) und da nützt Dir noch nicht mal auslöten und umflashen etwas. Und selbst wenn Du ein anderes OS-Image startest (oder einen externen Debugger bemühst) kannst Du das gewünschte OS-Image nicht mal lesen und erst recht nicht modifizieren.
Grüße
Erik
-
Ich würde mal vermuten, dass SUID einfach nur geht, wenn root gemountet hat. Aber wie gesagt, ich kenne mich damit nicht näher aus.
Ansonsten glaube ich, dass wir an dieser Stelle mit der Diskussion aufhören können. Deine Plattform hat einfach grundlegend unterschiedliche Voraussetzungen als ein PC, wenn das OS letztendlich in einem ROM liegt. Um Sachen wie Updates und nachinstallierte Tools brauchst du dir keine Gedanken machen, weil es ja eh nicht geht, sondern das gesamte OS in einmal festgelegter Form und Umfang unveränderlich da ist.
-
Hallo,
sondern das gesamte OS in einmal festgelegter Form und Umfang unveränderlich da ist.
Da hab ich mich wohl ungeschickt ausgedrückt. Den Flash-Inhalt kann man natürlich durchaus ändern (ist ja kein ROM). Wie sollte ich auch sonst mein OS überhaupt entwickeln können? Änderungen am Flash-Inhalt gehen aber nur mit dem richtigen Passwort und jedes Image wird von der Hardware individuell geschützt so das sich zwei parallel installierte OSe nicht gegenseitig beeinflussen können.
Ansonsten glaube ich, dass wir an dieser Stelle mit der Diskussion aufhören können.
Okay, da hast Du recht. An der derzeitigen suid-Flag-Implementierung von POSIX wird keiner von uns was ändern können und wie man das in seinem eigenen OS realisiert ist jedem selbst überlassen.
Grüße
Erik
-
Ja, schon klar. Aber du musst halt immer ein komplettes Image draufspielen und kannst nicht an einzelnen Dateien rumspielen, oder?
-
Hallo,
Aber du musst halt immer ein komplettes Image draufspielen und kannst nicht an einzelnen Dateien rumspielen, oder?
So ein OS-Image besteht aus einem kleinen Header, etwas Code und eben einem Kernel-Abbild + mehreren Simple-Executables. Diese Dinge sind einfach aneinander gereit so das es theoretisch möglich wäre einzelne Komponenten zu manipulieren aber schon allein die Block-Größe des Flashs wird dem Grenzen auferlegen. Die unterschiedlichen Images können problemlos individuell manipuliert oder gelöscht oder neue angelegt werden.
Grüße
Erik
-
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
-
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