Your security group wants to block all usage of the Temp folders under Users and Windows (on the SMP Server, Site Servers, and Client Machines). Also, they need to do the same on any folder named TEMP such as C:\USERS\Temp and C:\Windows\Temp.
Is there a way to define temporary folders for Symantec Management Agent executable files?
ITMS 8.x
There are quite a few scenarios where temp files get created in Symantec Management Agent (SMA):
1. installer extracts package into temp folder and executes setup application from there
2. installer self-removal includes script execution from the temp folder
3. UNC package transfer in certain scenarios writes files to temp folder
4. HTTP data or package transfer writes files to temp folder in certain scenarios
5. UNC/HTTP data transfer can include data compression or decompression into temp files
6. NSE processing can write into temp folder in certain usage scenarios
7. CTA writes scripts into temp folder for execution (in 8.5 RU4 it writes them into folder in ProgramData)
SMA plugins can use temp folders as well.
Temp folder or files created by SMA are usually named AeX_<guid> with or without an extension, like:
AeX_{FC08942A-D8B7-477F-9069-464222812936}
AeX_{FC08942A-D8B7-477F-9069-464222812936}.tmp
SMA creates temp folders into system or user-specific temp folders.
The usage of Temp directories is the normal Windows design. We cannot imagine Microsoft prohibit temp folder usage and expect every kind of software and OS itself to work. Apps need to create temp files, if they do not want to allow apps to execute files from temp folder then they can set the appropriate security descriptors. SMA service writes temp files into Windows\Temp under SYSTEM account, so here is the first way to cut the viruses - disable user accounts to write files in there. If virus code runs elevated due to some IE vulnerability then there is no protection anyway - it can save file wherever it wants.
Starting with our ITMS 8.5 RU4 release, the following has been implemented as a way to help to avoid the usage of Temp folders (See ITMS 8.5 RU4 Release Notes):
Ability to define temporary folders for Symantec Management Agent executable files.
|
The targeted agent advanced configuration settings let you define the temporary folder for executable files that the Symantec Management Agents can create.
|
The change allows the following:
The folder where SMA can store executable files can be configured in targeted policies, see "Advanced" page. You can use environment variables in the path. The customer will need to configure "Working Folders" on "Advanced" tab of the desired Targeted Agent Settings policy (SMP Console>Settings>Agents/Plugins>Symantec Management Agent>Settings) and specify the folder where SMA can write executable files.
The default value is %ProgramData%\Symantec\Symantec Agent\TempExecutables. If you specify a bad value as a path then the default value will be used by the agent. Look for the word "temporary" in the log to see info about the temp folder actions.
So far we identified two places in SMA/CTA/SMF that could create executable scripts in temp folders - script task and restart service task. If more places are identified in the future then all of them will need to be addressed separately.
This path gets written by the agent into "HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Folders key". The key is allowed to access by SYSTEM and Admins only. NO browser with UAC on can write in that location.
The change to CTA is that now it creates <guid> temporary folder for script task in the folder configured in the registry instead of C:\ProgramData\Symantec\Symantec Agent\ScriptTasks.
"Control Service State" task, "restart service" part of the task has been changed - it also creates the script to restart service and now it creates that script the same way as script task does. You can restart SMA itself using this task, the created temp folder should be removed
One more change is added to handle XP/2003 (and recent OS versions). There is no %ProgramData% on XP, so it gets replaces to "%ALLUSERSPROFILE% \Application Data" internally.
Overall there are not so many environment variables you can use to build the path that works on all the platforms: