McAfee ePO for OS X

| Comments

In my environment we have had a McAfee license for our Windows workstations since long before I joined the company. The task of administering the antivirus for all this workstation is done by our McAfee administrator using the ‘ePolicy Orchestrator’ console, also called ePO among friends.

Not long after I joined the decision of protecting workstations while they were running OS X was taken and the decision was to extend the license we already had and go with McAfee.

This, of course, brought up some challenges to our ePO administrator (an all time Windows guy) that he wasn’t quite prepared to face, at least not without the proper training. So the tasks were given to me as the OS X sysadmin, first task was the initial deployment.

The ePO server had to be upgraded in the first place and once that was done I received a call and an email that basically was the ‘installer’ for the OS X clients. “This is a bad start” I thought when I opened the email and saw that the installer was a bash script called of 16.5MB in size. Opening the script with a text editor revealed that the script was actually ~200 lines of bash and an embedded binary for what appeared to be a .dmg and a .zip files!

The way that McAfee works against the centralizes everything in ePO server is by having a ePO agent running on the client and that agent connects to the server to get policies, inform about the status, infections, updates and so on. So I dissected (ctrl+c plus Pacifist did most of the magic) the crappy installer and found out that:

  • The .zip file contains the actual information for the clients to connect to the ePO server through encrypted ssh and https. Things like an xml file containing the dns name and port of your ePO server, a client certificate and so on are here. Nedless to say that this is unique per each environment and should be distributed with some caution. From now on I will refer to this as ‘the keys’.

  • The .dmg contains a normal signed Apple installer that installs the generic ePO agent.

The process of the is as follows

  1. A new folder is created at /Library/McAfee/cma/scratch/keydata
        bash-3.2$ mkdir -p "$keydata_dir"
  2. The keys are copied to the new keydata folder
  3. The .dmg is mounted, a config file with a couple of parameters is written to /etc/mainstall.config and the installer is called agains the root volume
        bash-3.2$ echo "IsLegacyEPO:N" > /etc/mainstall.config
        bash-3.2$ echo "ConfigDirPath:/Volumes/MFECMA" >> /etc/mainstall.config
        bash-3.2$ echo "StartService:Y" >> /etc/mainstall.config
        bash-3.2$ sudo /usr/sbin/installer -pkg cma.pkg -target "/"
  4. The installer deletes the folder that contains the keys and the script cleans the mess.
  5. Changing anything on the script will corrupt the binaries and you will have to trash them.

For managing software in our clients I use Munki so once we know all this the task is simple. You can build a custom pkg to drop the keys into the keydata folder and check whether the keys were installed or not based on the receipt (Munki’s default). The use of pkgbuild here eases the task of mirroring the folder from a test machine.

Then you import the ePO installer, that is a normal Apple installer, and put a <key>requires</key> for the keys.

Once you’ve done all this basically you have moved from a script based installation to a real enterprise-class deployment solution. After this the ePO server is supposed to push the actual anti-malware (called McAfee component to the client computers. You could instead do as I did and get the anti-malware installer, get that into Munki and include a new <key>requires</key> for the ePO agent. This way you have to refer only to the anti-malware in your catalogs manifests and all the necessary components will be included and installed in the correct order.

PS: McAfee/Intel please when adapting your products to a new platform do take some time to adopt the standards. OS X installations when it comes to an enterprise level should not be based on scripts, nor we are used to patching a products but getting a new updated full installer instead. Companies with that amount of money (ejem Adobe!) should stick to the good-know-reliable methods instead of re-inventing the wheel. Things like filling the Info.plist of an .app with the full release version is also a good practice btw.

PS2: I’ll try to publish soon a quick how-to clean the installation of these components, as if you do not do them in the proper order the installations are most likely to fail until a full cleaning is done.