Private Object Namespace
One of the most common Deny Of Service (DOS) attack in Windows is kernel object name squatting.
For example, two processes want to access some shared resources. In order to keep the integrality of the shared resources, the two processes will cooperate by waiting on a named event object.
The problem is, there is no restriction on who can create the named Event object. If the two processes choose a well known name for the shared event object, a malicious application can create the event object before the two processes run. Now if any of the two processes run, it will not be able to create the event, and fail to run.
The problem is even worse, as the owners of the good processes can be administrators, and the owners of the malicious process can be a guess user and it will still work.
Complex steps have to be taken to mitigate this problem. Since you can’t choose well known name, you have to generate a random name (usually a GUID), and store it somewhere that only the owners of the good processes can be read, which requires delicate and sensitive ACL manipulation.
In short, it is very hard to securely share synchronizations between processes, even for administrators.
A solution to this problem is private object namespaces that only certain people can use. This way, you can safely create named kernel objects in the private namespace, without worrying that someone may hijack it maliciously.
In Windows Vista, Kernel team implements exact that.
Object Namespaces
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/object_namespaces.asp
This is easily my most favorite kernel change in Windows Vista.
