commvault.com commvault.com
Question

selinux context

downhill
Rank
Userlevel 2
Badge +7

We noticed on a RHEL8.7 build with a local disklib & ransomware enabled that it breaks xfs utils.

Opened a case with RH support. They said for mount options “try context=unconfined_u:object_r:user_home_dir_t:s0” instead of the recommended “context=system_u:object_r:cvstorage_t:s0”, which does fix the issue with xfs commands. Now they are asking me to ask you all do other customers have the same experience? Or, they suggested use the context that “allows xfs to work” to which I replied “I have no idea but this is what the script sets up”.

Basically if you setup a diskib using xfs (not NFS or S3 obviously), simply try to run xfs_info or xfs_growfs, can’t be done. The workaround I found if I need to grow the FS is stop service, remount without ransomware context in place (or use their options), fiddle with xfs, then remount with proper context.  Looking for some way to fix rather than workaround but they seem firm in “it’s not a problem” with selinux or xfs, it’s the way it’s mounted.

thanks

11 replies

Arunkumar P
Rank
Userlevel 2
Badge +7

@downhill - We have not observed with any of the customer so far and mounting with the below context will create a problem while reading/writing the data to the library. Also, it’s quite dangerous because it’s not protected by CV. 

context=unconfined_u:object_r:user_home_dir_t:s0

downhill
Rank
Userlevel 2
Badge +7

I would imagine you guys have a lab box you can reproduce the problem on (or not). It’s very simple - just run xfs_info /your/mount/path and see what happens.

thanks

L
Rank
Userlevel 6
Badge +15

hi ! it’s been a while. I ‘m so busy I have almost no time for communities.

And even today I’m reviewing the Communities because, trying to be trendy, deploying a new linux MA and infrastructure, I tried to apply so called best practices and enable anti-ransomware protection on the MA using the cvsecurity.ph script described here

https://documentation.commvault.com/v11/expert/126093_configuring_ransomware_protection_for_linux_mediaagent.html

1st, I’m using RHLE8 and Python3 is used, but script looks for ‘pyhton’, not ‘python3’ binary executable. ==> Had to create an alias (boo) to execute the .py script(s).

 

Then, 1st script execution worked, requesting MA reboot, which I performed.

Commvault services looked OK, then step 7 :

./cvsecurity.py restart_cv_services -i InstanceID

And that’s where the mess starts.. 

Stopping services worked.

Starting services failed.

And impossible to have it restarted.

Checking logs : 

SELinux is preventing /cv/commvault/Base64/cvrcgmgr from write access on the file .global.lock.

                                                            *****  Plugin catchall_labels (83.8 confidence) suggests   *******************

                                                            If you want to allow cvrcgmgr to have write access on the .global.lock file                                                             Then you need to change the label on .global.lock                                                             Do                                                             # semanage fcontext -a -t FILE_TYPE '.global.lock'                                                             where FILE_TYPE is one of the following: NetworkManager_unit_file_t, abrt_unit_file_t, accountsd_unit_file_t, afs_cache_t, alsa_lock_t, alsa_unit_file_t, amanda_unit_file_t, antivirus_unit_file_t, apcupsd_lock_t, apcupsd_unit_file_t, apmd_lock_t, apmd_uni>                                                             Then execute:                                                             restorecon -v '.global.lock'


                                                            *****  Plugin catchall (17.1 confidence) suggests   **************************

                                                            If you believe that cvrcgmgr should be allowed write access on the .global.lock file by default.                                                             Then you should report this as a bug.                                                             You can generate a local policy module to allow this access.                                                             Do                                                             allow this access for now by executing:                                                             # ausearch -c 'cvrcgmgr' --raw | audit2allow -M my-cvrcgmgr                                                             # semodule -X 300 -i my-cvrcgmgr.pp
 

And hell, what’s this???

I’m a backup guy, not a linux security guy. 

Looks like something did not work during the execution of those scripts, but it was not printed (I have the logs showing ‘success’ everywhere before), and now all is stuck.

 

