3

I'm having the following setup: The DLL I'm writing is loaded dynamically at runtime and offers some API-like functionality to the host application. The host application is not running with admin rights (and therefor my DLL isn't either).

Some tasks my DLL needs to fulfill need admin rights though, specifically I have to save and copy files to the program files folder.

My current approach is to launch external applications via ShellExecute and the "runas" verb, which triggers the UAC prompt. This especially means that multiple subsequent actions triggered by the user will always result in an additional UAC prompt, which could be pretty annoying.

So the idea would be to launch a separate, elevated process once, which then runs in the background and receives the respective commands and executes them. This brings me to my question: Which methods of communication are even possible between an unelevated process and its elevated child process? Access to stdin seems to be forbidden due to obvious security reasons, but what about named pipes or shared memory? Do the same restrictions apply?

aRestless
  • 1,825
  • 2
  • 18
  • 27
  • 1
    The reason you can't use standard handles is because you're not actually the parent of the new process. Also, the integrity mechanism blocks window messages. But other mechanisms such as named pipes and shared memory will work as normal. – Harry Johnston Jun 22 '15 at 01:36
  • 2
    Make sure that your elevated slave does NOT accept arbitrary commands, otherwise you are opening a security hole wider than disabling UAC. For a safer alternative, consider elevated instantiation of a DCOM object (which then communicates only with your original process) – Ben Voigt Jun 22 '15 at 06:16
  • @BenVoigt Yeah I'm aware of the security issues. I haven't worked with (D)COM yet, would you have a pointer for me where to look how to do this (especially the restriction of communication to the parent process)? Google results are a bit... sparse. – aRestless Jun 22 '15 at 11:05

0 Answers0