The Solution

There are two ways that have been identified that could correct this issue. The first, and most plausible, would be for McAfee to modify their driver such that it will refuse to acquire a handle to a process object if the OB_FLAG_CREATE_INFO bit is set in the process' object header Flags attribute. The downside to using this approach is that it requires McAfee to make use of undocumented structures that are intended by Microsoft to be opaque, and for good reason. However, the author is not currently aware of another means by which an object's creation state can be detected using general purpose API routines.

The second approach, and it's one that should at least result in a bugcheck within nt!ObInsertObject, would be to check to see if the object's OB_FLAG_CREATE_INFO bit has been cleared. If it has, an alternate action can be taken to validate the object's access mask. If it hasn't, the current method of validating the access mask can be used. At this point in time, the author cannot currently speak on what the alternate action would be, though it seems plausible that there would be another means by which a synonymous action could be performed without relying on the creation information in the object header.

In the event that neither of these solutions are pursued, it will continue to be necessary for protagonistic developers to avoid performing actions between nt!ObCreateObject and nt!ObInsertObject that might result in file operations being performed from within the new process' context. One of a number of work-arounds to this problem would be to post file operations off to a system worker thread that would then inherently run within the context of the System process rather than the new process.