Python Security Boundaries in FreeCAD

This article provides an overview of the security model surrounding Python execution within FreeCAD. It explores the inherent lack of sandboxing in FreeCAD's embedded interpreter, details how Python scripts interact directly with the host operating system, examines potential attack vectors like macros and external workbenches, and outlines essential precautions for safely running untrusted code.

The Absence of Native Sandboxing

FreeCAD does not implement a sandbox or security boundary for its embedded Python environment. When Python code runs inside FreeCAD—whether through the interactive console, a macro, or an installed workbench—it runs directly via standard CPython within the FreeCAD process.

Because there is no isolation layer, the interpreter has unrestricted access to the standard Python library. Modules such as os, sys, subprocess, socket, and shutil operate with full functionality. Consequently, a Python script executed within FreeCAD can perform any action that a standalone Python script could perform on your system.

Inherited Operating System Privileges

Python execution boundaries in FreeCAD are defined entirely by the operating system user account running the application. The embedded Python interpreter inherits the full system permissions of the active FreeCAD process:

  • File System Access: Scripts can read, modify, and delete any file accessible to the user, not just FreeCAD design files.
  • Network Operations: Python code can open sockets, make HTTP requests, download external payloads, or exfiltrate local data to remote servers.
  • Process Execution: Scripts can spawn shell processes, launch external binaries, and execute arbitrary commands on the host machine.
  • Memory and State: Code can interact with other FreeCAD internal C++ objects via the App and Gui modules, potentially altering memory or crashing the application.

If FreeCAD is run with elevated privileges (such as root on Linux or Administrator on Windows), any Python code executed within it gains those same administrative privileges.

Primary Attack Vectors

Understanding how Python code enters FreeCAD highlights where vulnerabilities typically arise:

  1. Macros (.FCMacro files): Users often download community macros to automate complex modeling tasks. Macros are plain Python scripts. Running a macro from an unknown or unverified source is equivalent to executing an unknown binary on your computer.
  2. Addons and Workbenches: Community workbenches installed via the FreeCAD Addon Manager are distributed as Git repositories containing Python source code. FreeCAD automatically loads these extensions upon startup or activation, executing initialization code directly.
  3. Parametric Objects and Scripted Features: FreeCAD projects (.FCStd) can include scripted Python features that define geometry dynamically. While FreeCAD generally restricts automatic execution of embedded scripts when loading third-party files, running features dependent on custom code can trigger execution paths.

Enforcing External Security Boundaries

Because FreeCAD does not isolate Python internally, security boundaries must be enforced externally at the operating system or environment level:

  • Least Privilege: Always run FreeCAD under a standard user account with minimal permissions. Never run FreeCAD as root or administrator.
  • Code Review: Inspect .FCMacro files in a text editor before executing them. Look for unauthorized network calls, system commands, or file system modifications.
  • Containerization and Sandboxing: Run FreeCAD inside a container (such as Docker or Podman with X11 forwarding) or use containerized application formats like Flatpak. On Linux, tools like Firejail can restrict FreeCAD’s network access and limit its visibility to specific directories.
  • Virtual Machines: When evaluating untrusted workbenches, macros, or experimental scripts, run FreeCAD inside an isolated virtual machine to prevent potential persistence or lateral movement across your primary system.