because the option you mention here is not controlled by a rule but a GUI checkbox, there may be no exclusion possible (I'm pretty sure there is none - there is not a mechanism that would accept or even interpret "exclusion" to this checkbox control.)
I would be surprised if there was such a mechanism, frankly. Hacks do not count
My thoughts exactly but just asking in case! I can see why McAfee wouldnt want to enable this, however this obviously causes me issues from an automation perspective as I need to stop the service, and the only way I can do that is by temporarily and manually disabling the option in the VSE console, which obviously kills the automation side of things! As you say, without hacks!
Nice discussion.I 'd like to add Attila, When we upgrade MA epo stops McAfee Frmawork service and start it again, do you know what machnism ePo uses behind it (Is it something related tp MfeVTPs that that permits these priviliges to ePO process to terminate it?If yes than we can disign a small utility to fool Mfevtps and allow framework service to stop at any time, what do you think?
There techincally is a way you can make this process automated but it is a bit long winded and theoretical.
1. Create a group in your ePO system tree that has a broken policy inheritance and have a policy that has the afore-mentioned tick box unticked assigned to it.
2. Use the ePO API to remotely run a command that moves the required machine into this new folder.
3. Use PSEXEC to run a remote CMDAGENT /P to force a policy refresh on the target machine.
4. Stop the services, do what ever you need to do, start the services
5. Use the ePO API to move the machine back into it's orignal location in the system tree
6. Send a policy refresh
As for the utility to stop the framework services!! I wouldn't like to think what would happen when the virus creators got hold of that little gem.
@Alexn - valid point, I hadnt even thought of that - there must be something in there to allow the updater to stop the service.
@Tristan - regards virus creators, there has to be something somewhere that allows the termination of the service. Allowing it to happen under controlled and restricted circumstances shouldnt introduce that much risk (depending on how exactly this was approached - I do appreciate where you are coming from!). With regards to your steps, I would agree to a certain extent, however the group that need to run this automated task do not have access to the ePO server - there are different groups managing different parts of the environment (large company). Everything needs to be run from the machine in question - so (I havent played with the API yet) as I understand it we would be looking at:
Carry out your number 1 in advance (carried out by ePO admin), then:
1) Install Python on machine in question (I believe this is required for API?)
2) Create script that can be run that carries out relevant API call (credentials will need to be hardcoded, or suitable credentials will need to be asked for by the script)
3) carry out everything else in your process above
I think that the overhead involved (given the fact that the admin of the system in question can disable the tickbox by going into the VSE console - they have permission) is far more than the current way of working - I just want to really be able to set something up so the framework service can be temporarily stopped.
Great points so far all - muchly appreciated!
I think now is a good time for me to add...
Once you've figured out how to bypass our Access Protection feature - and I can't give you any indication as to how far away you are from doing that, but in the Tech Security world it's not a matter of "if" you'll breach security measures, it's "when" - so, once you've figured it out, I want to remind everyone that the feature itself is not intended to be unbeatable. It is intended to make it difficult. On its own VSE does a decent job at protecting itself from malware and from well-intentioned Admins, but I can't in good conscience help you do it.
The product uses digital certificates to establish "Trust" relationships with McAfee processes, allowing them to programmatically go unhindered when we need them to. Sometimes you might even see our own processes getting blocked from certain actions (telling you that somehow the Trust relationship was lost - perhaps from a Patch update, typically solved with a reboot). It would be very difficult for someone outside of McAfee to leverage this method (our own method) to bypass Access Protection.
A more brutish method does exist and can be scripted, but I don't want that being on the internet any earlier than it needs to be - because someone will get a bee in their bonnet and jump up and down claiming it's a vulnerability and demand we do something to address it. Thus I refer back to my earlier comment, it is intended to make it difficult; it's not unbeatable.
Love to know that brutish method.
Well as per my findings at kernel level when OS assigns privilleges to Mcafee drivers MfEVTPS monitores and only allow those process which are sighned by McAfee and Microsoft so no digital signature exchange here.any idea?