Problem with rm -rf : permission denied

[michaelherrick]

Hi Everyone,

I am working on a policy to remove SentinelOne security software by simply using rm -rf to rip out the files, because the deactivation process from the product's console is time consuming and unreliable. I have a very basic sh script to remove the files line by line:

#!/bin/sh
sudo rm -rf /Library/Sentinel
sudo rm -rf /Library/LaunchDaemons/com.sentinelone.sentineld-guard.plist
sudo rm -rf /Library/LaunchDaemons/com.sentinelone.sentineld-helper.plist
sudo rm -rf /Library/LaunchDaemons/com.sentinelone.sentineld.plist
sudo rm -rf /Library/LaunchAgents/com.sentinelone.agent.plist
sudo rm -rf ~/Library/Preferences/com.sentinelone.SentinelAgent.plist

However, for every file (except for the one in the ~/library) , the result is "Permission denied". The files & directory in question are owned by root, would it make sense to try and chown them to the local management account that JAMF uses on the enrolled macs?

Thanks,

-Mike

[millersc]

That is not defining which User's Library your trying to purge.

Add something like:

# Find logged in user
loggedInUser=$(stat -f%Su /dev/console)

sudo rm -rf /Users/$loggedInUser/Library/Preferences/com.sentinelone.SentinelAgent.plist

[mm2270]

What happens if you switch to root and then try to delete one of them:

$ sudo -s
$ [Enter Password]
$ rm -f /Library/LaunchDaemons/com.sentinelone.sentineld-guard.plist

I don't know anything about SentinalOne, but I'm wondering if when the plists and other files are deployed from the vendor package if its making the files system immutable. This would kind of make sense since its a security product and would want some way of protecting itself from malware trying to remove it. Setting the system immutable flag is done by running the following command on a file:

sudo chflags schg /path/to/file

When this is done, even doing a sudo rm against the file will fail. The immutable flag must be removed before it can be deleted. This is done like:

sudo chflags noschg /path/to/file

Usually when this flag is set, the error isn't "permission denied" but "Operation not permitted", so I don't know if this is the issue, but worth giving it a try to see.

Outside of this, perhaps someone who uses the product will chime in with the correct answer for you.

[michaelherrick]

I altered the script to this:

#!/bin/sh
# Find logged in user
loggedInUser=$(stat -f%Su /dev/console)
#Remove plist from user library
sudo rm -rf /Users/$loggedInUser/Library/Preferences/com.sentinelone.SentinelAgent.plist
#remove immutable flags from files in /Library
sudo chflags -R noschg /Library/Sentinel
sudo chflags noschg /Library/LaunchDaemons/com.sentinelone.sentineld-guard.plist
sudo chflags noschg /Library/LaunchDaemons/com.sentinelone.sentineld-helper.plist
sudo chflags noschg /Library/LaunchDaemons/com.sentinelone.sentineld.plist
sudo chflags noschg /Library/LaunchAgents/com.sentinelone.agent.plist
#remove files
sudo rm -rf /Library/Sentinel
sudo rm -rf /Library/LaunchDaemons/com.sentinelone.sentineld-guard.plist
sudo rm -rf /Library/LaunchDaemons/com.sentinelone.sentineld-helper.plist
sudo rm -rf /Library/LaunchDaemons/com.sentinelone.sentineld.plist
sudo rm -rf /Library/LaunchAgents/com.sentinelone.agent.plist

Still the same "Permission denied" on every file.

[millersc]

Hmm... can you post the actual error message?

[michaelherrick]

Here's the error log from the JSS

