> So let me get this straight. > > Allowing unpriveleged processes to send control messages to priveleged > processes is not a flaw in the Win32 API because there is a mechanism > for applications to protect themselves from this type of attack > (alternate Windows Stations/Desktops). > > But the mechanism effectively prevents the priveleged processes from > providing a GUI because the user won't be able to actually see the > alternate Windows Stations/Desktops without some kind of Station > switching tool, and/or extra training in how to do this. > > So, the result is that no applications actually use this mechanism. > > What part of "this is broken" doesn't make sense?
Well, there is a Right Way of controlling privileged processes from the user's desktop. Simply banging a window up on the desktop is not the Right Way. There should be a separate UI/management tool which runs under the user's credentials on his desktop and uses some IPC mechanism to control the privileged process (RPC, DCOM, named pipes, tcp sockets, whatever). This IPC interface is the security boundary. To make an analogy in the Unix world, it would be like a deamon running as root opening an xterm on the users desktop to manage it. Nobody would say "X is broken" in this case - I think we'd all agree that the app is broken. Later, Kenn
