Configuring Symantec's Antivirus Client for Non-Administrator Updates

In today’s patch-or-die world, online updates are fast becoming an industry standard. Most major hardware and software players, including vendors of virus and spyware scanners, offer this technology. In some cases, you can avoid granting local administrative rights by installing and configuring each vendor’s push technology. Push technology adds another layer of complexity to managing desktop security: You need the hardware and disk space to store updates; you must learn how to install and configure each vendor’s push application; you need to verify that updates are downloaded successfully; you might need to review, test, and manually approve updates and you must verify that the push technology is actually distributing updates and backing up each push application and its associated patch files. You also need to monitor security holes that can let a malicious user compromise each vendor’s online update and push software. (Aside to vendors: Are you aware of any security flaws in your online update or push software? Do you test new versions for potential security holes? Do you disseminate such information?)

Implementing internal update servers is a manageable task for companies with a large budget and requisite technical expertise. Small and mid-sized businesses have smaller budgets and less technical acumen; thus they're more vulnerable to cyber threats and damages. Implementing internal update servers and push technology as a workaround for the local administrator rights problem shouldn't be necessary.

I recently took on the task of eliminating Symantec’s Antivirus Corporate Edition administrator requirement for a mid-sized business. I’m singling out Symantec only because I had to solve this particular client's problem; I’m sure other valid examples exist (HP’s Photosmart software, for one). I also need to acknowledge that the client is running Antivirus Corporate 7.5, and newer versions might already have addressed these concerns.

I searched Symantec's support site for the terms “administrator,” ”rights,” and “liveupdate” and turned up a whopping 94 articles, most of which affirmed that you can't run Symantec’s LiveUpdate utility without local administrator rights. I found an article that explains how to fine tune how LiveUpdate operates. The article "Restricted users cannot run LiveUpdate under Windows 2000" (Document ID: 2000100614565548) offers two methods for running LiveUpdate without local administrator rights.

If you don’t want to implement the company’s managed client software, you can use either method on a single machine, a group of machines, or across an enterprise. LiveUpdate in Antivirus Corporate client 7.x and later uses the registry value entry EnableAllUsers to determine whether local administrator rights are required. When this entry has a value of 1, any logged-on user can run LiveUpdate manually. During testing, LiveUpdate also ran as scheduled when nobody was logged on, although the reference article doesn't document this feature.

To enable LiveUpdate for any user, start a registry editor that lets you change the permission mask on registry entries. Navigate to the HKEY_LOCAL_MACHINE\Software\Intel\Landesk\VirusProtect6\CurrentVersion\PatternManager registry subkey. Make sure the value of the EnableAllUsersentry has a value of 1. If the entry EnableAllUsers is not present in the right-hand pane, create it, give it a data type of REG_DWORD, and a value of 1. If you want to make this change on multiple systems, you can use a registry script. Open a text-only editor, paste in the following code, and save the file as liveupdate.reg.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Intel\LANDesk\VirusProtect6\CurrentVersion\PatternManager] "EnableAllUsers"=dword:00000001

To run the script, simply double-click liveupdate.reg file on each system. The article doesn't tell you to restart the virus client service or reboot. If the code reads this setting every time it runs, you should be able to log on as an ordinary user and manually run LiveUpdate. If the manual update fails, restart the Symantec AntiVirus Client service and try again. You can disable a non-administrator update by setting EnableAllUsers to zero or by deleting the EnableAllUsers value entry.

If you operate in a more secure environment, you can fine tune LiveUpdate to run only for a specific user or group using the second method documented in the article. The instructions tell you to grant Full Control to the user or group for several registry keys and directories. When a user has Full Control on antivirus registry keys and directories, malware running in the context of the user can delete the keys and directories, possibly disabling the scanner.

After experimenting, I determined that LiveUpdate will run without Full Control (Symantec, please address this in your documentation). I removed permissions that let the user write an ACL or change the owner of the key, but I didn’t have time to isolate the minimum set of permissions. I also discovered that the ACL on the HKEY_LOCAL_MACHINE\Software\Symantec\InstalledApps subkey must enable the Create Subkey permission. I’m not sure I understand why, unless the code is using this portion of the registry as a temporary buffer. Each time you change the permission masks, close the registry, restart the client service, log on as an non-administrative user and verify you can manually run LiveUpdate.

The article states that these registry changes let a logged on user run LiveUpdate manually, but doesn't discuss whether LiveUpdate will run when nobody is logged on. After making these modifications on a Windows XP Service Pack 2 (SP2) test machine, I verified that the manual update worked. Next, I scheduled LiveUpdate to run and logged off. When I logged back on as an ordinary user, the date and time field indicated that LiveUpdate had successfully downloaded new definitions.

Purveyors of online update technology can significantly reduce the potential consequences of malware by eliminating the need for local administrator rights and by eliminating the need to touch every desktop with registry modifications to accomplish this goal. When you multiply the time it takes to propagate such changes by the number of online update utilities, the workload in our patch-or-die universe increases immensely. Instead of giving us client-management code that requires more hardware, software, manpower, and dollars, vendors should implement updates that run securely in the user context and with the fewest permissions possible. Feel free to add the name of other vendors who implement updates this way in the Comments section at the bottom of this page.

End of Article