Executing Policy Remove SentinelOne
Running script Force remove SentinelOne...
Script exit code: 1
Script result: rm: /Library/Sentinel/_sentinel/assets/arbiter.db: Permission denied
rm: /Library/Sentinel/_sentinel/assets/arbiter.db.sig: Permission denied
rm: /Library/Sentinel/_sentinel/assets/signatures.db: Permission denied
rm: /Library/Sentinel/_sentinel/assets/signatures.db.sig: Permission denied
rm: /Library/Sentinel/_sentinel/assets: Permission denied
rm: /Library/Sentinel/_sentinel/certificates: Permission denied
rm: /Library/Sentinel/_sentinel/com.sentinelone.sentineld.defaults.plist: Permission denied
rm: /Library/Sentinel/_sentinel/config/Config.plist: Permission denied
rm: /Library/Sentinel/_sentinel/config/CrashReporter.plist: Permission denied
rm: /Library/Sentinel/_sentinel/config/Detection.plist: Permission denied
rm: /Library/Sentinel/_sentinel/config/General.plist: Permission denied
rm: /Library/Sentinel/_sentinel/config/Server.plist: Permission denied
rm: /Library/Sentinel/_sentinel/config: Permission denied
rm: /Library/Sentinel/_sentinel/db/quarantine/000005.ldb: Permission denied
rm: /Library/Sentinel/_sentinel/db/quarantine/000048.log: Permission denied
rm: /Library/Sentinel/_sentinel/db/quarantine/CURRENT: Permission denied
rm: /Library/Sentinel/_sentinel/db/quarantine/LOCK: Permission denied
rm: /Library/Sentinel/_sentinel/db/quarantine/LOG: Permission denied
rm: /Library/Sentinel/_sentinel/db/quarantine/LOG.old: Permission denied
rm: /Library/Sentinel/_sentinel/db/quarantine/MANIFEST-000047: Permission denied
rm: /Library/Sentinel/_sentinel/db/quarantine: Permission denied
rm: /Library/Sentinel/_sentinel/db/settings/000097.log: Permission denied
rm: /Library/Sentinel/_sentinel/db/settings/CURRENT: Permission denied
rm: /Library/Sentinel/_sentinel/db/settings/LOCK: Permission denied
rm: /Library/Sentinel/_sentinel/db/settings/LOG: Permission denied
rm: /Library/Sentinel/_sentinel/db/settings/LOG.old: Permission denied
rm: /Library/Sentinel/_sentinel/db/settings/MANIFEST-000096: Permission denied
rm: /Library/Sentinel/_sentinel/db/settings: Permission denied
rm: /Library/Sentinel/_sentinel/db/state/111525.ldb: Permission denied
<huge list of files snipped out of here for brevity>
rm: /Library/Sentinel/_sentinel/db/state/CURRENT: Permission denied
rm: /Library/Sentinel/_sentinel/db/state/LOCK: Permission denied
rm: /Library/Sentinel/_sentinel/db/state/LOG: Permission denied
rm: /Library/Sentinel/_sentinel/db/state/LOG.old: Permission denied
rm: /Library/Sentinel/_sentinel/db/state/MANIFEST-191850: Permission denied
rm: /Library/Sentinel/_sentinel/db/state: Permission denied
rm: /Library/Sentinel/_sentinel/db/transient/000003.log: Permission denied
rm: /Library/Sentinel/_sentinel/db/transient/CURRENT: Permission denied
rm: /Library/Sentinel/_sentinel/db/transient/LOCK: Permission denied
rm: /Library/Sentinel/_sentinel/db/transient/LOG: Permission denied
rm: /Library/Sentinel/_sentinel/db/transient/MANIFEST-000002: Permission denied
rm: /Library/Sentinel/_sentinel/db/transient: Permission denied
rm: /Library/Sentinel/_sentinel/db: Permission denied
rm: /Library/Sentinel/_sentinel/Library/Preferences/com.apple.LaunchServices: Permission denied
rm: /Library/Sentinel/_sentinel/Library/Preferences: Permission denied
rm: /Library/Sentinel/_sentinel/Library: Permission denied
rm: /Library/Sentinel/_sentinel/quarantine: Permission denied
rm: /Library/Sentinel/_sentinel/scratch/com.sentinelone.crashreporter.tcMUtu: Permission denied
rm: /Library/Sentinel/_sentinel/scratch: Permission denied
rm: /Library/Sentinel/_sentinel: Permission denied
rm: /Library/Sentinel/compatibility_version.txt: Permission denied
rm: /Library/Sentinel/library_version.txt: Permission denied
rm: /Library/Sentinel/sentinel-agent.bundle/Contents/_CodeSignature/CodeDirectory: Permission denied
<more files snipped out>
rm: /Library/Sentinel: Permission denied
rm: /Library/LaunchDaemons/com.sentinelone.sentineld-guard.plist: Permission denied
rm: /Library/LaunchDaemons/com.sentinelone.sentineld-helper.plist: Permission denied
rm: /Library/LaunchDaemons/com.sentinelone.sentineld.plist: Permission denied
rm: /Library/LaunchAgents/com.sentinelone.agent.plist: Permission denied
Error running script: return code was 1.
Running Recon...
Retrieving inventory preferences from MY.JSS.COM
Locating accounts...
Locating package receipts...
Searching path: /Applications
Locating software updates...
Locating printers...

[millersc]

Without knowing the product, it looks like it's running still and can't remove anything because of that. Can you check activity monitor and see if it has a daemon or something still loaded or running? Might be able to do an unload and then continue running the script if so.

[alexjdale]

Security applications like this can in fact protect themselves from being removed, I've seen this with other products that are designed to be (relatively) tamper-proof. I assume there's a kernel extension installed as well?

[mcooper]

Have you tried unloading the daemons/agents with launchctl before deleting them?

In Terminal run sudo launchctl list to get a listing of, and verify the daemons/agents that are running.

In your script you should be able to use something like:
launchctl unload -F /Library/LaunchDaemons/com.sentinelone.sentineld-guard.plist for each of the different daemons/agents running, then delete the files.

[mm2270]

Hmm. While it's possible unloading the launchd job first will let you delete it, I can't say I've ever seen a case when you were not able to delete a launchd plist file unless its associated job was unloaded first. Maybe it's something new I haven't run into before though?

That being said, unloading first, then deleting it is best practice.

[djdavetrouble]

Maybe the immutable bit is set.

[AVmcclint]

I've seen this same thing with McAfee Endpoint Security. With McAfee there is a file buried somewhere (I can't remember the location right now) that defined all the protected files and directories relating to McAFee. If the path was listed in this file, you would not be able to delete it even as root. It makes sense for security software to protect itself from improper deletion, but it becomes a royal pain in the butt when the McAfee uninstaller fails to properly remove the software.
I would suspect that SentinelOne has a similar file telling the OS to not let anyone (even root) modify those files.

[michael-brodt]

You may want to try putting the Mac into Target Disk Mode and trying to delete them from another computer. That can usually get around these issues.

The best option is always an uninstaller from the manufacturer, of course. My only other thought off the top of my head (pre-coffee) is to use Composer or another package utility to re-create the installer so you can uninstall as well.

[charles_hitch]

Check to see if the uchg flag is set. Similar to the schg you tried already. If uchg is set it would prevent you from modifying or deleting the file even as root.

[cubandave]

@michaelherrick did you have any luck with this?

[signetmac]

I second what @charles.hitch said. I've never had an occasion to use noschg on a Mac.

sudo chflags -R nouchg [whatever]

...has always done the trick for me.

[csa]

This might be a bit late in this thread but just in case someone is looking, try this https://gist.github.com/Ambroos/f6f37398e3aecd7da467cbcf85d5299b

I have had 90% success with it, not sure what stops it on some machines as yet.