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

Hi,

Seen this but this is regarding appending a file (not services) so with me limited knowledge on this subject this is somehow difficult to understand what is going on.

How do I get rid of this notification / alert in the monitoring. By allowing this file or is this a fall positive?

Everything seems to work by the way.

Henk.

Hello @HenkR ,

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

Regards,

Josh

@Josh Perkoff Henk is working on a regular Linux MA 😉

@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 @HenkR 

Was commvault installed on a non-default location?

Thanks,

Sparsh

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 @HenkR 

This issue doesn’t seem to be occuring because of Ransomware protection. Was this working in beginning, and started giving error recently?

type=AVC msg=audit(1662726564.338:34): avc:  denied  { append } for  pid=2248 comm="Galaxy" name="Galaxy.env" dev="sdb3" ino=45978 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:usr_t:s0 tclass=file permissive=0

My suspicion is that either SELinux labels might not be proper on the commvault installation path OR it might be a result of RedHat tightened security + a combination of manual settings enabled on client.

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

Can you correct the SELinux labelling on Commvault directory by executing below commands?

# commvault stop

# semanage fcontext -a -t usr_t "/opt/commvault(/.*)?"
# /sbin/restorecon -vR /opt/commvault/*

# commvault start

Once the above commands are executed and the denials are not noticed anymore, please follow BOL to enable ransomware protection (if that’s the end goal).

Thanks,

Sparsh

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