Recently enabled application control. MACC prevents an attempt to modify this file::
%LocalAppData%\Google\Chrome\User Data\PepperFlash\32.0.0.371\pepflashplayer.dll
by:
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
When I try to create a policy for it via Solidcore Events, I get a message that says I can't create a policy for generic launcher process.
Please advise on how to allow this file.
Solved! Go to Solution.
Hello @mlajoie
There is couple ways how to do this, depending on how file is being used and which action is needed.
The block is present because Chrome is not Updater hence it is not allowed to perform modification against solidified file and also you can't make Chrome Updater because it is listed in "Menu -> Configuration -> Server Settings -> Solidcore" as one of "Generic launcher processes".
So first question is, does this block cause any actual problem on machine and can it be just ignored?
If you really have to allow this modification, you may just un-solidify the file itself which will allow file to be modified by any process, up to and including Chrome, however, the question after that is, does that file have to run again?
Other way to do the same thing is adding file in "skiplist -d" aka "Exclusions -> Advanced options -> Exclude path from write-protection rules", which will allow solidified file to be modified, however, that modification will un-solidify file so same question from above stands, does it have to run?
If it does because it is not solidified now, it will be prevented to execute till it is solidified back or manually allowed, so the question becomes is this file needed for something and is it necessary to allow it to run again?
To do that again, you may re-solidify file allow the files execution every time it is modified and new version has to run, you may add it on global allow list based on its SHA to ensure only specific SHAs can run or you may allow it by name in "Executable Files" witch tells Solidcore to let that file run regardless if it is on whitelist/solidified or not.
Last option that envelops all of above is, you may add file on skiplist -i, in "Exclusions -> Advanced options -> Ignore path for file operations" which basically tells Solidcore to allow modification to the file regardless if file is solidified or not and regardless if process trying to do that is Updater or not and also tells Solidcore to allow execution to that same file regardless if file is solidified or not.
So with skiplist -i, you will have:
01. File is solidified
02. Because it is on skiplist -i, Chrome will be allowed to perform modification on file event if it is not being Updater.
03. Because Chrome is not Updater, file now will become un-solidified.
04. But because it is on skiplist -i, it will still be allowed to run.
Main reason why I didn't start with skiplist right away is because I wanted to present how many factors you may have when making decision if something is needed to be modified or executed where "skiplist -i" is powerful option to resolve lot of those issues.
However, "skiplist -i" should be used really really carefully because if not careful, you may open lot of holes on machine, because "skiplist -i" not only that allows modification of the files that are not solidified, but also allows those file to run later on, that will defeat purpose of having Solidcore on the box in the first place.
I hope this helps.
To surpress the event on the client and the EPO . You just need to go to epo > solidcore Events > click on the event and state Exclude event. This will take you to build an AEF rule. Then just generalize it (like remove the user) Then it will not be in your logs or report to epo.
McAfee Support
Benjamin Ellis
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
Hello @mlajoie
There is couple ways how to do this, depending on how file is being used and which action is needed.
The block is present because Chrome is not Updater hence it is not allowed to perform modification against solidified file and also you can't make Chrome Updater because it is listed in "Menu -> Configuration -> Server Settings -> Solidcore" as one of "Generic launcher processes".
So first question is, does this block cause any actual problem on machine and can it be just ignored?
If you really have to allow this modification, you may just un-solidify the file itself which will allow file to be modified by any process, up to and including Chrome, however, the question after that is, does that file have to run again?
Other way to do the same thing is adding file in "skiplist -d" aka "Exclusions -> Advanced options -> Exclude path from write-protection rules", which will allow solidified file to be modified, however, that modification will un-solidify file so same question from above stands, does it have to run?
If it does because it is not solidified now, it will be prevented to execute till it is solidified back or manually allowed, so the question becomes is this file needed for something and is it necessary to allow it to run again?
To do that again, you may re-solidify file allow the files execution every time it is modified and new version has to run, you may add it on global allow list based on its SHA to ensure only specific SHAs can run or you may allow it by name in "Executable Files" witch tells Solidcore to let that file run regardless if it is on whitelist/solidified or not.
Last option that envelops all of above is, you may add file on skiplist -i, in "Exclusions -> Advanced options -> Ignore path for file operations" which basically tells Solidcore to allow modification to the file regardless if file is solidified or not and regardless if process trying to do that is Updater or not and also tells Solidcore to allow execution to that same file regardless if file is solidified or not.
So with skiplist -i, you will have:
01. File is solidified
02. Because it is on skiplist -i, Chrome will be allowed to perform modification on file event if it is not being Updater.
03. Because Chrome is not Updater, file now will become un-solidified.
04. But because it is on skiplist -i, it will still be allowed to run.
Main reason why I didn't start with skiplist right away is because I wanted to present how many factors you may have when making decision if something is needed to be modified or executed where "skiplist -i" is powerful option to resolve lot of those issues.
However, "skiplist -i" should be used really really carefully because if not careful, you may open lot of holes on machine, because "skiplist -i" not only that allows modification of the files that are not solidified, but also allows those file to run later on, that will defeat purpose of having Solidcore on the box in the first place.
I hope this helps.
That helps immensely. It doesn't appear to be stopping Chrome from doing anything so, for now, I'm inclined to leave it blocked.
I do have a follow-up. If I want to allow it to continue to be blocked, how do I prevent MACC from telling the user that it was blocked -- basically suppress the notification to the user and, probably, to ePO?
To surpress the event on the client and the EPO . You just need to go to epo > solidcore Events > click on the event and state Exclude event. This will take you to build an AEF rule. Then just generalize it (like remove the user) Then it will not be in your logs or report to epo.
McAfee Support
Benjamin Ellis
Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA