cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 1 of 4

Blocking pepflashplayer.dll

Jump to solution

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.

2 Solutions

Accepted Solutions
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 4

Re: Blocking pepflashplayer.dll

Jump 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.


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?

View solution in original post

Highlighted
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 4 of 4

Re: Blocking pepflashplayer.dll

Jump to solution

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?

View solution in original post

3 Replies
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 2 of 4

Re: Blocking pepflashplayer.dll

Jump 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.


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?

View solution in original post

Highlighted
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 3 of 4

Re: Blocking pepflashplayer.dll

Jump to solution

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?

Highlighted
McAfee Employee
McAfee Employee
Report Inappropriate Content
Message 4 of 4

Re: Blocking pepflashplayer.dll

Jump to solution

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?

View solution in original post

You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community