SON security model #150

New issue

Closed

opened 2025-12-30 19:13:49 +00:00 by navicore · 2 comments

navicore commented

2025-12-30 19:13:49 +00:00

(Migrated from github.com)

Context

SON (Seq Object Notation) is executable Seq code. Loading a .son file means running arbitrary code:

include "config.son"
config call  # Executes whatever is in config.son

This is powerful but dangerous. Loading untrusted SON = arbitrary code execution.

The Problem

JSON is safe to parse from untrusted sources. SON is not. We need a security model before SON becomes widely used.

Options

Option A: Sandboxed Evaluation

Restrict which words are available during SON evaluation.

# Only allow: literals, map.*, list.*, wrap, call (on quotations)
# Forbid: io.*, tcp.*, strand.*, file-*, etc.

Implementation:

Compile SON with restricted word list
Runtime sandbox that traps forbidden calls

Pros: Untrusted SON becomes safe
Cons: Complex implementation, overhead

Option B: Static "Pure Data" Subset

Define a syntactic subset of Seq that can only represent data:

SON ::= literal | '[' SON* ']' | '[' SON* 'map' ']' | '[' SON* 'list' ']' | ...

Pros: Statically verifiable, zero runtime overhead
Cons: Needs separate parser/validator, less flexible

Option C: Trust Model (No Sandboxing)

Document that SON is code. Only load from trusted sources.

# WARNING: Only include SON from sources you trust!
include "https://example.com/config.son"  # Don't do this!

Pros: Zero implementation cost
Cons: Users will inevitably load untrusted SON

Option D: Capability-Based Security

SON evaluation receives explicit capabilities:

[ :io :fs ] son.load-with-caps "config.son"  # Allow I/O and filesystem
[ ] son.load-with-caps "untrusted.son"       # Pure data only

Pros: Fine-grained control
Cons: Complex, capability propagation is hard

Recommendation

Start with Option C (documentation) but design the SON loader API to support Option A (sandboxing) later:

# Phase 1: Trust model
: son.load ( path -- values ) include call ;

# Phase 2: Add sandboxed version
: son.load-safe ( path -- values )
  # Sandboxed evaluation
  ;

Relation to SON

This must be resolved before SON is promoted for general use. The API design now affects what's possible later.

Part of the SON implementation roadmap.

## Context SON (Seq Object Notation) is executable Seq code. Loading a `.son` file means running arbitrary code: ```seq include "config.son" config call # Executes whatever is in config.son ``` This is powerful but dangerous. Loading untrusted SON = arbitrary code execution. ## The Problem JSON is safe to parse from untrusted sources. SON is not. We need a security model before SON becomes widely used. ## Options ### Option A: Sandboxed Evaluation Restrict which words are available during SON evaluation. ```seq # Only allow: literals, map.*, list.*, wrap, call (on quotations) # Forbid: io.*, tcp.*, strand.*, file-*, etc. ``` Implementation: - Compile SON with restricted word list - Runtime sandbox that traps forbidden calls Pros: Untrusted SON becomes safe Cons: Complex implementation, overhead ### Option B: Static "Pure Data" Subset Define a syntactic subset of Seq that can only represent data: ``` SON ::= literal | '[' SON* ']' | '[' SON* 'map' ']' | '[' SON* 'list' ']' | ... ``` Pros: Statically verifiable, zero runtime overhead Cons: Needs separate parser/validator, less flexible ### Option C: Trust Model (No Sandboxing) Document that SON is code. Only load from trusted sources. ```seq # WARNING: Only include SON from sources you trust! include "https://example.com/config.son" # Don't do this! ``` Pros: Zero implementation cost Cons: Users will inevitably load untrusted SON ### Option D: Capability-Based Security SON evaluation receives explicit capabilities: ```seq [ :io :fs ] son.load-with-caps "config.son" # Allow I/O and filesystem [ ] son.load-with-caps "untrusted.son" # Pure data only ``` Pros: Fine-grained control Cons: Complex, capability propagation is hard ## Recommendation Start with **Option C** (documentation) but design the SON loader API to support **Option A** (sandboxing) later: ```seq # Phase 1: Trust model : son.load ( path -- values ) include call ; # Phase 2: Add sandboxed version : son.load-safe ( path -- values ) # Sandboxed evaluation ; ``` ## Relation to SON This must be resolved before SON is promoted for general use. The API design now affects what's possible later. --- Part of the SON implementation roadmap.

navicore commented

2025-12-30 19:20:29 +00:00

(Migrated from github.com)

be careful not to introduce 'seqbleed' :)

navicore commented

2026-01-04 04:05:14 +00:00

(Migrated from github.com)

https://github.com/navicore/patch-seq/pull/174