I have a simple NDIS protocol driver that has worked for years on Windows 2000 through Windows Vista - then along comes Windows 7. To be honest, getting the driver to install seamlessly on Windows 7 took more time than I had planned.
*** Deprecated Functions ***
I've been writing NDIS drivers and related user-mode components since the DOS days. Some code snippets just get mindlessly re-used without being reviewed for years.
One snippet was associated with creating a driver service. This one has legacy code that attempted to lock the service controller database using LockServiceDatabase before calling CreateService. Well, on Windows 7 this function is deprecated; it can be called - but it does absolutely nothing. That's not terrible - BUT - the deprecated function never returns success.
Consequently calling my old code snipped resulted in an infinite loop.
So, take out that code and get a little further...
*** Device Object Security ***
On Windows 7 it is important to review security descriptors that you may assign to device objects. For example, if in the past yo assigned a NULL DACL to an object, don't expect Windows 7 to ignore it. A NULL DACL basically allows any user (anonymous, guest, authenticated user or administrator) to access the object: No access limitations at all!
Change that to use a more limited DACL!
Doron Holan has some notes in his blog at http://blogs.msdn.com/doronh/archive/2007/10/16/setting-a-security-descriptor-on-a-legacy-device-object.aspx.
In my case I am setting the device security from user-mode by calling SetServiceObjectSecurity and ConvertStringSecurityDescriptorToSecurityDescriptor. The MSDN has a decent example of using the latter to make a limited DACL that makes some sense.
*** Getting Elevated Privilege ***
The NDIS protocol driver is installed using an enhanced version of the ProtInstall utility described on NDIS.com at the URL http://ndis.com/ndis-general/ndisinstall/programinstall.htm.
The enhancement is basically to set an appropriate security descriptor (discussed above...) on the device object after installing the driver.
Of course, both calling the INetCfg API to install the driver and calling SetServiceObjectSecurity both require elevated privileges.
I'm not a Windows Installer SDK whiz and have grown tired of paying for installer tools that do more than I want (and must be updated for a fee with each Windows release). So, I have a simple Windows Installer project built under Visual Studio 2005. The installer installs both the driver(s) and some simple companion applications and support DLLs. This installer simply calls ProtInstall as a CustomAction during the Install and Uninstall phases.
Of course, these CustomActions must be executed with elevated privilege. Unfortunately, Visual Studio 2005 does NOT provide a way to specify that a CustomAction must be run with elevated privilege. This means that a user cannot simply download the MSI file and install it: The install will fail.
On Vista I took the easy way out: I required the user to download both the MSI file and the companion Setup.exe file. If the Setup.exe file is executed with elevated privilege, then execution of the MSI will inherit the elevated privilege and the CustomAction (calling ProtInstall...) will succeed.
But that's a nasty extra step. For Windows 7 I want to eliminate the need to use Setup.exe.
Fortunately Alek Davis of Intel was kind enough to have blogged about this particular problem. He provides a "bit of advice" (Actually bit 2048 in the CustomAction Type field...) that convinces the MSI installer to require elevated privilege when calling a CustomAction. The post of interest is at http://alekdavis.blogspot.com/2007/09/deploy-windows-services-on-vista.html.
After following his advice use of the extra Setup.exe bootstrapper is no longer necessary.
*** Summary ***
Thanks to having to work with Windows 7:
1.) My driver installs more cleanly - even on prior Windows versions.
2.) My software is more secure - even on prior Windows versions.
I'm tired of Windows 7 already. But it has forced me to make improvements and "That's a good thing!" (TM).
Thomas
*** Deprecated Functions ***
I've been writing NDIS drivers and related user-mode components since the DOS days. Some code snippets just get mindlessly re-used without being reviewed for years.
One snippet was associated with creating a driver service. This one has legacy code that attempted to lock the service controller database using LockServiceDatabase before calling CreateService. Well, on Windows 7 this function is deprecated; it can be called - but it does absolutely nothing. That's not terrible - BUT - the deprecated function never returns success.
Consequently calling my old code snipped resulted in an infinite loop.
So, take out that code and get a little further...
*** Device Object Security ***
On Windows 7 it is important to review security descriptors that you may assign to device objects. For example, if in the past yo assigned a NULL DACL to an object, don't expect Windows 7 to ignore it. A NULL DACL basically allows any user (anonymous, guest, authenticated user or administrator) to access the object: No access limitations at all!
Change that to use a more limited DACL!
Doron Holan has some notes in his blog at http://blogs.msdn.com/doronh/archive/2007/10/16/setting-a-security-descriptor-on-a-legacy-device-object.aspx.
In my case I am setting the device security from user-mode by calling SetServiceObjectSecurity and ConvertStringSecurityDescriptorToSecurityDescriptor. The MSDN has a decent example of using the latter to make a limited DACL that makes some sense.
*** Getting Elevated Privilege ***
The NDIS protocol driver is installed using an enhanced version of the ProtInstall utility described on NDIS.com at the URL http://ndis.com/ndis-general/ndisinstall/programinstall.htm.
The enhancement is basically to set an appropriate security descriptor (discussed above...) on the device object after installing the driver.
Of course, both calling the INetCfg API to install the driver and calling SetServiceObjectSecurity both require elevated privileges.
I'm not a Windows Installer SDK whiz and have grown tired of paying for installer tools that do more than I want (and must be updated for a fee with each Windows release). So, I have a simple Windows Installer project built under Visual Studio 2005. The installer installs both the driver(s) and some simple companion applications and support DLLs. This installer simply calls ProtInstall as a CustomAction during the Install and Uninstall phases.
Of course, these CustomActions must be executed with elevated privilege. Unfortunately, Visual Studio 2005 does NOT provide a way to specify that a CustomAction must be run with elevated privilege. This means that a user cannot simply download the MSI file and install it: The install will fail.
On Vista I took the easy way out: I required the user to download both the MSI file and the companion Setup.exe file. If the Setup.exe file is executed with elevated privilege, then execution of the MSI will inherit the elevated privilege and the CustomAction (calling ProtInstall...) will succeed.
But that's a nasty extra step. For Windows 7 I want to eliminate the need to use Setup.exe.
Fortunately Alek Davis of Intel was kind enough to have blogged about this particular problem. He provides a "bit of advice" (Actually bit 2048 in the CustomAction Type field...) that convinces the MSI installer to require elevated privilege when calling a CustomAction. The post of interest is at http://alekdavis.blogspot.com/2007/09/deploy-windows-services-on-vista.html.
After following his advice use of the extra Setup.exe bootstrapper is no longer necessary.
*** Summary ***
Thanks to having to work with Windows 7:
1.) My driver installs more cleanly - even on prior Windows versions.
2.) My software is more secure - even on prior Windows versions.
I'm tired of Windows 7 already. But it has forced me to make improvements and "That's a good thing!" (TM).
Thomas
1 comment:
Hello Mr. Thomas. how are you ?
How's things ?
your web log is very interesting :)
why don't you continue write ? it is useful.
OK, I'll be right back again.
Post a Comment