Understanding BlueRock Sandbox Policies

The BlueRock Sandbox operates based on a structured JSON policy file. This configuration file acts as the central source of truth for the sandbox environment, dictating exactly what applications can execute, how file systems are mounted, what privileges are granted, and how network traffic is routed.

The policy template file resides at /opt/bluerock/trex with filename bru_policy.json.template. Rename or copy it with filename bru_policy.json and make the relevant changes.

Policy Structure Overview

A standard sandbox policy is divided into three primary blocks:

1. options: Defines runtime environments, user privileges, and namespace isolation.

2. network: Governs internal routing and firewall configurations.

Below is a reference template of a foundational policy configuration:

bru_policy.json

"brace": {
                "options": {
                    "bind_mount": {
                        "mount_proc": true,
                        "mounts": []
                    },
                    "pid_ns": true,
                    "user_ns": false
                },
                "network": {
                    "enable": false,
                    "general": {
                        "bridge": "bru0",
                        "gateway": "10.0.0.1"
                    },
                    "firewall": null
                },
}

Runtime Options (options)

The options block manages system-level isolation, file system access, and user privileges.

Parameter	Type	Description
bind_mount.mount_proc	Boolean	Procfs Mount Control: Automatically mounts a separate, isolated /proc filesystem inside the sandbox container for process status tracing. (Defaults to true).
bind_mount.mounts	Array	Host Volume Mappings: An array defining directories or files mapped from the host filesystem into the sandbox. (Empty [] in this profile).
pid_ns	Boolean	PID Namespace Isolation: Restricts process visibility. When enabled, processes running inside the sandbox cannot see or interact with processes on the host system. (Defaults to true).
user_ns	Boolean	User Namespace Mapping: Determines if root operations are mapped to an unprivileged host user. (Defaults to false).

Network Configuration (network)

The network block defines how the sandbox interacts with internal and external networks.

Parameter	Type	Description
enable	Boolean	Network Sandbox Enforcement: When disabled, the network namespace isolation layer is bypassed, blocking or overriding dynamic interface generation for the instance. (Defaults to false).
general.bridge	String	Virtual Bridge Interface: The designated virtual network bridge identifier used for container network binding when networking is active. (Defaults to "bru0").
general.gateway	String	Default Gateway: The IPv4 target destination routing address for network packets escaping the sandbox interface. (Defaults to "10.0.0.1").
firewall	Null / Object	Firewall Access Control List: Granular firewall filters, iptables, or routing rules applied to this specific profile. (Defaults to null).

Policy-Driven Configuration Examples

Centralizing security logic within the policy file reduces manual input errors and ensures consistent enforcement across environments.

Running Python MCP Server and MCP Client

To run Python MCP Server and MCP Client in BlueRock Sandbox, an MCP setup is required:

1. Install uv :

$ curl -LsSf https://astral.sh/uv/install.sh | sh

2. Create Project Directory Create a new project directory for the MCP applications and navigate into it:

$ cd ~
$ uv init mcp-observability
$ cd mcp-observability

3. Install Required Dependencies Create an isolated Python environment using uv, then install the MCP framework, BlueRock sensor, and BlueRock runtime required for generating and exporting telemetry:

# Create virtual environment
$ uv venv --python python3.12

# Activate virtual environment
$ source .venv/bin/activate

# Install MCP framework
$ uv pip install fastmcp

# Install BlueRock runtime
$ uv pip install /opt/bluerock/python-dist/bluerock-0.0.1-py3-none-any.whl

# Initialize BlueRock sensor
$ python -m bluerock --install

4. Add MCP Application Files Create the MCP client and server scripts in the project directory using the sample code provided in the Appendix section. Ensure the following files are present in the mcp-observability directory:

• mcp_client.py

• mcp_fileserver.py

• mcp_fileserver_stdio.py

Defining Mounts to run the MCP Server and Client

Defining mount points directly within the bru_policy.json file under the options.bind_mount block eliminates the requirement for extensive -v arguments in the Command Line Interface (CLI).

bru_policy.json

