Thema: Doku tyndur

[kevin]

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().

[FlashBurn]

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.

[erik.vikinger]

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

[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?

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

[erik.vikinger]

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

[kevin]

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.

[erik.vikinger]

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

[kevin]

Dann implementier mal (auf Linux) Programme wie su oder passwd ohne das...

[erik.vikinger]

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

[kevin]

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?

[Svenska]

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

[erik.vikinger]

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

[kevin]

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!

[erik.vikinger]

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

[kevin]

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!

[erik.vikinger]

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

[kevin]

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.

[erik.vikinger]

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

[kevin]

Ja, schon klar. Aber du musst halt immer ein komplettes Image draufspielen und kannst nicht an einzelnen Dateien rumspielen, oder?

[erik.vikinger]

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