- Add SecurityMiddleware class with YAML-based configuration support - Implement three-tier configuration hierarchy (Enterprise → Global → Project → Custom) - Add ASK action support for prompting users instead of just blocking - Create EnhancedRooIgnoreController that integrates with SecurityMiddleware - Support both gitignore-style and regex patterns for file matching - Add comprehensive type definitions for security configuration - Include example YAML configurations for different use cases - Add documentation for the new security middleware features - Implement tests for core functionality Fixes #7912
9.8 KiB
RooCode Security Middleware
Overview
The RooCode Security Middleware provides enhanced, granular file access control beyond the traditional .rooignore functionality. It introduces a flexible YAML-based configuration system with support for ASK actions (prompting users for approval), regex patterns, and a three-tier configuration hierarchy.
Key Features
1. ASK Action Support
Instead of just blocking file access, the middleware can prompt users for approval before allowing access to sensitive files.
2. YAML Configuration
More flexible and readable configuration format compared to gitignore-style patterns.
3. Three-Tier Configuration Hierarchy
- Enterprise: Organization-wide policies (cannot be overridden)
- Global: User-level defaults (~/.roo-security.yaml)
- Project: Project-specific rules (.roo-security.yaml)
- Custom: Personal overrides (.roo-security-custom.yaml)
4. Regex Pattern Support
In addition to gitignore-style patterns, supports regular expressions for complex matching.
5. Rule Priority System
Fine-grained control over which rules take precedence when multiple patterns match.
Configuration File Format
Basic Structure
version: "1.0"
security:
enabled: true
inheritRules: true # Whether to inherit rules from higher levels
defaultAction: ALLOW # Default when no rules match (ALLOW, BLOCK, or ASK)
askMessagePrefix: "Security check" # Prefix for ASK prompts
rules:
- pattern: "**/.env*" # Gitignore-style pattern
action: ASK # ALLOW, BLOCK, or ASK
priority: 90 # Higher numbers = higher priority
description: "Environment files may contain secrets"
askMessage: "Access to ${file} requires approval" # Custom prompt
applyToCommands: true # Also check terminal commands
Pattern Types
-
Gitignore-style patterns:
*.log- Match all log files**/.env*- Match .env files in any directorysrc/**/*.test.js- Match test files in src
-
Regular expressions (enclosed in forward slashes):
/.*\.secret\..*/- Match files with .secret. in the name/.*[Ss][Ss][Nn].*\d{3}-\d{2}-\d{4}.*/- Match potential SSN patterns
Configuration Hierarchy
1. Enterprise Configuration
- Managed by organization administrators
- Cannot be overridden by lower levels
- Typically enforces compliance requirements (GDPR, HIPAA, PCI-DSS)
2. Global Configuration
- Located at
~/.roo-security.yaml - User's personal default security settings
- Applies to all projects unless overridden
3. Project Configuration
- Located at
project-root/.roo-security.yaml - Project-specific security rules
- Can inherit or override global rules
4. Custom Configuration
- Located at
project-root/.roo-security-custom.yaml - Personal overrides for the current project
- Highest priority (except for enterprise rules with
inheritRules: false)
Rule Evaluation Order
- Rules are evaluated from Custom → Project → Global → Enterprise
- Within each level, rules are sorted by priority (highest first)
- First matching rule determines the action
- If no rules match, the
defaultActionis applied
Actions
BLOCK
Completely prevents access to the file. The operation fails with an error message.
- pattern: "**/.ssh/**"
action: BLOCK
description: "SSH keys must not be accessed"
ASK
Prompts the user for approval before allowing access. If approved, access is granted; if denied, access is blocked.
- pattern: "**/*.key"
action: ASK
askMessage: "File ${file} appears to be a private key. Allow access?"
ALLOW
Explicitly allows access to the file. Useful for overriding inherited rules.
- pattern: "test/fixtures/**"
action: ALLOW
description: "Test fixtures are safe to access"
Integration with .rooignore
The Enhanced Security Middleware maintains full backward compatibility with .rooignore:
.rooignorepatterns are always evaluated first- Files blocked by
.rooignorecannot be allowed by security rules - Security middleware adds additional layers of protection
Usage Examples
Example 1: Protecting Sensitive Files
# .roo-security.yaml
version: "1.0"
security:
enabled: true
rules:
- pattern: "**/production.yml"
action: BLOCK
priority: 100
description: "Production configuration"
- pattern: "**/*.pem"
action: ASK
priority: 90
askMessage: "Certificate file ${file} - approve access?"
Example 2: Development Overrides
# .roo-security-custom.yaml
version: "1.0"
security:
enabled: true
inheritRules: true
rules:
# Override project rule for local development
- pattern: ".env.local"
action: ALLOW
priority: 200
description: "Local development environment"
Example 3: Enterprise Compliance
# Enterprise configuration (managed centrally)
version: '1.0'
security:
enabled: true
inheritRules: false # Cannot be overridden
rules:
- pattern: "**/pii/**"
action: BLOCK
priority: 1000
description: "GDPR compliance - PII protection"
- pattern: "/.*credit.*card.*\d{4}.*/"
action: BLOCK
priority: 1000
description: "PCI-DSS compliance"
Command-Line Access Control
The middleware also validates terminal commands that attempt to read files:
rules:
- pattern: "**/.env*"
action: BLOCK
applyToCommands: true # Also blocks: cat .env, type .env, etc.
Supported commands:
- Unix:
cat,less,more,head,tail,grep,awk,sed - PowerShell:
Get-Content,gc,type,Select-String,sls
API Usage
TypeScript Integration
import { EnhancedRooIgnoreController } from "./core/ignore/EnhancedRooIgnoreController"
import { SecurityEvaluation } from "./core/security/types"
// Initialize with security middleware
const controller = new EnhancedRooIgnoreController(projectPath, {
enableSecurityMiddleware: true,
askHandler: async (evaluation: SecurityEvaluation) => {
// Show prompt to user
const approved = await vscode.window.showWarningMessage(evaluation.message, "Allow", "Deny")
return approved === "Allow"
},
securityOptions: {
debug: true,
globalConfigPath: "~/.roo-security.yaml",
},
})
// Initialize (loads configurations)
await controller.initialize()
// Check file access (async for proper ASK handling)
const result = await controller.validateAccessAsync("config/secrets.yml")
if (!result.allowed) {
if (result.requiresApproval) {
console.log("File requires approval:", result.evaluation?.message)
} else {
console.log("File access blocked:", result.evaluation?.message)
}
}
// Check command execution
const cmdResult = await controller.validateCommandAsync("cat .env")
if (!cmdResult.allowed) {
console.log("Command blocked:", cmdResult.evaluation?.message)
}
Statistics and Monitoring
// Get security statistics
const stats = controller.getSecurityStats()
console.log(`Total evaluations: ${stats.totalEvaluations}`)
console.log(`Blocked: ${stats.blockedCount}`)
console.log(`Asked: ${stats.askedCount}`)
console.log(`Allowed: ${stats.allowedCount}`)
// Export configuration
const yamlConfig = await controller.exportSecurityConfig("project")
console.log("Current project config:", yamlConfig)
// Import new configuration
await controller.importSecurityConfig(newYamlContent, "custom")
Best Practices
1. Start with Defaults
Begin with sensible defaults at the global level, then add project-specific rules as needed.
2. Use Priority Wisely
- 1000: Critical security rules (enterprise/compliance)
- 100-999: Important project rules
- 50-99: Standard rules
- 1-49: Low-priority suggestions
3. Provide Clear Messages
Always include descriptive askMessage and description fields to help users understand why access is being controlled.
4. Test Your Rules
Use the custom configuration file to test new rules before adding them to project or global configs.
5. Regular Expressions
Use regex patterns sparingly and test thoroughly. They're powerful but can have performance implications.
6. Command Protection
Enable applyToCommands: true for truly sensitive files to prevent command-line access.
Migration from .rooignore
The security middleware is fully backward compatible. To migrate:
- Keep your
.rooignorefile as-is - Create
.roo-security.yamlfor new rules - Gradually move patterns from
.rooignoreto YAML configs - Use ASK action for files that need conditional access
Troubleshooting
Rules Not Being Applied
- Check that
enabled: trueis set - Verify file paths are relative to project root
- Check rule priority - higher priority rules match first
- Enable debug mode to see evaluation details
ASK Prompts Not Showing
- Ensure
askHandleris configured in the controller - Check that the UI component is properly connected
- Verify the pattern matches the file path
Performance Issues
- Avoid overly complex regex patterns
- Limit the number of rules per configuration level
- Use gitignore-style patterns when possible
Security Considerations
- Enterprise rules should be immutable and audited
- Sensitive patterns should use BLOCK, not ASK
- Regular expressions should be carefully reviewed for ReDoS vulnerabilities
- Custom configurations should be excluded from version control if they contain sensitive patterns
Future Enhancements
- Cloud-based enterprise configuration management
- Audit logging for all security decisions
- Machine learning-based sensitive data detection
- Integration with secret scanning tools
- Role-based access control (RBAC)
- Time-based access rules
- Contextual rules based on git branch or environment