OSRLogo
OSRLogoOSRLogoOSRLogo x Seminar Ad
OSRLogo
x

Everything Windows Driver Development

x
x
x
GoToHomePage xLoginx
 
 

    Thu, 14 Mar 2019     118020 members

   Login
   Join


 
 
Contents
  Online Dump Analyzer
OSR Dev Blog
The NT Insider
The Basics
File Systems
Downloads
ListServer / Forum
  Express Links
  · The NT Insider Digital Edition - May-June 2016 Now Available!
  · Windows 8.1 Update: VS Express Now Supported
  · HCK Client install on Windows N versions
  · There's a WDFSTRING?
  · When CAN You Call WdfIoQueueP...ously

Securing Device Interfaces - A Better Approach than Sending an SD

In a number past articles here in The NT Insider, we've discussed various methods for securing device interfaces.One method we discussed was building a Security Descriptor (SD) that describes the security you want applied to a device interface back in a user mode app (using all the clever user-mode APIs, as appropriate). The app then sends this self-relative SD to the driver using a predefined IOCTL. The driver stores the SD away for later use. On each IOCTL that the driver wants to protect, it does an SeAccessCheck() of the user's current security credentials against the stored-away SD.

The problem with this approach is that it is tied to the thread that you are testing against. The thread's security context may not be the same as the one that was used to open the device in the first place. That means that it strays from the traditional semantics of all the access rights being computed up front and stored in the handle. So, if ThreadA opens the device, then dups the handle to another process, the kind of test described would violate the premise that the handle would have full fidelity access to the device. So, while the security check works, it's not fully consistent with how the Windows architecture defines the relationship between handles and devices.

A different way to handle this problem that preserves the handle semantics is to create a second, protected, interface. Anyone with WRITE_DAC access to this device could change the security descriptor on it. Thus, the user mode app, as easily as constructing a security descriptor and sending it down via an IOCTL to your driver (as in the previous method) could call SetKernelObjectSecurity() to directly change the device object's security.

In trying to solve a problem such as attaching appropriate security to a Device Object, it's important to look across the entire spectrum of possible solutions. The difficulty in doing this lies in the fact that few people understand possible solutions that exist in both kernel mode and user mode. In this case, it's clear that there's a ready made solution available to user-mode applications.

Related Articles
Keeping Secrets - Windows Security (Part III)
Keeping Secrets - Windows NT Security (Part II)
Keeping Secrets - Windows NT Security (Part I)
You've Gotta Use Protection -- Inside Driver & Device Security
Still Feeling Insecure? - IoCreateDeviceSecure( ) for Windows 2K/XP/.NET
Security During Create Operations
Locking Down Drivers - A Survey of Techniques
What is Coming with Vista - Limited User Access

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

Post Your Comments.
Print this article.
Email this article.
bottom nav links