Securing Device Interfaces - A Better Approach than Sending an SD
(By: The NT Insider, Vol 9, Issue 5, Sep-Oct 2002 | Published: 15-Oct-02| Modified: 10-Oct-02)
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.
was printed from OSR Online http://www.osronline.com
Copyright 2017 OSR Open Systems Resources, Inc.