{
  "brace": {
    "options": {
      "bind_mount": {
        "enable": true,
        "mounts": [
          {"host": "/usr", "sandbox": "/usr", "read_only": true},
          {"host": "/lib", "sandbox": "/lib", "read_only": true},
          {"host": "/lib64", "sandbox": "/lib64", "read_only": true},
          {"host": "/etc/resolv.conf", "sandbox": "/etc/resolv.conf", "read_only": true},
          {"host": "/dev", "sandbox": "/dev", "read_only": false},
          {"host": "/home/ubuntu", "sandbox": "/home/ubuntu", "read_only": false}
        ]
      }
    }
  }
}

Important:

Modifications to bru_policy.json require a complete policy update to take effect. This process involves extracting the tarball, generating a new signature via trex.py, and uploading the repackaged files. Refer to the BlueRock Policy Builder for detailed instructions.

With file mounts pre-configured in the policy, the system allows for the direct execution of the MCP client or server without additional volume flags.

Terminal 1:

Starting the MCP Server Launch the sandbox and execute the Python server script:

$ brace --name mcp_server -- /home/ubuntu/.local/bin/uv run mcp_fileserver.py

Expected Output:

╭──────────────────────────────────────────────────────────────────────────────╮
│                                                                              │
│                                                                              │
│                         ▄▀▀ ▄▀█ █▀▀ ▀█▀ █▀▄▀█ █▀▀ █▀█                        │
│                         █▀  █▀█ ▄▄█  █  █ ▀ █ █▄▄ █▀▀                        │
│                                                                              │
│                                                                              │
│                                FastMCP 3.1.0                                 │
│                            https://gofastmcp.com                             │
│                                                                              │
│                   🖥  Server:      Linux File Server, 3.1.0                   │
│                   🚀 Deploy free: https://fastmcp.cloud                      │
│                                                                              │
╰──────────────────────────────────────────────────────────────────────────────╯
[03/12/26 04:42:11] INFO     Starting MCP server 'Linux File    transport.py:273
                             Server' with transport 'http' on                   
                             http://0.0.0.0:8001/mcp                            
INFO:     Started server process [9]
INFO:     Waiting for application startup.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:8001 (Press CTRL+C to quit)

Terminal 2:

Starting the MCP Client. Open a separate terminal and launch a second sandbox to execute the client script:

$ brace --name mcp_client -- /home/ubuntu/.local/bin/uv run mcp_client.py --mcp_server http://0.0.0.0:8001/mcp --mcp_auth_token dev-test-token tools --list

Network Firewall Configuration

Network profile defines how a program running inside the sandbox connects to external network services.

Only one network firewall can be configured for the Sandbox policy.

• Egress (Outbound): Allows programs in the sandbox to reach external network services.

  Parameters - IP, port, protocol

  For example: An agent program running inside the sandbox is restricted to access a specific LLM provider.

• Ingress (Inbound): Allows inbound connections from a specific host to the server program running inside the sandbox on a specific port and protocol

  For example: Allows an MCP client program from a specific source address to connect to the MCP server program running on a specific port

bru_policy.json

"network": {
                "enable": true,
                "general": {
                        "bridge": "bru0",
                        "gateway": "10.0.0.1"
                    },
                    "firewall": {"options": {"allow_icmp": true, "log_drops": true},
                                 "ingress": {"published_ports": [{"container_port":8001, "host_bindings": [{"host_ip": "0.0.0.0", "host_port": 8001}]}]},
                                 "egress": {"allow_to": [{"addr": "8.8.8.8", "ports": [], "proto": ["tcp", "udp"]},
                                                         {"addr": "api.openai.com", "ports": [], "proto": ["tcp", "udp"]},
                                                         {"addr": "api.<domain>.com", "ports": [], "proto": ["tcp", "udp"]}]}}
}

