GetSecurityInfo and device object namespace

NTDEV
1

I encountered a strange issue when the device is opened using interface name + a name within associated namespace. It is well known that in such a case OS doesn’t check the device ACL and leaves it on driver. To avoid security problems FILE_DEVICE_SECURE_OPEN flag in the device characteristics was introduced. If set, OS makes the same security check for both device and its namespace.

So far so good. But when GetSecurityInfo() or NtQueryObjectSecurity() is used with a device handle opened using a name from the namespace, it doesn’t return device security info as expected but empty DACL, instead. It seems as OS properly checks device access but ignores security queries which leads to inconsistent results. Tested at Win7 but I presume the same for previous versions.

BTW, I encountered it with a driver which uses interface reference string to distinguish which interface was used to open the device (recommended technique). It made crazy a new WLK tool which checks if a biometric device is properly secured.

To me it looks like an OS fault, although not fatal. IMO it should check for the FILE_DEVICE_SECURE_OPEN flag and return device security info for whole namespace. Or am I missing something?

Michal

NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/

2

I am guessing that you need to handle IRP_MJ_QUERY_SECURITY and handle queries on your namespace (probably the io manager handles the query on the root, ie your device object name itself, and delegates remaining queries to the namespace provider), even though you are not an FS driver. The MSDN docs seem to confirm this guess, http://msdn.microsoft.com/en-us/library/ff549298(VS.85).aspx. It says:

The IRP_MJ_QUERY_SECURITY request is sent by the I/O Manager. It can be sent, for example, when a user-mode application has called a Microsoft Win32 function such as GetSecurityInfo.

d

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of Vodicka, Michal [xxxxx@authentec.com]
Sent: Friday, April 01, 2011 9:22 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] GetSecurityInfo and device object namespace

I encountered a strange issue when the device is opened using interface name + a name within associated namespace. It is well known that in such a case OS doesn’t check the device ACL and leaves it on driver. To avoid security problems FILE_DEVICE_SECURE_OPEN flag in the device characteristics was introduced. If set, OS makes the same security check for both device and its namespace.

So far so good. But when GetSecurityInfo() or NtQueryObjectSecurity() is used with a device handle opened using a name from the namespace, it doesn’t return device security info as expected but empty DACL, instead. It seems as OS properly checks device access but ignores security queries which leads to inconsistent results. Tested at Win7 but I presume the same for previous versions.

BTW, I encountered it with a driver which uses interface reference string to distinguish which interface was used to open the device (recommended technique). It made crazy a new WLK tool which checks if a biometric device is properly secured.

To me it looks like an OS fault, although not fatal. IMO it should check for the FILE_DEVICE_SECURE_OPEN flag and return device security info for whole namespace. Or am I missing something?

Michal

NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

I think Michal’s point is that this makes the security handling inconsistent, and this query should be answered by the I/O Manager when FILE_DEVICE_SECURE_OPEN is set.

For IRP_MJ_CREATE, he’s not handling the security for his name space… the I/O Manager is, due to the setting of FILE_SECURE_DEVICE_OPEN in the Device Object.

So, he COULD handle the IRP_MJ_QUERY_SECURITY… but he’d almost certainly have quite a lot of work to do there. For one thing, he’d have to discover what the protection on his Device Object actually IS, as the I/O Manager (not his driver) is responsible for setting it (using info from the Registry, from the INF file, and/or from IoCreateDeviceSecure or the WDF equivalent). Given, then, that he’s not the one who’s ultimately DEFINING the security for his devnode, he really isn’t the right one to be answering queries about that security, right?

Sounds to me like Michal has a good point… One that *I’ve* certainly never considered before.

Peter
OSR

4

All fair points, but for an already released os, I dint think you will see a patch to alter this behavior. Since the wlk test seems to require this, I was providing a solution for the problem at hand. I will bring this up to see if something can be done in the future.

d

dent from a phine with no keynoard

-----Original Message-----
From: xxxxx@osr.com
Sent: Saturday, April 02, 2011 1:08 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] GetSecurityInfo and device object namespace

I think Michal’s point is that this makes the security handling inconsistent, and this query should be answered by the I/O Manager when FILE_DEVICE_SECURE_OPEN is set.

For IRP_MJ_CREATE, he’s not handling the security for his name space… the I/O Manager is, due to the setting of FILE_SECURE_DEVICE_OPEN in the Device Object.

