Who's Asking: Solution
Well, after all of this chasing of security issues around the internals of the OS, I guess it's finally time to reveal way to handle this problem.
The key here is recognizing that the security context information must be valid somehow during the create path. No matter what else happens above, the create IRP that is passed into the target driver (i.e. a filesystem driver, for example) must have valid security information - how else would the filesystem driver know if the requestor has permission to e.g. open the file?
Digging into the IO_STACK_LOCATION a bit, you'll find the SecurityContext member of the Create options in the big old parameters union. This is where we find the authoritative security context information present for the request. Programming an access check routine based on this information is still a little tricky, and requires a good understanding of the security model of the OS, but this is where to start.
I'd like to thank Ken Johnson, another Positive Networks coder, for lending a hand on this series of articles. This series has been fun for a few reasons - it's interesting getting to the bottom of the issues created by the asynchronous processing model of the OS, and it's an example of the principle that you should never be too sure that you know the right answer to a problem, regardless of how well your solution seems to work.
Happy hacking!
[now playing: Elephant, by the White Stripes]