Parameter	Type	Description
network.enable	Boolean	Master toggle to enable (true) or disable (false) the network configuration.
network.general.bridge	String	The name of the virtual bridge interface designated for this network (e.g., bru0).
network.general.gateway	String	The IPv4 address assigned as the network gateway (e.g., 10.0.0.1).
network.firewall.options.allow_icmp	Boolean	Determines whether ICMP traffic (such as ping requests) is permitted through the firewall.
network.firewall.options.log_drops	Boolean	When enabled, logs all network packets that are dropped by the firewall rules.
network.firewall.ingress.published_ports	Array of Objects	A list of port mapping definitions for inbound traffic to the container.
...published_ports[].container_port	Integer	The specific port number inside the container that will receive the routed traffic.
...published_ports[].host_bindings	Array of Objects	Specifies how the internal container_port maps to the host's external network interfaces.
...host_bindings[].host_ip	String	The host IP address to bind the port to. Use 0.0.0.0 to bind to all available IPv4 interfaces.
...host_bindings[].host_port	Integer	The external port number exposed on the host machine.
network.firewall.egress.allow_to	Array of Objects	A list of strict outbound rules defining permitted external destinations for container traffic.
...allow_to[].addr	String	The destination IPv4 address (e.g., 8.8.8.8) or Fully Qualified Domain Name (FQDN) (e.g., api.openai.com) permitted for egress.
...allow_to[].ports	Array of Integers	An array of specific destination ports allowed for the defined address. An empty array typically implies no port restrictions for the specified protocols.
...allow_to[].proto	Array of Strings	The network protocols permitted for this egress rule (e.g., ["tcp", "udp"]).

Important:

Modifications to bru_policy.json require a complete policy update to take effect. This process involves extracting the tarball, generating a new signature using trex.py, and uploading the repackaged files. Refer to the BlueRock Policy Builder for detailed instructions.

Seccomp Interception Rules & Monitor Constraints

When syscalls.enable = true is set in your configuration profile, the engine actively injects custom seccomp filters into the container sandbox initialization routine using SCMP_ACT_NOTIFY vectors. The parent engine runs an isolated asynchronous loop that monitors matching system hooks, intercepts process namespaces, reads the context block, and emits the structured telemetry.

Policy Reference Configurations

Use these minimal structures to enforce active tracking for audited domains:

Suspicious Syscalls Tracker (suspicious_syscalls) Intercepts unauthorized privilege escalation or host namespace jailbreak vectors.

"suspicious_syscalls": {
  "enable": true,
  "remediate": false,
  "allow_unshare": false,
  "allow_ptrace": false
}

Parameter	Type	Description
suspicious_syscalls.enable	Boolean	Master toggle to enable (true) or disable (false) the monitoring and evaluation of suspicious system calls.
suspicious_syscalls.remediate	Boolean	Determines whether the system should take automatic enforcement action (such as blocking or terminating the process) when a suspicious syscall is detected.
suspicious_syscalls.allow_unshare	Boolean	Controls whether the unshare system call is permitted. When disabled, it prevents processes from detaching namespaces (often restricted for security isolation).
suspicious_syscalls.allow_ptrace	Boolean	Controls whether the ptrace system call is permitted. When disabled, it prevents unauthorized process tracing, debugging, or memory inspection.

Process Execution (execve or execveat)

Generates telemetry indicators whenever execve or execveat are handled inside the container.

"exec": {
  "enable": true,
  "track_clone": false
}

Parameter	Type	Description
exec.enable	Boolean	Master toggle to enable (true) or disable (false) execution monitoring and related policies.
exec.track_clone	Boolean	Controls whether the system tracks process creation events (such as clone or fork system calls) as part of the execution policy.

Filesystem Interface Tracker (allow_read_only)

Tracks namespace interactions. Toggling "allow_read_only": true reduces metric noise by omitting read operations.

"open": {
  "enable": true,
  "remediate": false,
  "allow_read_only": true
}

Parameter	Type	Description
open.enable	Boolean	Master toggle to enable (true) or disable (false) monitoring and policy evaluation for file open operations.
open.remediate	Boolean	Determines whether the system should take automatic enforcement action (such as blocking the operation) when an unauthorized file open request is detected.
open.allow_read_only	Boolean	Controls whether read-only file access is permitted by default. When enabled, it allows processes to open files strictly for reading, even if broader access restrictions are in place.