So, he COULD handle the IRP_MJ_QUERY_SECURITY… but he’d almost certainly have quite a lot of work to do there. For one thing, he’d have to discover what the protection on his Device Object actually IS, as the I/O Manager (not his driver) is responsible for setting it (using info from the Registry, from the INF file, and/or from IoCreateDeviceSecure or the WDF equivalent). Given, then, that he’s not the one who’s ultimately DEFINING the security for his devnode, he really isn’t the right one to be answering queries about that security, right?

Sounds to me like Michal has a good point… One that *I’ve* certainly never considered before.

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

Agreed.

Yeah… ugh. Maybe somebody wants to write some generic code for this and make it available to the community. Since Michal’s gonna have to write it, maybe he’d like to make an article for The NT Insider out of it :slight_smile:

Thanks, that was the purpose of my follow-up, actually.

Peter
OSR

6

If there a status or an ACL that would mean “inherit from parent”?

7

Yes… inheritance in a DACL is described in the security descriptor control flags. See

SE_DACL_AUTO_INHERIT_REQ
SE_DACL_AUTO_INHERITED
SE_DACL_PROTECTED

described in

http://msdn.microsoft.com/en-us/library/aa394402(v=vs.85).aspx

Peter
OSR

8

Thanks, Peter. This is exactly what I meant but you wrote it much more clearly.

Yes, if I/O Manager handles security during opens because of FILE_DEVICE_SECURE_OPEN set, it should also handle appropriate IRP_MJ_QUERY_SECURITY requests. Probably not only queries, but also sets.

Michal

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-447856-
xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Saturday, April 02, 2011 10:11 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] GetSecurityInfo and device object namespace

I think Michal’s point is that this makes the security handling inconsistent, and
this query should be answered by the I/O Manager when
FILE_DEVICE_SECURE_OPEN is set.

For IRP_MJ_CREATE, he’s not handling the security for his name space… the
I/O Manager is, due to the setting of FILE_SECURE_DEVICE_OPEN in the
Device Object.

So, he COULD handle the IRP_MJ_QUERY_SECURITY… but he’d almost
certainly have quite a lot of work to do there. For one thing, he’d have to
discover what the protection on his Device Object actually IS, as the I/O
Manager (not his driver) is responsible for setting it (using info from the
Registry, from the INF file, and/or from IoCreateDeviceSecure or the WDF
equivalent). Given, then, that he’s not the one who’s ultimately DEFINING
the security for his devnode, he really isn’t the right one to be answering
queries about that security, right?

Sounds to me like Michal has a good point… One that *I’ve* certainly never
considered before.

Peter
OSR

NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/

9

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-447906-
xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Sunday, April 03, 2011 5:26 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] GetSecurityInfo and device object namespace

Agreed.

Me too.

Yeah… ugh. Maybe somebody wants to write some generic code for this and
make it available to the community. Since Michal’s gonna have to write it,
maybe he’d like to make an article for The NT Insider out of it :slight_smile:

Fortunately, I found a workaround. The driver (which I’ve inherited) is a bit overdesigned and it doesn’t seem to be necessary to use namespace at all. So I’ll remove it and if it doesn’t break anything else, it’ll save me from the necessity of handling IRP_MJ_QUERY_SECURITY.

The mentioned WLK test invokes problem only because it enumerates device interfaces and reference string is included in returned device path (to my surprise). So it opens it and in turn uses namespace. Without reference string the test passes.

BTW, the test is only used for biometric devices so other don’t need to worry, yet :wink:

Thanks, that was the purpose of my follow-up, actually.

That was the purpose of my original post as well :slight_smile: Thanks for considering, Doron.

Michal

NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/

10

Hi all,

Doron came and talked to me about this and we’ll do something to address it in the future.

Glad you were able to find a workaround Michal. For those who are curious, it is possible to handle this request downlevel. Peter, feel free to steal this for NT Insider :slight_smile:

For IRP_MJ_QUERY_SECURITY, create a dispatch routine that does the following:

