search cancel

Unexpected behavior with HFSSEC rules and Symbolic links after deleting ACF2 rules

book

Article ID: 240119

calendar_today

Updated On:

Products

ACF2 - z/OS

Issue/Introduction

symbolic links in OMVS for unix directories.
For Example:

lib -> $VERSION/lib
etc -> $SYSNAME/etc
bin -> $VERSION/bin
 
Rules existed for both $KEY(/etc) and $KEY(/SYS1)
 
Someone accessing /etc would actually be accessing /SYS1/etc (on LPAR SYS1).
This would be hitting $KEY(/SYS1) and should not be using the $KEY(/etc) rule. 

When $KEY(/etc) TYPE(HFS) was deleted violations occurred for these resources.
RHFS-/etc.Vendor.ibm.Apache.V9R0.bin.httpd      *VIO  RHFS-/etc
RHFS-/etc.Vendor.lrs.vmcf.ihsa.#.plugin                *VIO  RHFS-/etc  
 
When displaying the symbolic link it appeared as though the link information was no longer available
 
 
lrwxrwxrwx     1 BPXOINIT OSS           12 Jun 16  2015 etc -> $SYSNAME/etc
However after deleting the $KEY(/etc) the link looks like this.
lrwxrwxrwx     1 BPXOINIT OSS           12 Jun 16  2015 etc
 
 

Cause

When an actual file is accessed via a symbolic link, the file name passed to ACF2 has been resolved to the
actual file name of the file and validation is done based on that actual file name.
For most validation situations this is sufficient.
However, in the case of the following, ACF2 validates the link itself rather than the file name:

unlink (delete a symbolic link)
rename (change one symbolic link name to another)
readlink (read a symbolic link to determine what it points to)
lchown (change the owner of a link)

Environment

Release : 16.0

Component : ACF2 for z/OS

Resolution

an HFS sectrace showed that when opening a directory  a readlink event occurs.
The readlink requires access to the $KEY(/etc) per above documentation.


 CAS2319I TRACEID=HFS   USER=USER01  JOBNAME=USER01      
          EVENT=opendir                                            
          /                                                        
          READ                                                     
          /                                                        
          SAF FASTAUTH return codes: 00000000/00000000/00000000    
          Exit with return code = 00      
                        
 CAS2319I TRACEID=HFS   USER=USER01  JOBNAME=USER01 620       
          EVENT=readlink                                           
          /etc                                                     
          READ                                                     
          /ETC                                                     
          SAF FASTAUTH return codes: 00000008/00000008/00000000    
          Exit with return code = 08                               
 CAS2312E USER01  - READ    ACCESS DENIED 621                     

This proves that the problem relates to the READLINK event requiring the $KEY(/etc) resource rule.
Access is required to both the link name and the symbolic that it points to.

Without access to the link name you cannot point to the symbolic.
That is why the symbolic link looked like data had been removed when the rule was deleted.