Security Risk? - Automic Unix v12.3 + v21 Agent performs chmod 777 on "/temp" and "/ressources" directory during startup.

[Michael TMO8Y2tl]

Dear all,

it seems that the unix agent performs a chmod 777 on directory "<agentdir>/ressources" and "<agentdir>/temp" during each startup.

Does someone know why chmod 777 is performed during startup? Is there any option to disable that?

Docu: 

Requirements

• User ID AE has been created.
• Privileges for the out (UC_EX_PATH_JOBREPORT) and temp (UC_EX_PATH_TEMP) directory (see List of Agent Variables):

  • Owner: read, write and execute permissions

  • Group: read, write and execute permissions

  • World: read, write and execute permissions

• If permissions are missing, the agent changes the permissions for these directories

[Peter Daransky]

Hi Michael,

no there is no real option to disable that. The temp folder is mostly used for storing the JCL or Report files which are required for Job execution, but the files are created as the user who is specified in the Job's login object...
Similar scenario is with the resources folder where the situation is more complicated. There is the access required for 2 purposes:

1.) you want to start a Job with :ATTACH_RES script command, where you can download some resources before the job get started.
2.) Because of the Backup/Rollback execution, which can be also started under different users 

Means, the folders should be accessible for everyone, but the resources created there, have also own owners and permissions which are not accessible for everyone. 

BR peter

[Michael A. Lowry]

I just realized that the wide-open 777 directory mode opens up the possibility that one user's job could alter, delete, or replace the temporary files belonging to another user's job on the same agent.

It seems like there has to be a more secure way to handle temporary files.

[Michael TMO8Y2tl]

"Means, the folders should be accessible for everyone, but the resources created there, have also own owners and permissions which are not accessible for everyone. "
The files within the temp folder can be deleted and recreated with modified content by anyone, which is from my perspective a big security issue.

[Peter Daransky]

Hi Guys, 
last I have chat with the Unix Guys here regarding this topic, so here are some thoughts on the security concerns. 

Basically the concept is designed for two scenarios:
1. the jobs are started with a specific user
2. the jobs are started with the "agent" user

In the first case the agent needs a softer permissions for the directories as it will be shared among several users. Nevertheless, the files (folders) will be visible/accessible only to the owner (-rw--------).

In the second case everything belongs only to the one user, that is the one who started the agent ...

So there should be no situation when one user/job can modify the files of others.  

BR Peter

[NorbertZ]

Dear Peter,

thank you for the explanation.

Currently, we also have to deal with security findings regarding the "resources" subdirectories.
Basically, it's hard to argue that we have to blindly trust the application that it will always set the right permissions for the files. 

Is there any reason, why the Sticky Bit is not set on the subdirectories?
That would still comply to your two scenarios and would also provide OS-based security. 

I already tried to manually set the Sticky Bit (1777), but the agent is removing it and setting the permissions back to 0777, unfortunately. 

Kind regards
Norbert

[Kaj Wierda]

We are working on addressing this issue as part of our current Program Increment (Aug - Oct) and will change this behavior in an upcoming update.

[Christoph Rekers]

Hi @Kaj Wierda,
Any news on this topic? I have 2 customers who have implemented increased security measures. These say that no folder can have 777 anymore.

Thanks
Christoph 

[Markus Embacher]

Hi Christoph,

please check the Folder* Parameters in the configuration file of the agent.

https://docs.automic.com/documentation/webhelp/english/ALL/components/DOCU/21.0.8/Automic%20Automation%20Guides/Content/InstallAgents/InstallAgentUNIX.htm?Highlight=folderpermission#link4

Regards, Markus

[Josef Scharl]

Hello,

We had the same issue. Security department blamed us for read/write permissions on Agent’s backup, out, resources and temp directory.

According to CIS Red Hat Enterprise Linux 8 Benchmark https://workbench.cisecurity.org/files/2485) “1.1.21 Ensure sticky bit is set on all world-writable directories” the sticky bit to the directories is recommended (if world-writable directories are really needed).

We fixed this during Agent update to Version 21 (21.0.7+hf.2).

1. Our Upgrade Job change the permissions:
   
   ! open working dirs
   echo "chmod 1777 temp out backup resources"
   chmod 1777 temp out backup resources
   check_success $?
   
   
2. The new Agent ini file were enhanced by the following parameters:
   
   [MISC]
   ...
   ;
   ; FolderOwner:
   ; Specified user name or id who becomes the owner of the newly created agent's folder,
   ; default is the user who executes the agent,
   ; if you use a ID instead of name, then this ID will be then used for user and group ownership
   ;
   FolderOwner = uc4
   ;
   ; FolderOwner_backup: Owner of backup directory
   ;
   FolderOwner_backup =
   ;
   ; FolderOwner_temp: Owner of Agent's temp directory
   ;
   FolderOwner_temp =
   ;
   ; FolderOwner_out: Owner of Agent's output directory
   ;
   FolderOwner_out =
   ;
   ; FolderOwner_cache: Owner of Agent's resources cache directory
   ;
   FolderOwner_cache =
   ;
   ; FolderPermissionMask:
   ; specified permission masks is used as default for for newly created Agent's folders
   ; existing folder permissions are not modified
   ; the mask can be used as octal number eg. 777 or as string representation eg. rwxr-xr-x
   ;
   FolderPermissionMask = rwxrwxrwx
   ;
   ; FolderPermissionMask_backup: Permission mask of backup directory, can be used to overwrite the default settings
   ;
   FolderPermissionMask_backup =
   ;
   ; FolderPermissionMask_temp: Permission mask of Agent's temp directory, can be used to overwrite the default settings
   ;
   FolderPermissionMask_temp =
   ;
   ; FolderPermissionMask_out: Permission mask of Agent's output directory, can be used to overwrite the default settings
   ;
   FolderPermissionMask_out =
   ;
   ; FolderPermissionMask_cache: Permission mask of Agent's resources cache directory, can be used to overwrite the default settings
   ;
   FolderPermissionMask_cache =
   ;
   ...
   
   

As you can see it’s not 100% consistent because, the FolderPermissionMask = rwxrwxrwx and not FolderPermissionMask = rwxrwxrwt as it should be.
However, it’s the only way it works – so far as we figured out.

Cheers, Josef