NTSTATUS
DispatchQuerySecurity(
__in PDEVICE_OBJECT DeviceObject,
__in PIRP Irp
)
{
NTSTATUS status;
PSECURITY_DESCRIPTOR pSecurityDescriptor = NULL;
BOOLEAN alloc;

//
// Request security descriptor associated with the device object.
//
status = ObGetObjectSecurity(DeviceObject, &pSecurityDescriptor, &alloc);

if (NT_SUCCESS(status)) {
PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation(Irp);

//
// Capture the appropriate information into the user buffer or
// get the number of bytes required and return overflow.
//
try {
ULONG length = irpSp->Parameters.QuerySecurity.Length;
status = SeQuerySecurityDescriptorInfo(&irpSp->Parameters.QuerySecurity.SecurityInformation,
Irp->UserBuffer,
&length,
&pSecurityDescriptor);

if (status == STATUS_BUFFER_TOO_SMALL) {
Irp->IoStatus.Information = length;
status = STATUS_BUFFER_OVERFLOW;
} else if (NT_SUCCESS(status)) {
Irp->IoStatus.Information = length;
}

} except (EXCEPTION_EXECUTE_HANDLER) {
status = GetExceptionCode();
}

ObReleaseObjectSecurity(pSecurityDescriptor, alloc);
}

Irp->IoStatus.Status = status;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return status;
}

For IRP_MJ_SET_SECURITY, your dispatch routine can either fail (since really, setting security on a specific name in the namespace is probably not something you support, even if you support opening that name), or you can use the logic in Doron’s blog post here to do the set (left as an exercise to the reader):

http://blogs.msdn.com/b/doronh/archive/2007/10/16/setting-a-security-descriptor-on-a-legacy-device-object.aspx

Cheers!

-paul

11

Thanks, Paul. It is simpler than I expected as SeQuerySecurityDescriptorInfo() makes all the parameters handling.

For IRP_MJ_SET_SECURITY, your dispatch routine can either fail (since really,
setting security on a specific name in the namespace is probably not
something you support, even if you support opening that name)

There is the same problem as with query. FILE_SECURE_DEVICE_OPEN flag makes whole namespace security uniform and the same as the device object security. So it should be handled by I/O Manager as well. Until it does, the driver should handle it, instead. Just set the device object security for any name in the namespace. However, I wouldn’t do it until there is a real problem with it. Is there any app which really needs it? I know only WinObj which can be taken as a debugging tool.

Michal

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-448251-
xxxxx@lists.osr.com] On Behalf Of xxxxx@microsoft.com
Sent: Wednesday, April 06, 2011 7:23 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] GetSecurityInfo and device object namespace

Hi all,

Doron came and talked to me about this and we’ll do something to address it
in the future.

Glad you were able to find a workaround Michal. For those who are curious,
it is possible to handle this request downlevel. Peter, feel free to steal this
for NT Insider :slight_smile:

For IRP_MJ_QUERY_SECURITY, create a dispatch routine that does the
following:

NTSTATUS
DispatchQuerySecurity(
__in PDEVICE_OBJECT DeviceObject,
__in PIRP Irp
)
{
NTSTATUS status;
PSECURITY_DESCRIPTOR pSecurityDescriptor = NULL;
BOOLEAN alloc;

//
// Request security descriptor associated with the device object.
//
status = ObGetObjectSecurity(DeviceObject, &pSecurityDescriptor,
&alloc);

if (NT_SUCCESS(status)) {
PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation(Irp);

//
// Capture the appropriate information into the user buffer or
// get the number of bytes required and return overflow.
//
try {
ULONG length = irpSp->Parameters.QuerySecurity.Length;
status = SeQuerySecurityDescriptorInfo(&irpSp-
>Parameters.QuerySecurity.SecurityInformation,
Irp->UserBuffer,
&length,
&pSecurityDescriptor);

if (status == STATUS_BUFFER_TOO_SMALL) {
Irp->IoStatus.Information = length;
status = STATUS_BUFFER_OVERFLOW;
} else if (NT_SUCCESS(status)) {
Irp->IoStatus.Information = length;
}

} except (EXCEPTION_EXECUTE_HANDLER) {
status = GetExceptionCode();
}

ObReleaseObjectSecurity(pSecurityDescriptor, alloc);
}

Irp->IoStatus.Status = status;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
return status;
}

For IRP_MJ_SET_SECURITY, your dispatch routine can either fail (since really,
setting security on a specific name in the namespace is probably not
something you support, even if you support opening that name), or you can
use the logic in Doron’s blog post here to do the set (left as an exercise to the
reader):

http://blogs.msdn.com/b/doronh/archive/2007/10/16/setting-a-security-
descriptor-on-a-legacy-device-object.aspx

Cheers!

-paul

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/

12

Thank you, Paul, for agreeing to address this odd corner issue. It’s obviously one that none of us had previously considered . (For those of you don’t know him, Paul “owns” the I/O Manager – so it’s a pleasure to have him post here, and his reply on this topic is authoritative).

And, of course, thanks to Doron for taking the time to mention this to Paul.

Peter
OSR