Thema: Doku tyndur

[erik.vikinger]

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

[FlashBurn]

@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.

[erik.vikinger]

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

[kevin]

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?

[FlashBurn]

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.

[erik.vikinger]

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

[kevin]

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.

[FlashBurn]

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

[erik.vikinger]

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

[FlashBurn]

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.

[kevin]

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.

[FlashBurn]

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.

[kevin]

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.

[FlashBurn]

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.

[erik.vikinger]

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

[FlashBurn]

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.

[kevin]

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.

[FlashBurn]

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

[kevin]

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?

[erik.vikinger]

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