um - device interfaces are not about security, they are about locating
services - a replacement for naming conventions like ‘com1’.
Mark Roddy
On Fri, Dec 3, 2010 at 6:19 PM, wrote:
>> A device interface is just a way to FIND a device. ?It is an
>> advertisement that you offer certain services. ?It doesn’t affect
>> whether or not users can ACCESS the device. ?Typically, the device
>> interface isn’t disabled until the device is actually shutting down, but
>> you typically do not shut down a device while there are open handles.
>
> Yes. Which makes the “device interface” pretty useless for security, right?
>
> And, isn’t that the whole reason they said they were forcing us to use
> “device interfaces” in the first place? For security?
>
> Any first-year system administrator can easily see the problem in this
> scenario, right?
>
> “Your credentials are valid till the next time you try to open the device,
> or as long as you don’t close it - whichever comes LAST”. Duh. 
>
> I never did buy all that “we’re giving this to you because of security” stuff.
> But hey, what do I know, I’m just a programmer.
>
> —
> 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
>
The named devobj in the middle of the stack with diff security than the pdo problem is solved by specifying your acl in the inf. The io manager will apply that acl to all the device objects in the stack.
d
dent from a phpne with no keynoard
-----Original Message-----
From: Pavel A.
Sent: December 04, 2010 12:17 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Virtual PNP Device
“Pavel A.” wrote in message news:xxxxx@ntdev…
> wrote in message news:xxxxx@ntdev…
>>
>> And, isn’t that the whole reason they said they were forcing us to use
>> “device interfaces” in the first place? For security?
>
> The story about device interfaces is related to security, rather
> indirectly.
> To make this story short… MS promotes using devinterfaces because
> the device object that you open by devinterface names is always the PDO
> of the stack.
> Security on PDOs can be easily set, either in the INF at install time,
> or in the registry, or inherited from the setup class.
>
> But the stack can consist of several drivers, each of them can assign
> different names and security to their device objects.
> So if you use “legacy” name to open the device, you can land to random
> device object of some filter, with bogus security settings.
Here’s example: look at the recent thread “Device object usage”.
p.
> To minimise possibility of this, MS advices to use devicenterfaces,
> and leave other thinghs in the stack unnamed.
> Security-wise this is worth as much as any other MS commandment.
>
> --pa
—
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
There’s absolutely nothing wrong with this. This is the basic Windows OS architectural concept of how/when security checks are implemented. Think about it: You’re pumping several thousand IOCTLs per second between your app and your device – Would you REALLY want Windows to evaluate your security token and the ACL on your device for EVERY IOCTL? I think not.
Well… no. There are a lot of reasons, as folks have already outlined.
But you’re not crazy. The idea of Device Interfaces and whether or not you should name your FDOs created a lot of mumbling about security, including statements saying things like “you should never name your FDO because it creates a serious security hole in the device stack, and you should use device interfaces instead, because device interfaces fix this terrible security problem.” In other words, device interfaces WERE sold to the community (at least in various WHDC whitepapers and the WDK) as “the right thing for security” – Many of these statements were at best simplistic and misleading and at worst just downright incorrect.
I wrote about this at length in The NT Insider a couple of years back:
http://www.osronline.com/article.cfm?article=507
http://www.osronline.com/article.cfm?article=508
So, while the REAL purpose of device interfaces is in fact service location (finding a device), there certainly WAS a lot of hullaballoo about folks using device interfaces instead of device names due to security issues.
Peter
OSR
> And, isn’t that the whole reason they said they were forcing us to use
“device interfaces” in the first place? For security?
No. For name generation without conflicts.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> That has two major problems. First, it fails if you have two or more
instances. So, people tack on a number. Now you have \.\MyDevice0 and
\.\MyDevice1. This causes its own set of problems; if I have device 0,
1, and 2, and device 1 goes away, now the set of device numbers is not
contiguous. A user-mode program can’t just start at 0 and query the
devices. Instead, you have to have some upper limit (10? 99? 255?) and
try them all. Does a new device fill in the hole, or just append to the
end? These are awkward decisions.
More so.
The numbers are either non-persistent or persistent.
If the numbers are non-persistent - then there is a scenario when the same device will have another number after reboot or plug/unplug of the identical devices.
And, if the numbers are persistent - then yes, the issues described by you arise.
Device interface names are persistent. For instance, for removable media disk devices, the device interface name is the MountDev ID, which is used to assign the drive letter. And yes, the drive letters are persistent.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com