Speicher vor anderen Programmen schützen
-
be||!be schrieb:
Wie kann ich den Speicher meines Programmes (Stack & Heap) vor anderen Programmzugriffen schützen (Speicher auslesen) bzw. geht das überhaupt?
Nein, ich glaube nicht das dies möglich ist.
-
Ich versteh nur nicht, wieso man direkt auf den Speicher and zwar auf alles und mit Schreibrechten und _gesamten_ Adressbereich zugreifen will?
Jemand ist in dein System eingebrochen, das RootKit versteckt sich erfolgreich und kann nicht ueber die die normalen Systemaufrufe ausfindig gemacht werden. Fuer Spurensicherung oder zur Analyse kann der Hauptspeicher so einfach in eine Datei geschrieben werden.
-
Wie kann ich den Speicher meines Programmes (Stack & Heap) vor anderen Programmzugriffen schützen (Speicher auslesen) bzw. geht das überhaupt?
Nein, ich glaube nicht das dies möglich ist.
Sagen wir mal so: nicht direkt.
Wenn Du deinen Kritischen Anteil aber in ein externen Prozess auslagerst, den mit entsprechenden Privilegien laufen laesst, das der Normale user nicht draufkann ... erledigt halt das BS dann fuer dich.
Problem ist der Datenaustausch zwischen dem Programm im User bereich und dem im Ausgelagerten, das muss dann alles ueber IPC gehen -> aufwendiger.
Du brauchst dann aber auch immer hoeher priviligerte rechte, also zum installieren, und den Prozess starten zu lassen. Unter Linux und Windows geht das mit den Diensten / daemons ...
Meist, wenn ein Programm nen Dienst irgendwo installiert, obwohl ned offensichtlich ist, wozu es den braucht ... will es sich vor eben so speicherzugriffen schützen, oder selber Zugriff auf anderer Programme ressourcen (Speicher) haben, ohne das du es immer expliziet als Admin / root starten musst.
Nicht nur nützliche software nutzt das ...
Ciao ...
-
knivil schrieb:
Ich versteh nur nicht, wieso man direkt auf den Speicher and zwar auf alles und mit Schreibrechten und _gesamten_ Adressbereich zugreifen will?
Jemand ist in dein System eingebrochen, das RootKit versteckt sich erfolgreich und kann nicht ueber die die normalen Systemaufrufe ausfindig gemacht werden. Fuer Spurensicherung oder zur Analyse kann der Hauptspeicher so einfach in eine Datei geschrieben werden.
Dann reicht doch readonly, oder ein syscall á la write_ram_to_disk().
-
mmazal schrieb:
Dann reicht doch readonly, oder ein syscall á la write_ram_to_disk().
Deine Moeglichkeiten kuenstlich zu limitieren ist dumm. Man kann ja ueber Umwege immer direkt auf den Physikalischen RAM zugreifen wenn man die noetigen Rechte hat. Was genau spricht gegen ein Standardisiertes Interface dafuer?
-
Und wie planst du im Usermode eine virtuelle in eine physikalische Addresse umzurechnen?
Und was wenn der Speicher geswappt ist?
-
Ethon schrieb:
Und wie planst du im Usermode eine virtuelle in eine physikalische Addresse umzurechnen?
Und was wenn der Speicher geswappt ist?Was hat das mit dem Thema zu tun?
-
Shade Of Mine schrieb:
Ethon schrieb:
Und wie planst du im Usermode eine virtuelle in eine physikalische Addresse umzurechnen?
Und was wenn der Speicher geswappt ist?Was hat das mit dem Thema zu tun?
Weil er /dev/mem als die große Sicherheitslücke anpreist?
Nichtsdestotrotz bin ich neugierig obs darauf ne vernünftige Antwort gibt.
-
Ethon schrieb:
Shade Of Mine schrieb:
Ethon schrieb:
Und wie planst du im Usermode eine virtuelle in eine physikalische Addresse umzurechnen?
Und was wenn der Speicher geswappt ist?Was hat das mit dem Thema zu tun?
Weil er /dev/mem als die große Sicherheitslücke anpreist?
Nichtsdestotrotz bin ich neugierig obs darauf ne vernünftige Antwort gibt.
Ich kann meinen eigenen Speicher auf die physikalische Adresse umrechnen lassen.
Und wenn ich root bin, kann ich einfach diesen Code im Kontext des jeweiligen Prozesses laufen lassen.
-
mmazal schrieb:
Dann reicht doch readonly, oder ein syscall á la write_ram_to_disk().
Weil ich die ganzen Standardprogramme wie cat, cp, dd, grep, ... etc. benutzen kann und keine Extrawurst wie Windows brate. Ich finde beim Unixkonzept habe sich die Leute echt Gedanken gemacht, auch wenn sich der Sinn aus meiner beschraenkten Perspektive erst spaeter offenbart.