Viewing Security in WinObj

Users access my driver by calling create file like:
sprintf( szBoardName, “\\.\%s%d”, m_BoardName, BoardNumb);
hMyDriver = CreateFile( szBoardName,
0,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING, 0, NULL);

I found that under windows 7 this did not work unless the user was an elevated administrator. After searching this forum, I found that I was supposed to add security to my inf file. I add the lines below to my inf

[SGRWDF.Dev.NT.HW]
AddReg = SGRWDF.Dev.Security

[SGRWDF.Dev.Security]
HKR,DeviceCharacteristics,0x10001,0x100
HKR,Security,“D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)”

And lo and behold I could now access the driver from a normal user account.

My question is, I expecedt to be able to see a change in security settings when viewing my device in WinObj. This I did not see. I navigate to the GLOBAL?? tree and find my symbolic name, right click to select properties and then the security tab. What it shows is basically that no one has any access. This is obviously not true as things are working… So what am I doing wrong? Should I be looking at something other than the symbolic link name?

Look at the target, not the symlink.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@verizon.net
Sent: Friday, February 22, 2013 9:03 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Viewing Security in WinObj

Users access my driver by calling create file like:
sprintf( szBoardName, “\\.\%s%d”, m_BoardName, BoardNumb);
hMyDriver = CreateFile( szBoardName,
0,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING, 0, NULL);

I found that under windows 7 this did not work unless the user was an elevated administrator. After searching this forum, I found that I was supposed to add security to my inf file. I add the lines below to my inf

[SGRWDF.Dev.NT.HW]
AddReg = SGRWDF.Dev.Security

[SGRWDF.Dev.Security]
HKR,DeviceCharacteristics,0x10001,0x100
HKR,Security,“D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)”

And lo and behold I could now access the driver from a normal user account.

My question is, I expecedt to be able to see a change in security settings when viewing my device in WinObj. This I did not see. I navigate to the GLOBAL?? tree and find my symbolic name, right click to select properties and then the security tab. What it shows is basically that no one has any access. This is obviously not true as things are working… So what am I doing wrong? Should I be looking at something other than the symbolic link name?


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

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 that this ASSUMES you’re INF file will be signed. Otherwise, the security will be subject to change, right?

If you’re INF file will NOT be signed, check out the function call WdfDeviceInitAssignSddlString.

Peter
OSR

>Look at the target, not the symlink.
I am assuming by target, you mean the entry int the “device” key that the symbolic link points to. This does seem to work. I thought I had looked there before, but either I did not or I misread what what there.

Note that this ASSUMES you’re INF file will be signed. Otherwise, the security will be subject to change, right?

I am currently test signing the cat file. I assume I will eventually purchase a certificate so I can sign it for real. I thought it was required to sign driver packages for window 7. Is there a way not to sign it?

Is it preferred to do the security in the inf or use WdfDeviceInitAssignSddlString ?

If you do it through the INF, the SDDL gets applied to all devices in the stack. That is important b/c if the PDO, which always has a name, is opened by name (vs your FDO’s name), it can circumvent your security

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@verizon.net
Sent: Friday, February 22, 2013 12:41 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Viewing Security in WinObj

Look at the target, not the symlink.
I am assuming by target, you mean the entry int the “device” key that the symbolic link points to. This does seem to work. I thought I had looked there before, but either I did not or I misread what what there.

Note that this ASSUMES you’re INF file will be signed. Otherwise, the security will be subject to change, right?

I am currently test signing the cat file. I assume I will eventually purchase a certificate so I can sign it for real. I thought it was required to sign driver packages for window 7. Is there a way not to sign it?

Is it preferred to do the security in the inf or use WdfDeviceInitAssignSddlString ?


NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

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

xxxxx@verizon.net wrote:

> Note that this ASSUMES you’re INF file will be signed. Otherwise, the security will be subject to change, right?
I am currently test signing the cat file. I assume I will eventually purchase a certificate so I can sign it for real. I thought it was required to sign driver packages for window 7. Is there a way not to sign it?

Driver packages do not have to be signed. In Windows 7 64-bit, you can
sign the SYS file itself to satisfy KMCS. In Win 7 32-bit, no
signatures are required.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

>Driver packages do not have to be signed. In Windows 7 64-bit, you can sign the SYS file itself to satisfy KMCS. In Win 7 32-bit, no signatures are required.

Thank you so much for that information. In my case it would be very desirable to sign the SYS file only as the inf file will need to be modified periodically. If the cat file is signed, changes to the inf would require re signing (if I understand things correctly). If was not clear to me what the Win 7 32 requirements were.

This is true. IF you’re going to sign your driver package, including the INF, THE BEST PLACE to specify Device Object security is in the INF.

OTOH, if you’re NOT going to sign your INF, you can never be sure what the security will be.

Calling WdfDeviceInitAssignSddlString *will* propagate the security set on the FDO down to the PDO and through the device stack… but only if there’s no security already specified for the device class and only after the system has been rebooted.

Setting the protection on a device object is actually a big can of worms that’s waaay more complicated than (a) it sounds, (b) it should be. You can read about it in these two articles that I wrote some years ago:

http://www.osronline.com/article.cfm?article=507
http://www.osronline.com/article.cfm?article=508

Peter
OSR

xxxxx@verizon.net wrote:

Thank you so much for that information. In my case it would be very desirable to sign the SYS file only as the inf file will need to be modified periodically. If the cat file is signed, changes to the inf would require re signing (if I understand things correctly).

Yes, but remember that (1) signing is free, (2) any change to any file
requires a new CAT, (3) changing the INF requires uninstall/reinstall,
and (4) Windows 8 requires a CAT file.

If was not clear to me what the Win 7 32 requirements were.

Same as Vista 32. Same as XP.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim Roberts wrote:

> If was not clear to me what the Win 7 32 requirements were.
Same as Vista 32. Same as XP.

XP requirements are somewhat different.

On one hand, there’s no KMCS. On the other hand, to have your INFs “server install” (that is, installed without user interaction, and without prompting for an admin account), they have to be signed by WHQL or an equivalent Windows System Component Verification certificate. (From Vista onwards, any Authenticode certificate will do.)

P.S. if for some reason you have to target Windows XP, this is a crude yet working option - http://stackoverflow.com/a/3333992/130066

xxxxx@gmail.com wrote:

Tim Roberts wrote:
>> If was not clear to me what the Win 7 32 requirements were.
> Same as Vista 32. Same as XP.
XP requirements are somewhat different.

On one hand, there’s no KMCS.

There’s no KMCS in Vista 32 or Win 7 32, either.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

There still is a kernel mode signing policy on 32-bit, it’s simply not enforced for driver loading. It is however enforceable by DRM content: media may refuse to play on such systems as the Protected Environment Authorization (PEAUTH) will return an “untrusted system state” to the Media Foundation API.

As such, one should also sign their drivers on 32-bit as well.

Additionally, certain newer APIs enforce signing requirements on 32-bit, such as ObRegisterCallback.


Best regards,
Alex Ionescu