What You Run (LLM) Locally Is Your Business, But… Are You Sure Your LLM Model Isn’t Messing with Your System? ????
Lock down your local LLM model

What You Run (LLM) Locally Is Your Business, But… Are You Sure Your LLM Model Isn’t Messing with Your System? ????

More and more people are running LLM models (e.g., Ollama, LM Studio, Llama, Mistral, Open-WebUI) locally to avoid the cloud and maintain full control over their data. But do you really have control? Do you know what your model is doing beyond generating text?

Could it be scanning your network or snooping around your system? ??


??? Can a Model "Do Something" on Your System?

If you run it without isolation, it can (YEEEEESSSSS):

  • Read files that the process has access to
  • Download additional data from the internet (if the application allows it)
  • Scan open ports on your network
  • Execute system commands, if the hosting application permits it

That’s why it’s crucial to ensure security - especially if you’re working on a machine containing personal or corporate data!



LM Studio and Ollama

??? Best Practices for LM Studio and Ollama

?? LM Studio (see https://lmstudio.ai/docs/offline)

  • Disable internet access for models → Check settings to ensure models are not sending requests to APIs or external sources
  • Block access to system files – Run LM Studio in a dedicated user profile
  • Monitor network traffic (e.g., Lulu (by Patrick Wardle https://objective-see.org/products/lulu.html), Little Snitch, Wireshark or tcpdump) to check if the app communicates with suspicious addresses
  • Update only from official sources (LM Studio has an auto-update feature - always check the changelog!)

?? Ollama

  • Run Ollama in a sandbox, such as Firejail (Linux) or AppArmor
  • Block network access (ollama run model_name works locally, but ensure it doesn't fetch extra data)
  • Create a dedicated user account with no sudo privileges if you want to run models in the background
  • Verify the models you download – If you're pulling models from unknown sources (ollama pull), check their SHA256 hash to ensure they haven’t been tampered with
  • If you're using a GUI (chat interface) for your model, review its security before trusting it with sensitive information

?? Selected CVEs:

  1. CVE-2024-50050 - Remote Code Execution (CWE-502)
  2. CVE-2024-39720 - Out-of-bounds Read leading to Denial of Service (CWE-125) Enables attackers to crash the application through the CreateModel route, leading to a segmentation fault.
  3. CVE-2024-39722 - File existence disclosure (CWE-22) Exposes the files that exist on the server on which Ollama is deployed, via path traversal in the API/push route.?
  4. CVE-2024-39719 - File existence disclosure (CWE-497) Provides a primitive for file existence on the server, making it easier for threat actors to further abuse the application.?
  5. CVE-2024-39721 - Infinite Loops and Denial of Service (CWE-400) Allows denial-of-service (DoS) attacks through the CreateModel API route via a single HTTP request.?
  6. CVE-2024-23496 - Integer Overflow or Wraparound (CWE-190)
  7. CVE-2024-21802 - Heap-based Buffer Overflow (CWE-122)
  8. CVE-2024-21836 - Heap-based Buffer overflow (CWE-190)




Docker

??? How to Secure Your Locally Running Model?

?? Isolation in Docker

  • Block internet access: --network none or a custom bridge network without a gateway
  • Restrict privileges: --security-opt no-new-privileges
  • Remove unnecessary capabilities: --cap-drop ALL

docker network create \
  --driver=bridge \
  --subnet=192.168.1.0/24 \
  isolated_net

docker run -d \
  --network=isolated_net \
  --ip=192.168.1.100 \
  -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  --dns 192.168.1.1 \  
  --dns-search local \
  --security-opt no-new-privileges \
  --cap-drop NET_RAW \
  --cap-drop NET_ADMIN \
  ghcr.io/open-webui/open-webui:main        
?? Option: Docker Seccomp/AppArmor

  • Seccomp Profile: Restricts the ability to execute certain system calls.

docker run --security-opt seccomp=unconfined ghcr.io/open-webui/open-webui:main        

  • AppArmor Profile: You can configure custom policies for the container, blocking unwanted operations.

docker run --security-opt apparmor=unconfined ghcr.io/open-webui/open-webui:main        

  • Completely drop unnecessary capabilities:

docker run --cap-drop ALL --security-opt no-new-privileges ghcr.io/open-webui/open-webui:main        

  • Block access to /bin/sh (forces the model to run in an environment without a system shell):

docker run --read-only --tmpfs /tmp ghcr.io/open-webui/open-webui:main        
?? Blocking System Calls in Python Option: Monkey Patching (Disabling os.system)

Before launching the model, you can disable key functions:

import os
import subprocess

os.system = None
subprocess.call = None
subprocess.run = None
subprocess.Popen = None        

This prevents executing system commands from Python.



Linux

?? Running in a Sandbox

  • Firejail (Linux) – process isolation
  • AppArmor/Seccomp – restrict access to system resources
  • or other ...

?? Using SELinux (Linux)

If you are on a system that supports SELinux, you can set a policy that blocks access to /bin/sh, /usr/bin/python, etc.

sudo semanage fcontext -a -t sandbox_model_t "/path/to/model(/.*)?"
sudo restorecon -Rv /path/to/model        
?? Limiting User Privileges

The simplest method: Run the model on a dedicated user account without sudo privileges.

sudo useradd -m -d /home/llm_user -s /usr/sbin/nologin llm_user
sudo chown -R llm_user:llm_user /path/to/model
sudo -u llm_user python3 run_model.py        

This ensures the model cannot execute commands requiring admin privileges.


?? Monitoring Model Activity

  • Check open network connections: lsof -i -P -n
  • Analyze network traffic with tools like tcpdump
  • Monitor system resource usage (htop, iotop, strace)
  • and more... or other ...

?? Monitoring Network Traffic and System Logs

If you suspect that the model might be trying to execute commands, check:

strace -p $(pgrep -f model)  # Tracing system calls
sudo auditctl -w /bin/sh -p x  # Monitoring attempts to launch the shell        

Conclusion


LLM

?? "Trust, but verify."

What you run locally is your business (thing) - but if you don’t implement isolation, you might unknowingly give your model access to your network and files. LM Studio and Ollama are great tools, but you should still monitor their behavior and limit their access to your system and the internet.

How do you secure your local LLM instances? Do you have your own best practices? Let us know in the comments! ????


Source:

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/security_hardening/index?utm_source=AlamaKota

https://ubuntu.com/security/certifications/docs/usg

https://docs.docker.com/engine/security/

https://docs.docker.com/security/for-admins/hardened-desktop/enhanced-container-isolation

https://genai.owasp.org/resource/genai-red-teaming-guide/ OWASP Top 10 For Large Language Model Applications & Generative AI OWASP? Foundation



Deya Eldeen Elkhawaldeh

iOS Engineer SDE III @ Expedia Group

1 个月

Nice, is it useful to also include podman, and not only docker? You know, daemon-less arch, rootless containers, etc...

回复
Krzysztof Pranczk

Senior Security Engineer @ Application Security, DevSecOps

1 个月

Really cool article Sebastian Obara. As you have the deployment's best practices covered, it deserves a continuation in terms of preventing LLM attacks in such setup.

要查看或添加评论,请登录

Sebastian Obara的更多文章

社区洞察

其他会员也浏览了