It would be rather odd for an app to startup a child just to do the actual printing. That is why the print spooler was created in the first place. I'm not saying someone hasn't done it, but we haven't seen one.BUCKAROO wrote: Tests show that session in 4.17.5 seems to mean for only this process [pid] (not for others in the Sandbox). Therefor if an application creates a new slave process each time to print, then it will NEVER be able to print. I don't know how common that is, so I don't want to be critical about a work-in-progress. I think it's an improvement and removing the property sheet was a well-thought-out move.
I first tried to block just StartDocPrinter -- actually the lower level RpcStartDocPrinter. During testing, I discovered 2 more RPC API's that will also allow you to print to file via the spooler. They are documented, but they are buried deep and it wasn't clear at all that they allowed print to file. So then I asked myself, "well who knows what other surprise API's lurk in the bowels of Windows?" That's the problem with sandboxing the spooler as well. We can't be sure that what we are letting through is not dangerous.BUCKAROO wrote: Glad to see it's catching and stopping printer driver install from 4.17.4 and hopefully onwards. I'm not going to dig any further... Except to say, bouncing spoolss completely and IPCing with an unsandboxed Sbie server would have been my choice - keeping it user-mode and with one more SYSTEM service closed off completely save for printing actions determined by user.
@Curt, can not Sbie block until user responds to prompt? StartDocPrinter is a blocking function anyway [Pity the UI if same thread - so I guess not advisable] - is not appropriate driver asynchronous and runs within the very thread it was entered from ? [Little to do with keeping Windows Messages pumping, I know] I have not much clue about these things (and not much desire to learn) so don't feel like you need to respond to this. What if the driver makes a copy of the print buffer whole somewhere, say, in a dummy process, effectively swallowing the calls ahead of user decision and then playing them back based on positive answer/setting ?
I decided to attack it from the other end and switched to having the Sbie minifilter driver block all print to file requests that come from a sandboxed app. That way, no matter what method a hacker can dig up, the print spooler is not allowed to write to the host. But the minifilter can't wait on a user to press ok.