Staging Memory Execution Tracker (mmap_exec) Tracks fileless execution strategies and dynamic memory allocations inside the container sandbox space.

"mmap_exec": {
  "enable": true,
  "remediate": false
}

Parameter	Type	Description
mmap_exec.enable	Boolean	Master toggle to enable (true) or disable (false) the monitoring and policy evaluation of memory regions mapped with execution permissions (e.g., PROT_EXEC).
mmap_exec.remediate	Boolean	Determines whether the system should take automatic enforcement action (such as blocking the mapping request) when an unauthorized executable memory mapping is detected.

1. Operational Impact: Generates a brace_mmap_exec telemetry signature whenever a process requests an mmap allocation flagged with PROT_EXEC modifications, or attempts to execve target an anonymous memory descriptor (/memfd:).

2. Enforcement Behavior: Structural prevention blocks are unique to high-risk traps. If a fileless execution mechanism violates the staging policy, remediation flags can be enabled to block the memory allocation lifecycle.

Network Socket Tracking Interface (socket) Captures raw endpoint instantiation handles at the container namespace boundary.

"socket": {
  "enable": true,
  "remediate": false
}

Parameter	Type	Description
socket.enable	Boolean	Master toggle to enable (true) or disable (false) monitoring and policy evaluation for network socket creation and operations.
socket.remediate	Boolean	Determines whether the system should take automatic enforcement action (such as blocking the operation) when an unauthorized socket request is detected.

1. Operational Impact: Dispatches a brace_socket data block immediately when the socket() system call is processed inside the sandbox.

2. Observe-Only Baseline: This hook functions in an observe-only validation scope. The configuration captures the underlying protocol arrays (such as AF_INET or SOCK_STREAM) for audit baselines without introducing runtime structural latency.

Network Connection Tracker (connect) Monitors bi-directional outbound connectivity and tracking state handshakes.

"connect": {
  "enable": true,
  "remediate": false
}

Parameter	Type	Description
connect.enable	Boolean	Master toggle to enable (true) or disable (false) monitoring and policy evaluation for outbound network connection attempts (e.g., the connect system call).
connect.remediate	Boolean	Determines whether the system should take automatic enforcement action (such as blocking the connection attempt) when an unauthorized network connection is detected.

1. Operational Impact: Evaluates the container's raw process memory directly on a connect() execution request. The interface translates destination headers into human-readable IP or Unix socket address strings (such as 1.2.3.4:port or unix:/path/to/sock) inside the brace_connect log output.

2. Observe-Only Baseline: Operates under an observe-only posture. This hook does not drop traffic directly; enforcement is entirely delegated to host-level egress network firewall rules to minimize path friction.

Filesystem Deletion Tracker (delete) Maintains an accurate audit trail of structural file and directory purging actions.

"delete": {
  "enable": true
}

Parameter	Type	Description
delete.enable	Boolean	Master toggle to enable (true) or disable (false) monitoring and policy evaluation for file or resource deletion operations (e.g., unlink or rmdir system calls).

1. Operational Impact: Triggers a brace_delete tracking log upon any valid call to unlink, unlinkat, or rmdir system commands.

2. Metadata Structure: Emits absolute resolved paths along with a boolean is_dir flag to distinguish regular file drops from full directory removals within the security metrics stream. This trap is always permitted through for observation.

Sensitive File Access (sensitive_file_access)

Monitors real-time interactions with critical system configurations, credential storage locations, and environmental identity blocks.

"sensitive_file_access": {
  "enable": true,
  "remediate": false,
  "paths": [
    { "path": "/etc/shadow", "write_only": false },
    { "path": "/etc/sudoers", "write_only": false },
    { "path": "/etc/passwd", "write_only": true }
  ],
  "exceptions": [
    { "program": "/usr/sbin/sshd", "file": "**/*" }
  ]
}

