Prozess mit eigener ACL?



  • Hallo.
    Ich habe folgendes Problem/Frage: ich habe einen host-process. Der machst nichts anderes als einen Satz an plugins (Dlls) zu laden die dann irgend was machen.
    Ich möchte nun den Zugriff dieser DLLs auf das System etwas einschränken. Im speziellen geht es mir darum zu verhindern, dass eine DLL aus einem Folder geladen wird der bei mir auf der "backlist" steht. Eine Option wäre ein User account der einfach keine Rechte für diese Folder besitzt und den Prozess unter diesen User zu starten. Das ist mir aber zu umständlich, da sich das Programm wie bei "normalen" User verhalten soll, minus Zugriff auf einem "blacklist" und deshalb die beiden User ACLs immer synchron halten müssten ect. (läuft irgendwie immer auch Service raus der mitlauscht, das ist mir aber zu viel aufwand....)

    Kennt jemand irgend eine Möglichkeit prozessweit den Zugriff auf einen bestimmten Folder zu verhinden? Am besten würde mir eine Art prozess-globale ACL gefallen in welcher die blacklist folder einfach auf "kein zugriff" stehen und damit keiner innerhalb des Prozesses mehr dort ran kommt.
    Bin aber auch mit allem andern zufrieden das mich zum geschünschten Ergebniss bring ohne irgend was rießiges um das mini-tool raum bauen zu müssen 🤡
    Thx!



  • CMatt schrieb:

    Eine Option wäre ein User account der einfach keine Rechte für diese Folder besitzt und den Prozess unter diesen User zu starten.

    Das ist der einzig sinnvolle Weg.


  • Mod

    Warum willst Du es so tief und sicher mit den Rechten abschotten.
    Wenn Du die Kontrolle hast, der die DLLs lädt, hindert Dich doch nichts die DLLs eben nicht zu laden... 😉



  • Martin Richter schrieb:

    Warum willst Du es so tief und sicher mit den Rechten abschotten.
    Wenn Du die Kontrolle hast, der die DLLs lädt

    Das ist ja mein Problem: die habe ich nicht. Ich mache einfach ein CoCreateInstance, um das lade kömmert sich COM. Dieser 'spezielle' Prozesses liefert alles was er braucht per reg-free COM mit. Parallel dazu gibt es einen Satz an globalen COM Objekten, welche von den "nicht speziellen" Prozessen verwendet wird. Was ich verhindern will höhrt sich simpel an: wenn ein bestimmtes COM Objekt nicht mitgelifert wird soll ein Fehler zurückkommen und NICHT die registrierte version verwendet werden => ich möchte einfach nur verhindern, dass ein Prozess in der lagen ist COM Objekte aus einem bestimmten Folder zu laden.
    Klar gibt es da noch x andere Ansätze wie ein MyCoCreateInstance das checkt wo das Objekt her kommt ect. aber ich fände es viel schöner wenn ich das irgendwie anders lösen könnte als direkt in den plugin dlls.
    Ob ich das irgendwie über die DCOM Security settings zu stande bekomme wenn es keine Möglichkeit gibt einen Prozess mit in die ACL auf zu nehmen?


  • Mod

    Dann mach es doch einfacher:
    Prüfe einfach von wo das Objekt geladen werden soll. Da es sich um vermutlich sowieso um CLSCTX_INPROC_SERVER und CLSCTX_LOCAL_SERVER handelt kanst Du das doch ganz einfach kontrollieren.



  • Prüfe einfach von wo das Objekt geladen werden soll.

    Habe ich jetzt gemacht. Ich habe die IAT umgebogen und checke jetzt bei jeden LoadLibrary erst mal ob die irgendwo liegt wo der Prozess nicht ran darf und erst dann geht es weiter an die kernel32.dll
    Machmal ist wohl doch der Holzhammer die einzige Lösung 🤡


  • Mod

    Ich würde sagen, dass hier diese Methode genau die richtige ist 😉 obwohl ich sonst nicht für so etwas plädiere. Aber das ist in diesem Fall mit Sicherheit die elegantere Lösung.

    BTW: Du kannst dies auch vorher in der Registry prüfen... Das weißt Du?



  • Du meinst in CoCreateInstance? Wollte ich erst auch, war mir dann aber zu unsicher da ich nicht weiß was die COM Runtime da intern noch so alles macht (die braucht ja nur aus irgend einem Grund einen proxy/stub an CoCreateInstance vorbei hoch zu ziehen und schon wirkt hook nicht mehr - mit LoadLibrary erschlage ich gleich alles was versucht DLLs zu laden 🤡 ).


  • Mod

    CMatt schrieb:

    Du meinst in CoCreateInstance? Wollte ich erst auch, war mir dann aber zu unsicher da ich nicht weiß was die COM Runtime da intern noch so alles macht (die braucht ja nur aus irgend einem Grund einen proxy/stub an CoCreateInstance vorbei hoch zu ziehen und schon wirkt hook nicht mehr - mit LoadLibrary erschlage ich gleich alles was versucht DLLs zu laden 🤡 ).

    Wie kann ein Objekt an CoCreateInstance vorbei einen Proxy hochziehen? Gar nicht!

    BTW: Dein Verfahren funktioniert übrigends nicht, wenn Dein Server Out of Process ist. Oder in einem anderen Process erzeugt oder gehostet wird.
    Dann würde aber auch die ACL Methode umgangen. Das ist auch klar, weil Dein Prozess nicht mehr der Owner ist.



  • Martin Richter schrieb:

    CMatt schrieb:

    Du meinst in CoCreateInstance? Wollte ich erst auch, war mir dann aber zu unsicher da ich nicht weiß was die COM Runtime da intern noch so alles macht (die braucht ja nur aus irgend einem Grund einen proxy/stub an CoCreateInstance vorbei hoch zu ziehen und schon wirkt hook nicht mehr - mit LoadLibrary erschlage ich gleich alles was versucht DLLs zu laden 🤡 ).

    Wie kann ein Objekt an CoCreateInstance vorbei einen Proxy hochziehen? Gar nicht!

    CoGetClassObject (müsste man dann natrürlich auch hooken). Aber darum geht es mir eigentlich gar - bei mir hat sich die über letzten Jahre nur eine Art natrürliches misstrauen gegen die COM Runtime und deren Benutzer entwickelt und bevor ich im nachhinein auf einen irgend nem Hack in COM stoße der was macht was er nicht sollte gehe ich lieber gleich auf Nummer sicher;)

    Out of process ist kein Problem, in dem speziellen folder liegen nur inproc's.
    Thx für den schubs in die richtige richtung 😉


Anmelden zum Antworten