Remediating DeepSeek Installations in MacOS

[ThomM]

We have been tasked with blocking DeepSeek on all campus resources. Unfortunately, keeping users from running DeepSeek models locally on their Macs isn’t as simple as making a Restricted Software title in Jamf Pro because the models aren’t actually apps.

What we can work with, however, is Ollama – the framework which DeekSeek models currently run under. If a user has installed Ollama, why not leverage that to check for the presence of DeepSeek LLMs?

Our first step is identifying it. The command ollama list will list all the LLMs a user has currently installed. If we grep those results for deepseek, we can make a little script-based Extension Attribute to identify Macs with DeepSeek LLMs present.

Next, make a Smart Computer Group for detections that looks something like this:

• Criteria “DeepSeek Check” – is not – (blank)
• AND
• Criteria “DeepSeek Check” – is not – Not Detected

(You could probably get away with just one criteria where DeepSeek Check – is like – *deepseek* or do something with regex, but I did not test those.)

Next up, figure out your action plan.  We’ve been asked to do the following:

• Alert the user and ask them to uninstall DeepSeek ASAP.
  • If they feel they need an exemption, direct them to contact our CISO.
• If they ignore us, alert them again.
• If they continue to ignore us, automatically remove it.

We’ve got three policies to make this happen, all scoped to our “DeepSeek Detected” Smart Computer Group.

1. DeepSeek Uninstaller LaunchDaemon
   1. General
      1.          Trigger – Custom – KillDeepSeekDaemon
      2.          Frequency - Ongoing
   2. Script
      1.          DeepSeekRemovalDaemon.sh
         1. Writes a LaunchDaemon to call a policy which runs our auto-uninstall script after a set amount of time. I’ve given our users three days.
      2. DeepSeek Uninstaller
         1. General
            1.          Trigger – Custom – KillDeepSeek
            2.          Frequency – Ongoing
         2. Script
            1.          DeepSeekRemoval.sh
            2.          Takes advantage of the ollama rm command to remove all DeepSeek models.  It also checks for our LaunchDaemon and if found, boots it out and removes it.
         3. Maintenance
            1.          Update Inventory
         4. DeepSeek Alert
            1. General
               1.          Trigger – Login, Recurring Check-in
               2.          Frequency – Once every day
            2. Script
               1.          DeepSeekAlert.sh

JamfHelper is usually my go-to for user alerts, but it only supports two buttons.  I wanted three, so I chose osascript to pop up a series of dialogs. Please use whatever tool fits best for your org.

Our primary alert informs the user that DeepSeek has been detected on their Mac, is not permitted on our computers, and needs to be removed as soon as possible. It presents three buttons:

• Do it for me
  • Triggers the KillDeepSeek policy.
  • Updates Inventory.
  • Thanks the user and tells them DeepSeek has been removed.
• Do it myself
  • Thanks the user and advises them to update inventory from Self Service after removing DeepSeek.
  • Triggers the KillDeepSeekDaemon policy in case the user is trying to get around us.
• No
  • Advises the user to contact our CISO (including CISO’s email address) to discuss an exemption ASAP. Also informs them that DeepSeek will be automatically uninstalled in three days if no action is taken.
  • Triggers the KillDeepSeekDaemon policy.

I should note this does not keep users from getting DeepSeek models through Ollama, but it does help us remediate it if they do.  It is also only effective while Ollama is the only way to run them.  We’ll have to keep an eye out for if – or realistically when – that changes and expand our methods to cover whatever the new hotness is.

[Chubs]

I would code in on the "No" button to create a ServiceNow RITM for an exception and have it go to an approvals queue.  How cool would it be to also code back from ServiceNow into the JAMF API that once it's approved, the devices gets moved into an exception group to not be bothered with this popup again?

These are the types of automations that I'm working on at my current workplace :) 

[Jordy-Thery]

Nice one @ThomM!

[PSankaran]

When i try to add the "DeepseekRemoval.sh" in a recurring policy, the script does not remove the LLMs. However, when i run the same policy, it removes the LLMs successfully. 

Below is the error from policy:

================================

Script result: panic: $HOME is not defined
goroutine 1 [running]: github.com/ollama/ollama/envconfig.Models() /Users/runner/work/ollama/ollama/envconfig/config.go:91 +0xa4 github.com/ollama/ollama/envconfig.AsMap() /Users/runner/work/ollama/ollama/envconfig/config.go:251 +0x70c github.com/ollama/ollama/cmd.NewCLI() /Users/runner/work/ollama/ollama/cmd/cmd.go:1373 +0xbd0 main.main() /Users/runner/work/ollama/ollama/main.go:12 +0x1c panic: $HOME is not defined

[ThomM]

@Chubs Hey, very cool idea thanks!  I'll drop that to our team and see what they think of it too!

@JordyThery Thank you!

@PSankaran My apologies for such a late reply, this got published just as I needed to take an extended leave from work. Thanks so much for the feedback.  Just so I'm sure I understand... if the script runs via a recurring policy it throws that error but if you run the policy manually it succeeds?

[rastogisagar123]

Awesome one @ThomM  as always!!!!!