Parameter	Type	Description
sensitive_file_access.enable	Boolean	Master toggle to enable (true) or disable (false) monitoring and policy evaluation for interactions with designated sensitive files.
sensitive_file_access.remediate	Boolean	Determines whether the system should take automatic enforcement action (such as blocking the access attempt) when an unauthorized interaction with a sensitive file is detected.
sensitive_file_access.paths	Array of Objects	A list of specific file paths designated as sensitive, along with their access evaluation criteria.
...paths[].path	String	The absolute directory or file path to be monitored (e.g., /etc/shadow).
...paths[].write_only	Boolean	Controls the scope of monitoring for the specific path. When true, alerts or remediation only trigger upon modification (write) attempts. When false, any access (read or write) triggers the policy.
sensitive_file_access.exceptions	Array of Objects	A list of rules defining trusted processes permitted to bypass the sensitive file access restrictions.
...exceptions[].program	String	The absolute path to the executable program authorized for the exception (e.g., /usr/sbin/sshd).
...exceptions[].file	String	The specific file path or glob pattern (e.g., **/*) that the authorized program is permitted to access without triggering a violation.

1. Operational Impact: Evaluates standard file open requests against a predefined file-path array to detect unauthorized access to system configurations, tracking operations through the sensitive_file_access_violation observability signature.

2. Granular Read/Write Mechanics: Adjusts alert tracking structures by matching paths with a declarative boolean flag. Setting write_only: false enables bi-directional audit logging to catch both read actions (such as a cat command) and write modifications on target paths. Setting write_only: true suppresses read notifications to isolate alerts strictly to modification attempts on asset stores (such as user group files or network resolution configurations).

3. Automated Exceptions Mapping: Processes fine-grained exemptions to eliminate false positive noise from validated system utilities. Whitelisted operations (such as authentication lookups from the sshd daemon or privilege changes via sudo) bypass violation filters, matching entries without dispatching security logging events.

Process Guard (process_guard)

Manages binary execution parameters inside the container space to prevent post-exploit tool execution and remote script injections.

"process_guard": {
  "enable": true,
  "remediate": false,
  "allow": [
    "/bin/**",
    "/usr/bin/**"
  ],
  "deny": [
    "**/nc",
    "**/wget",
    "**/curl"
  ],
  "deny_exceptions": [
    { "path_pattern": "**/bin/bash", "comm_list": ["setup-policy-ro"] }
  ]
}

Parameter	Type	Description
process_guard.enable	Boolean	Master toggle to enable (true) or disable (false) monitoring and policy evaluation for process execution based on allow/deny lists.
process_guard.remediate	Boolean	Determines whether the system should take automatic enforcement action (such as blocking the process creation) when an unauthorized process execution is detected.
process_guard.allow	Array of Strings	A list of explicit file paths or glob patterns (e.g., /bin/**) designating executables that are permitted to run.
process_guard.deny	Array of Strings	A list of explicit file paths or glob patterns (e.g., **/wget) designating executables that are strictly prohibited from running.
process_guard.deny_exceptions	Array of Objects	A list of granular rules defining specific exceptions to the broader deny list.
...deny_exceptions[].path_pattern	String	The path or glob pattern of the executable (e.g., **/bin/bash) that is granted an exception under specific conditions.
...deny_exceptions[].comm_list	Array of Strings	A list of permitted command names (typically mapped to the Linux comm value) that are authorized to execute the file matched by the path_pattern, bypassing the deny rule.

1. Operational Impact: Validates process execution calls (execve, execveat) against declarative directories, triggering an automated process_guard_violation event whenever a disallowed binary or unlisted path structure matches active block restrictions.

2. Intrusion Isolation Blocklists: Enforces a persistent deny matrix to target binaries frequently abused during payload deployment stages. Execution attempts matching ingestion or scripting tools (such as curl, wget, or Netcat) are systematically blocked and reported to telemetry pools.

3. Contextual Deny Overrides: Evaluates targeted exceptions based on explicit execution contexts to permit safe administration actions. Regulated binaries (such as a standard bash shell) are permitted to run only if the execution sequence maps directly to a trusted system initialization wrapper (such as setup-policy-ro).