Version: 0.1 (Draft) Status: Specification Phase

This document defines the security model for VAM — VSAD Arch Manager.

VAM is a system-management platform. Security is a first-class architectural concern.

VAM's security architecture is designed to reduce and control package risk. Absolute security claims are not made.

VAM must never reduce package installation to:

download random script
↓
sudo bash
↓
hope for the best

VAM uses two related but distinct security concepts:

Package trust concerns the authenticity and integrity of packages.

Runtime safety concerns how packages execute.

Metadata alone does not guarantee a package is safe.

VAM enforces trust through:

1. Capability declarations — package must declare what it needs
2. Capability validation — VAM checks declarations against policy
3. Runtime monitoring — execution is bounded by declared capabilities
4. Privilege brokering — elevated operations go through VAM

VAM uses path/network/privilege grants:

Capabilities are declared in the package manifest:

[[capabilities]]
type = "path"
access = "/var/log"
mode = "read"

[[capabilities]]
type = "network"
access = "outbound"
protocol = "https"

[[capabilities]]
type = "privilege"
access = "systemctl"
operations = ["restart", "status"]

Before package execution, VAM validates:

1. All declared capabilities are explicitly granted
2. No undeclared capabilities are requested
3. Capability scope matches declared scope
4. User has acknowledged capability requirements

During execution:

• Path capabilities — VAM restricts filesystem access to declared paths
• Network capabilities — VAM controls network access based on declarations
• Privilege capabilities — VAM brokers privileged operations through its API

1. VAM handles privilege escalation — the user interacts with VAM, not raw sudo
2. VAM provides a controlled privileged-operation API — packages request elevated operations through defined interfaces
3. VAM itself does not simply run as root — privilege is requested narrowly
4. Packages do not freely call sudo — they use VAM's privileged-operation API

Privileged operations are performed through direct syscalls through VAM broker.

Package
    ↓
request privileged operation
    ↓
VAM validates capability
    ↓
VAM checks user consent
    ↓
VAM performs operation
    ↓
return result to package

VAM should use narrowly scoped privileged operations.

Examples of privileged operations:

• systemctl service management
• filesystem writes to protected locations
• network configuration changes
• user/group management
• system configuration changes

Privileged operations require explicit user consent.

The consent model is an OPEN DECISION.

Package Signature
    ↓
Repository Signature
    ↓
Manifest Validation
    ↓
Integrity Checksums
    ↓
Capability Validation
    ↓
Dependency Verification

The package trust/signature cryptographic model is an OPEN DECISION.

1. Verify repository signature
2. Verify package signature
3. Validate manifest structure
4. Check integrity checksums
5. Validate capability declarations
6. Check dependency availability
7. Grant or deny installation

Users configure which repositories are trusted.

Trust configuration is an OPEN DECISION.

A local .vampkg is not automatically trusted merely because it is local.

Official repository trust and local package trust are distinct concepts.

VAM uses minimal isolation with capability checks.

The runtime provides:

• Environment control
• Declared path restrictions
• Capability validation
• Privilege boundary enforcement

Full sandboxing is not used. VAM relies on capability declarations and validation.

Packages receive only declared environment variables.

Undeclared environment variables are not passed to package code.

Packages can only access declared paths.

Undeclared path access is denied.

Package execution is monitored for:

• Undeclared capability usage
• Path access violations
• Privilege escalation attempts
• Unexpected behavior patterns

1. Verify repository trust
2. Verify package signature
3. Validate manifest
4. Check integrity
5. Validate capabilities
6. Check dependencies
7. Request user consent for capabilities
8. Extract to temporary location
9. Verify extracted contents
10. Move to final location
11. Register package

• Extract to isolated temporary directory
• Validate extracted contents before moving
• Prevent path traversal attacks
• Validate file permissions
• Check for unexpected files

1. Verify update authenticity
2. Validate update compatibility
3. Create rollback point
4. Install update
5. Verify update success
6. Register rollback

VAM should log:

• Package installations
• Package removals
• Privilege escalations
• Capability grants
• Security violations
• Configuration changes

The logging and audit model is an OPEN DECISION.

• Unauthorized package installation
• Privilege escalation without consent
• Path traversal attacks
• Command injection
• Undeclared capability usage
• Tampered packages
• Untrusted repositories

• Malicious packages with declared capabilities
• Social engineering attacks
• Compromised development environments
• Zero-day vulnerabilities in dependencies

VAM assumes:

• The VAM binary itself is trustworthy
• The user understands capability implications
• The system is not already compromised
• Repository infrastructure is secure

This security model interacts with:

• Architecture — how security is implemented in VAM Core
• Package Specification — capability declarations, manifest format
• Repository Specification — repository trust, signatures
• Configuration Specification — security configuration