Solved

For SELinux, must/should/could false positive AVC denials be ignored by using sealert -a /var/log/audit/audit.log and the policy extended via ausearch and semodule?

  • 11 October 2021
  • 4 replies
  • 715 views

Badge +1

RHEL 7.9 and SELinux have tools such as sealert to report on avc denials.  We are seeing many false positive alerts, and they are inconsisent across nodes. Overall about 22 false positives.

  1. Why are these false positives triggered inconsistently across nodes?
  2. Is using sealert to find alerts recommended? If so, is reducing the false positives using ausearch and semodule to generate local policies recommended or frowned upon?
  3. Is there a better way?

Thanks.


Marc

icon

Best answer by SparshGupta 12 October 2021, 07:04

View original

4 replies

Badge

See if details in

https://documentation.commvault.com/11.24/expert/24204_selinux_configuration.html

and

https://documentation.commvault.com/11.24/expert/24206_troubleshooting_selinux_configuration.html

answers your queries, as there are some additional settings that may be required.

Userlevel 4
Badge +10

Hey @MarcS 

 

Could you paste some denials that you have been noticing across nodes? Also, are the machines in enforcing mode or permissive mode? Are the denials causing issues with any Commvault operations like data protection jobs?

 

RedHat keeps tightening security and confinement between processes by modifying SELinux policy (combination of rules that guides the SELinux security engine) behavior with each release. Also, depending across SELinux settings, Booleans enabled on client and domain transition mappings, the denials can vary across different machines.

 

Meanwhile, you can use the troubleshooting section mentioned in link above to create a custom rule and bypass the denials.

https://documentation.commvault.com/11.24/expert/24206_troubleshooting_selinux_configuration.html

 

Thanks,

Sparsh

Badge +1

Thanks for the assist @SparshGupta .  The media agents are in enforcing/targeted mode. The denials do not appear to be interfering with the CommVault operations, thankfully.  

Grepping the output of sealert and removing dupes, I get


Hash  abrt-hook-ccpp,abrt_dump_oops_t,cvbackup_exec_t,file,getattr
Hash  cvd,unconfined_service_t,cvstorage_t,dir,add_name
Hash  CvMountd,unconfined_t,cvstorage_t,dir,add_name
Hash  df,logrotate_t,var_t,dir,read
Hash  df,sosreport_t,cvstorage_t,filesystem,getattr
Hash  eu-unstrip,abrt_t,cvbackup_exec_t,file,open
Hash  eu-unstrip,abrt_t,cvbackup_exec_t,file,read
Hash  iptables,iptables_t,var_run_t,file,open
Hash  iptables,iptables_t,var_run_t,file,read
Hash  locate,setroubleshootd_t,cvstorage_t,dir,read,search
Hash  logrotate,logrotate_t,auditd_log_t,file,getattr
Hash  lsof,sosreport_t,cvbackup_exec_t,file,getattr
Hash  mail,fsdaemon_t,etc_runtime_t,file,append
Hash  mail,fsdaemon_t,root_t,dir,write
Hash  mkdir,logrotate_t,default_t,dir,write
Hash  setroubleshootd,setroubleshootd_t,cvbackup_exec_t,file,getattr
Hash  setroubleshootd,setroubleshootd_t,cvstorage_t,dir,getattr
Hash  setroubleshootd,setroubleshootd_t,cvstorage_t,dir,search
Hash smartd,fsdaemon_t,nvme_device_t,chr_file,ioctl
Hash  smartd,fsdaemon_t,nvme_device_t,chr_file,open
Hash  smartd,fsdaemon_t,nvme_device_t,chr_file,read
 

Are these denials due to misconfiguration?

Userlevel 4
Badge +10

Hey @MarcS 

 

The denials does not necessarily indicate any misconfigurations in itself. 

 

SELinux denies every action that it is not explicitly allowed by the SELinux policy.

 

Few of the most common causes why SELinux denies an action are:

  • Processes, files, or directories are labeled with incorrect SELinux context
  • Confined processes are configured in a different way than what is expected by the default SELinux policy

 

For instance, from the output you pasted, looks like SELinux is trying to prevent Commvault processes such as cvd and CvMountd, “add_name” or add a file to a directory permission. This could be due to a simple label mismatch for the SELinux context type for these binaries or a missing type enforcement rule.

 

If the intention is to investigate the denials individually, you can check “sealert -a /var/log/audit/audit.log” output which will print the reason for each denial along with plugin catchall confidence score and steps to resolve.

 

For now, the simplest way would be to create a custom local policy module to allow the access using audit2allow and semodule commands for specific denials (such as commvault processes i.e cvd, CvMountd) or all denials (commvault processes + kernel / networking / filesystem layer such as df, logrotate)

 

grep –E "cvd|CvMountd" /var/log/audit/audit.log | audit2allow -M backup_IDA_1

semodule -i backup_IDA_1.pp

 

Additionally, we would like you to open a ticket with Commvault so that we could investigate it further as well.

 

Thanks,

Sparsh

Reply