Recent security reviews in the Windows file systems team have pointed out that the FILE_DEVICE_SECURE_OPEN characteristic needs to be set for file system device objects that do not support naming. For example, a physical media file system typically creates a named device object. This named device object is then, in turn, registered with the I/O Manager so that it will receive mount requests on devices of the specified type. Thus, the I/O Manager calls a FILE_DEVICE_CD_ROM_FILE_SYSTEM to mount devices of type FILE_DEVICE_CD_ROM. Because these device objects do not support naming structure (that is, you do not open \Cdfs\Myfile, for example) they need to indicate this when they create their device objects by specifying the FILE_DEVICE_SECURE_OPEN characteristic.
For example, the CDFS file system code in the Windows XP IFS Kit does not indicate this characteristic:
//
// Create the device object.
//
RtlInitUnicodeString( &UnicodeString, L"\\Cdfs" );
Status = IoCreateDevice( DriverObject,
0,
&UnicodeString,
FILE_DEVICE_CD_ROM_FILE_SYSTEM,
0,
FALSE,
&CdfsFileSystemDeviceObject );
However, to avoid allowing a malicious application from compromising security by specifying a bogus trailing name, this code should read:
//
// Create the device object.
//
RtlInitUnicodeString( &UnicodeString, L"\\Cdfs" );
Status = IoCreateDevice( DriverObject,
0,
&UnicodeString,
FILE_DEVICE_CD_ROM_FILE_SYSTEM,
FILE_DEVICE_SECURE_OPEN,
FALSE,
&CdfsFileSystemDeviceObject );
For older versions of Windows NT, where the FILE_DEVICE_SECURE_OPEN option is not available, an alternative mechanism to close this security hole would be for the driver to reject any IRP_MJ_CREATE request on these device objects for which there is a trailing name component. While this is not identical in behavior (it would reject any call against the device where there was a trailing name, not just those without sufficient security) it is more conservative and thus does not compromise security. For those who wish to match the semantics identically, it would require performing a full security check (using SeAccessCheck) against the security descriptor of the file system device object, which can be obtained by calling ObGetObjectSecurity.
Be careful here! Your file system will not want to specify FILE_DEVICE_SECURE_OPEN for any of its device objects that support name structure (e.g., a normal file system volume device object) because it will incorrectly reject requests from users that do not hold administrative rights. The normal requirement is that the caller must have TRAVERSE permission for the file system volume device object, but FILE_DEVICE_SECURE_OPEN requires that the caller have actual permission on the volume itself. Thus, an application that requests ?write? access to a file, would be required to have ?write? access on the volume ? which is not going to be the case for most normal users!