SELinux hardening denied Commvault files but everything works.

Hello @HenkR,

Thank you for reaching out to us on this.

Are you seeing any specific CV services listed in the audit logging, or just the generic “Galaxy” tag?

If you are seeing specific services listed, please follow the steps here:
https://documentation.commvault.com/2022e/expert/24206_troubleshooting_selinux_configuration.html

Regards,

Josh

Hello @HenkR ,

Is this happening on a Linux MA you installed, or a Hyperscale/ScaleProtect node?

Regards,

Josh

@HenkR Not experienced on this specific topic, but looking at the error, at first glance it seems you need to alter the selinux context for the Commvault file related to the error:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-working_with_selinux-selinux_contexts_labeling_files

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/chap-security-enhanced_linux-selinux_contexts

What process is linked to pid 2248?

Hi @SparshGupta ,
Yes it was /opt/commvault.

My concern is that Commvault made its windows integration very simpel and out of the box.  With RHEL it becomes somehow complex if you don’t have the knowledge about this subject. Enabling with cvsecurity.py on mediaagent server gives you more then you expected.

Note : the sdb3 location and file are also involved not only the mountpath which is the boot / root disk. So it seems this disk and probably /opt/commvault files are also involved.

But there is more, selinux als involves system deny on snmp deamons etc… so you have to mitigate also services and other 3th party files.

The articles asume you have a great understanding of selinux which I have not so much. This makes it harder to adopt this as a solution to support. All reports and in Commvault  regarding ransomware is windows based ma servers.

Hi Sparsh,

We added SELINUX after the installation of the mediaagent, no issues where found until they were discovered by a monitoring tool on the linux system (then we where alerted on these denied notifications)

Had some support on this and did the following.

With this (and also other services)  denies are mitigated.

But if this is the correct way?

Havent tried your way of corrections yet.

# audit2allow -M  mz-commvault-tweaks -a

#  cat mz-commvault-tweaks.te

module commvault-tweaks 1.0;



require {

        type snmpd_t;

        type cvstorage_t;

        type pcp_pmcd_t;

        type setroubleshootd_t;

        type sysstat_t;

        class dir getattr;

        class filesystem getattr;

}

#============= pcp_pmcd_t ==============

allow pcp_pmcd_t cvstorage_t:filesystem getattr;

#============= setroubleshootd_t ==============

allow setroubleshootd_t cvstorage_t:dir getattr;

#============= snmpd_t ==============

allow snmpd_t cvstorage_t:filesystem getattr;

#============= sysstat_t ==============

allow sysstat_t cvstorage_t:filesystem getattr;

# semodule -i commvault-tweaks.pp

Rotate audit log (to reset audit.log file)

# pkill -SIGUSR1 auditd

/dev/sdb3 is indeed the physical (os) disk and the server is used as a mediaagent server. The mountpaths are direct attached LUNS over FC.

Monitoring the server and checking the audit logs,  this alert did not occured anymore.

see also:

https://docs.fedoraproject.org/en-US/Fedora/12/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html