Here’s something interesting I’ve found recently. It turns out that
there is a new OBJ_ flag that isn’t documented in ntdef.h, call it
OBJ_KERNEL_MODE_ONLY (0x10000). If you set this in your
InitializeObjectAttributes call, then the object you create will be
completely protected from user-mode access, even from the LOCAL_SYSTEM
account with the highest privileges possible. This can come in handy if
you need to create a protected object that you don’t want user-mode to
touch. Note that this will only work on named objects, I believe, since
this is done by the kernel setting the mask 0x4000000 to
ObjectHeaderNameInfo->QueryReferences, and that structure is only
present in the object header if the object has a name. This only works
on Windows 2003 SP1 and above, by the way, and it’s the protection used
to secure \Device\PhysicalMemory. I’m curious why it hasn’t been exposed
to all driver writers? I’ve seen horrible hacks done by some developers
to achieve this result before.
Best regards,
Alex Ionescu
Certainly is a useful flag.
For documentation, search the DDK for OBJ_KERNEL_HANDLE.
Thomas
“Alex Ionescu [397670]” wrote in message
news:xxxxx@ntdev…
> Here’s something interesting I’ve found recently. It turns out that there
> is a new OBJ_ flag that isn’t documented in ntdef.h, call it
> OBJ_KERNEL_MODE_ONLY (0x10000). If you set this in your
> InitializeObjectAttributes call, then the object you create will be
> completely protected from user-mode access, even from the LOCAL_SYSTEM
> account with the highest privileges possible. This can come in handy if
> you need to create a protected object that you don’t want user-mode to
> touch. Note that this will only work on named objects, I believe, since
> this is done by the kernel setting the mask 0x4000000 to
> ObjectHeaderNameInfo->QueryReferences, and that structure is only present
> in the object header if the object has a name. This only works on Windows
> 2003 SP1 and above, by the way, and it’s the protection used to secure
> \Device\PhysicalMemory. I’m curious why it hasn’t been exposed to all
> driver writers? I’ve seen horrible hacks done by some developers to
> achieve this result before.
>
> Best regards,
> Alex Ionescu
>
Thomas F. Divine wrote:
Certainly is a useful flag.
For documentation, search the DDK for OBJ_KERNEL_HANDLE.
That’s a different flag. OBJ_KERNEL_HANDLE inserts the object into the
system-wide object/handle table so that the kernel access it (ie: the
handle exists in the system context).
Best regards,
Alex Ionescu
Humm…
So MS has more tools (infirmation) to make their drivers secure then we
have. 
Thomas
“Alex Ionescu [397670]” wrote in message
news:xxxxx@ntdev…
> Thomas F. Divine wrote:
>> Certainly is a useful flag.
>>
>> For documentation, search the DDK for OBJ_KERNEL_HANDLE.
>>
>
> That’s a different flag. OBJ_KERNEL_HANDLE inserts the object into the
> system-wide object/handle table so that the kernel access it (ie: the
> handle exists in the system context).
>
> Best regards,
> Alex Ionescu
>
> > For documentation, search the DDK for OBJ_KERNEL_HANDLE.
>
That’s a different flag. OBJ_KERNEL_HANDLE
Yes. OBJ_KERNEL_HANDLE is IIRC 0x100 or 0x400
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com