I have a mini filter driver and I would like to block certain applications from reading certain files. I, however, do not want to block the application from opening the file but block them when they actually read the data off of it. To implement this I registered a PreCallback for IRP_MJ_READ and perfrom the following things:
You can want all you want, but that isn’t going to change the facts.
Security checks are done on create and not reads. Attempting to write on a
handle that does not have write access will fail, but otherwise you can’t
just decide to fail reads. The system can become unstable if you do. You
could just fill the buffers with zeroes and return them that way, but if a
write occurs it will destroy the file.
wrote in message news:xxxxx@ntfsd… > Hello Folks, > > I have a mini filter driver and I would like to block certain applications > from reading certain files. I, however, do not want to block the > application from opening the file but block them when they actually read > the data off of it. To implement this I registered a PreCallback for > IRP_MJ_READ and perfrom the following things: > > > FLT_PREOP_CALLBACK_STATUS PreReadCallback(…) > { > > if (BlockingCondition() == TRUE) > { > data->IoStatus.Status = STATUS_ACCESS_DENIED; > data->IoStatus.Information = 0; > > return (FLT_PREOP_COMPLETE); > } > return (FLT_PREOP_SUCCESS_NO_CALLBACK); > } > > Question to you guys is, is it ok to return STATUS_ACCESS_DENIED from this > callback? Will it result into a failure of read in the application? > > Appreciate your help. > > Thanks > -RU >
Your attempt is doomed, while you might block ReadFiles all you need is an
application that does a MapFile and you will never see the condition needed
to block. You have to do a lot of work to make this effective.
wrote in message news:xxxxx@ntfsd… > Hello Folks, > > I have a mini filter driver and I would like to block certain applications > from reading certain files. I, however, do not want to block the > application from opening the file but block them when they actually read > the data off of it. To implement this I registered a PreCallback for > IRP_MJ_READ and perfrom the following things: > > > FLT_PREOP_CALLBACK_STATUS PreReadCallback(…) > { > > if (BlockingCondition() == TRUE) > { > data->IoStatus.Status = STATUS_ACCESS_DENIED; > data->IoStatus.Information = 0; > > return (FLT_PREOP_COMPLETE); > } > return (FLT_PREOP_SUCCESS_NO_CALLBACK); > } > > Question to you guys is, is it ok to return STATUS_ACCESS_DENIED from this > callback? Will it result into a failure of read in the application? > > Appreciate your help. > > Thanks > -RU >
wrote in message news:xxxxx@ntfsd… > Hello Folks, > > I have a mini filter driver and I would like to block certain applications from reading certain files. I, however, do not want to block the application from opening the file but block them when they actually read the data off of it. To implement this I registered a PreCallback for IRP_MJ_READ and perfrom the following things: > > > FLT_PREOP_CALLBACK_STATUS PreReadCallback(…) > { > > if (BlockingCondition() == TRUE) > { > data->IoStatus.Status = STATUS_ACCESS_DENIED; > data->IoStatus.Information = 0; > > return (FLT_PREOP_COMPLETE); > } > return (FLT_PREOP_SUCCESS_NO_CALLBACK); > } > > Question to you guys is, is it ok to return STATUS_ACCESS_DENIED from this callback? Will it result into a failure of read in the application? > > Appreciate your help. > > Thanks > -RU >
Appreciate all your feedback. I agree that I should be blocking the create and not reads but in our product when we perform block it generates an event which is reported to the administrator. In case of the above use case blocking on create generates a lot of false positives e.g. when the user simply hovers the mouse over the file in the file open dialog box from with in the blacklisted application, a block happens and it generates an event. This result into a false positive as the user did not really open that file and read the contents.
A more concrete example would be to block a cd/dvd application from reading a file only when it is really trying to burn it and not while the user is browsing it in the file open dialog.
Don’t block IRP_MJ_CREATE requests, but remove FILE_READ_DATA / FILE_READ_ATTRIBUTES and FILE_READ_EA flags in Create dispatch routine.
Let lower devices to block read IRPs instead of you ;).
Petr
wrote in message news:xxxxx@ntfsd… > Appreciate all your feedback. I agree that I should be blocking the create and not reads but in our product when we perform block it generates an event which is reported to the administrator. In case of the above use case blocking on create generates a lot of false positives e.g. when the user simply hovers the mouse over the file in the file open dialog box from with in the blacklisted application, a block happens and it generates an event. This result into a false positive as the user did not really open that file and read the contents. > > A more concrete example would be to block a cd/dvd application from reading a file only when it is really trying to burn it and not while the user is browsing it in the file open dialog. > > Thanks > -RU >