There’s not much in the docs, so it looks like i’m stuck and have to call the support. 🙄😭

Expect a new hotfix in the next releases, then…

 

 

==> My thought on ‘antiransomware’ on linux : DON’T activate this, even if your manager is harrassing you to do it.

Just secure your linux so noone gets in or root access. 

As, 1) it offers no protection if anyone has root privileges

  1. you’ll be in trouble for many times and won’t know why (well, it would be because of this..)
  2. Documentation is outdated and scripts too

 

downhill
Rank
Userlevel 2
Badge +7

I tend to disagree. SELinux is the way to go if you want to do as much as possible to prevent things being removed or whatnot and IMO, the more recent updates have eliminated many of the issues.

Keep in mind that your base build - how the box is configured BEFORE installing Commvault and enabled via the script DOES potentially impact how SELinux gets enforced. The context of paths should be verified with matchpathcon. If they are not correct before, Cv can’t fix things. If SELinux was never in place at all, then you probably have a case because the contexts for their files should be correct.

Now, do I disagree that someone with root can foil this all - not at all, it’s not magic - but if you have people roaming your nix boxes as root that your don’t intend, you’re probably already toast eh - so then what? It’s a deterrent and good practice to use SELinux if nothing else.

The minor inconvenience of me having to pause protection before using certain XFS utils does bug me but it goes to the point of - you really, really need to either have root to break the box once this is enabled OR you have not followed the docs precisely. My RHEL 8 boxes have python 3 and setting a symlink or 2 is pretty common isn’t it? To me the install documentation is correct but steps and order cannot be skipped because “you know how to build a nix MA”, this is probably the most common problem. That’s not to say the specific version you are running might have a bug but I’ve been running this for over a year and built up several new nix boxes. As I said, in earlier FRs the services would be very slow to stop and of course some xfs commands won’t work with it enforcing, so, open a case- this is how they can make it better. I have had zero issues other than that. just my 2 cents but I feel your frustration. 

L
Rank
Userlevel 6
Badge +15

Thanks @downhill 

Yes I am quite furious and frustrated. I don’t setup MAs every day, nor do I declare selinux is crap.

My RHEL 8.7 is brand new, freshly setup, and selinux was virgin from any user or application modification. v11.28.83..

We do have some XDR tool that should be installed when I would complete the Commvault configuration, so even this one does not interfer so far. 

I’m not skilled enough at linux/security to know what to do to solve this for got.

Like just disabling selinux, starting commvault, and reactivating it, works.

So the policy/created by scripts is wrong.. 

Case @support for the solution...

L
Rank
Userlevel 6
Badge +15

Oww, much better… 😡

L
Rank
Userlevel 6
Badge +15

Well.. a bit of feedback as more than 24hours after my censored post (don’t know why), nothing really changed. 

Case open with support (Incident 230928-506)

Already applied https://kb.commvault.com/article/69303 but no changes, even after a reboot.. 

Waiting to be called-back by support for next steps..

Regards,

Laurent.

 

L
Rank
Userlevel 6
Badge +15

Case escalated to development team.

L
Rank
Userlevel 6
Badge +15

Case still escalated to dev.

Got a question today, to check if I had tried to manually restart services (which were already attempted + reboot performed). So, callback counter reset to another 5 days… 🤐😤😭

@Arunkumar P any chance you or one dev teammate could have a look at this ?

I’m stuck since more than 10 days now.. 

Thank you of anything you could do to push up this case.

M
Rank
Userlevel 3
Badge +6

Hi @Laurent,

 

It sounds like you need to reach out to your account team to get this escalated on your behalf.


Regards,

Mike

L
Rank
Userlevel 6
Badge +15

This has been fixed in session with Dev and Support team. Thanks to them.

So, explanation is that, as I do not use the default paths to install Commvault software, the scripts to enable ransomware would fail to target my ‘custom’ paths, resulting in this issue.

Support told that this is fixed in FR34 (i’m on FR28/2022E).

 

That’s for your knowledge, in case of 😊

Reply


Terms & ConditionsCookie settings