I have a UMDF 2.0 driver that needs to read contents of a data file. It makes a CreateFile(fileName,GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_EXISTING,0,NULL) call to open the file, reads its contents and closes the file. It works fine when the file is residing in folders that are **not ** part of any user profile folder Ex: C:\Test, D:\Test, C:\Program Files, C:\Windows etc.
However, the CreateFile call fails with “access denied” when the same file is residing inside folder that belongs to user profile folders: Ex: C:\Users\TestUser or C:\Users\TestUser\Desktop
I understand that the UMDF driver runs as a LocalService and apparently it doesn’t have read access to the data file thus the failure. How do I over come this issue?
An application that is an add-on component of our product will create this data file and update it periodically. The driver will only read and use it. This application does not communicate with the driver at all, thus it cannot send the data directly to the driver.
That is a pretty bad design. You can’t trust the contents of the file, so you need to validate everything you read. A functional area that is notoriously bad for bugs, escalation of privilege, etc. Why can’t the app communicate with the driver? If the application running as the normal user or elevated?
The binary data will always be one KB or less and the driver performs rigorous validation before using it. The application runs as a normal user and it is developed and owned by a third party.
well, let’s think for a minute. drivers whether UM or KM necessarily control think that are both system wide and per system. user profiles are different. they are obviously per user instead of system wide and they might be per system or cross systems (roaming profile) or be a hybrid (i.e. local temp, but global documents etc.). drivers should not depends on files written to places that they might not even have theoretical access to - such as in the case of a roaming profile with a network outage. an ACL denying access is the least of your issues.
the next likely point is that non-elevated processes cant write to other locations by default. nor should they be able to. that a key point with respect to security - you either have it or you don’t
with respect to the validation of binary data within a driver, Doron’s point is that many people who have thought that they have rigorously validated inputs have been surprised by cases that they had not considered. every format is different, but text based formats like the 7-bit ASCII SMTP protocol are much harder to exploit.
as your data is so small have you considered the registry? not a binary blob, but specific named keys and values where the system will perform nearly all of the necessary validation for you? and there are registry locations that non-elevated applications can write to - and the plurality of them may force you to address any system versus user questions in your design - which i clearly can know nothing about