I do not believe this is possible; however, this query belongs in the VSE community.
I did move this to Virusscan per your recommendation. I find it hard to believe that McAfee would bundle the prevention of executable and configuration files into one policy without the ability to exclude certain configuration files. If that was the case it should be two separate entries. Has anyone else had any experience in this area?
Well thats why I indicated the query should be moved to VSE someone in this community can provide you with a better answer. If it is a file you want to exclude (as opposed to a process) you could try adding the exclusion to the VSE On-access default process policy. I believe that access protection rules obey the OAS exclusions but I could be wrong. I know if the OAS is disabled access protection rules stop working so that is what I'm basing this assumption on.
Good point. I performed a quick test by excluding .ini files in the on access scanner and found that the Access Protection is still blocking the modification of ini files. Unfortunately, it seems the On Access policy does not carry over into the Access Protection policy.
Exactly right, OAS configurations, are completely separate from Access Protection configurations.
When McShield (OAS) is stopped, it stops all of our VSE processes. That is why you saw AP disable as well. However, an OAS exclusion, is separate from AP exclusions.
Hope it helps.
So the original question still exists, is there a way to exclude certian configuration files like .ini files from the AP policy? This specific option in the policy I need to for the executable protection but it causes a lot of other issues with config files like dll and ini files. Roaming users is broken because ntuser.ini can not be written for example.
Sorry to work up this thread from the bottom
So the process would pretty much always be something like svchost, or lsass, or something, since we are talking about remote connections coming into this system.
While you can prevent modification of the ini, exclusions would probably just circumvent that rule, since it's likely one particular process everytime.
Does that even make sense?
This situation depends on what your legitimate apps are going to do, versus potential malware....
So if you have local apps that need to modify the ini files, you could place those processes in the exclusion field, and still block "remote" changes. (what we would expect malware to do). However, if your app needs to make changes over the network, then it will always show up as "System:Remote", just the same as malware, and there would be no way to decern malware from the legit application. In which case, the AP rule might not be usable in your environment.
We should probably get more information about what your legit apps will need to do, and see if there is a way to allow the expected "good" apps, and block all others. It's not always possible though.
Let us know if we need to go further.
Many of our users have redirected Application Data that resides in thier home directories on a server. The applications that are installed on the workstations sometimes keep data in the Application data folder on the server. One example is in the first post. This is caused by scanner software installed on the workstation that keeps ini files in Application data. Another example is RUP (Roaming User Profiles). The RUP folder is also kept in thier home directories and ntuser.ini cannot be modified. Our solution thus far has been to stop redirecting Application Data and recreate the profiles locally on the workstations. This is a slow and painful process as not all users only use one machine so we need to remove all local profiles from every machine they have used in the past. So in short, all of our problems are caused from applications on the PC trying to write files to a server and therefore seen as Remote:System. It is sounding like there is not a soluion but any suggestions would be appreciated.