gitrepublic-web/docs/SECURITY.md

Security Analysis

Current Security Model

This is a multi-tenant system where multiple users (identified by Nostr pubkeys/npubs) share the same server instance with application-level isolation but no process or filesystem isolation.

Security Measures in Place

1. Path Validation

   • ✅ File paths are validated and sanitized
   • ✅ Path traversal attempts (..) are blocked
   • ✅ Absolute paths are rejected
   • ✅ Null bytes and control characters are blocked
   • ✅ Path length limits enforced (4096 chars)

2. Input Validation

   • ✅ npub format validation (must be valid bech32)
   • ✅ Repository name validation (alphanumeric, hyphens, underscores, dots only)
   • ✅ No path separators allowed in repo names

3. Access Control

   • ✅ Repository ownership verified via Nostr events
   • ✅ Private repos require NIP-98 authentication
   • ✅ Maintainer checks before allowing write operations
   • ✅ Ownership transfer chain validation

4. Path Construction

   • ✅ Uses path.join() which prevents path traversal
   • ✅ Repository path: join(repoRoot, npub, ${repoName}.git)
   • ✅ File paths within repos are validated separately

Security Concerns

⚠️ Critical: No Process Isolation

Issue: All repositories run in the same Node.js process. If an attacker compromises one repository or finds a code execution vulnerability, they could potentially:

• Access other users' repositories
• Read/write files outside the repo directory
• Access server configuration or secrets

Mitigation:

• Path validation prevents most traversal attacks
• Access control checks prevent unauthorized access
• But a process-level compromise would bypass these

✅ High: git-http-backend Security - IMPROVED

Previous Issue: git-http-backend was spawned with GIT_PROJECT_ROOT set to the entire repoRoot, allowing potential access to all repositories.

Current Protection (✅ IMPLEMENTED):

• ✅ GIT_PROJECT_ROOT now set to specific repository path (not entire repoRoot)
• ✅ PATH_INFO adjusted to be relative to the repository
• ✅ Path validation ensures repository path is within repoRoot
• ✅ Limits git-http-backend's view to only the intended repository

Remaining Concerns:

• No chroot/jail isolation (git-http-backend still runs in same process context)
• If git-http-backend has vulnerabilities, it could still access files within the repo
• ✅ Runs as dedicated gitrepublic user (non-root) - IMPLEMENTED

⚠️ Medium: No Resource Limits Per Tenant

Issue: No per-user resource limits:

• One user could exhaust disk space (2GB per repo limit, but unlimited repos)
• One user could exhaust memory/CPU
• No rate limiting per user

Current Protection:

• 2GB repository size limit
• 500MB per-file limit
• But no per-user quotas

✅ Medium: Filesystem Access - IMPROVED

Previous Issue: Repository paths were not validated to ensure they stayed within repoRoot.

Current Protection (✅ IMPLEMENTED):

• ✅ Repository path validation using resolve() to check absolute paths
• ✅ Ensures resolved repository path starts with resolved repoRoot
• ✅ Prevents path traversal attacks at the repository level
• ✅ File path validation within repositories (already existed)
• ✅ Access control checks for private repos

Remaining Concerns:

• No chroot/jail isolation
• All repos readable by the same process user
• Relies on application logic, not OS-level isolation

⚠️ Low: Network Isolation

Issue: All repos accessible from same endpoints:

• No network-level isolation between tenants
• All repos share same IP/domain

Impact: Low - this is expected for a multi-tenant service

Security Improvements Made

✅ Implemented (2024)

1. ✅ Repository Path Validation

   • Added resolve() checks to ensure repository paths stay within repoRoot
   • Prevents path traversal attacks at the repository level
   • Applied to all git operations (GET and POST handlers)

2. ✅ git-http-backend Isolation

   • Changed GIT_PROJECT_ROOT from entire repoRoot to specific repository path
   • Adjusted PATH_INFO to be relative to the repository
   • Limits git-http-backend's view to only the intended repository

3. ✅ File Path Validation (Already existed)

   • Validates file paths within repositories
   • Prevents path traversal within repos
   • Blocks absolute paths, null bytes, control characters

Recommendations

✅ Implemented (2024)

1. ✅ Resource Limits - IMPLEMENTED

   • ✅ Per-user repository count limits (configurable via MAX_REPOS_PER_USER)
   • ✅ Per-user disk quota (configurable via MAX_DISK_QUOTA_PER_USER)
   • ✅ Rate limiting per user/IP (configurable via RATE_LIMIT_* env vars)
   • ✅ Applied to fork operations and repository creation

2. ✅ Audit Logging - IMPLEMENTED

   • ✅ Logs all repository access attempts
   • ✅ Logs all file operations (read/write/delete)
   • ✅ Logs authentication attempts
   • ✅ Logs ownership transfers
   • ✅ Structured JSON logging format

3. ✅ Enhanced git-http-backend Security - IMPLEMENTED

   • ✅ Operation timeouts (5 minutes max)
   • ✅ Process isolation (no shell, minimal environment)
   • ✅ Audit logging for all git operations
   • ✅ Path validation and scoping
   • ⚠️ Chroot/jail still not implemented (complex, requires root or capabilities)

Remaining (Medium Priority)

Medium Priority

4. Process Isolation (Complex)

   • Run each tenant in separate container/process
   • Use Docker with per-tenant containers
   • Significant architectural change

5. Filesystem Isolation

   • Use bind mounts with restricted permissions
   • Implement per-tenant filesystem quotas
   • Use separate volumes per tenant

6. ✅ Audit Logging - IMPLEMENTED

   • ✅ Log all repository access attempts
   • ✅ Log all file operations
   • ⏳ Monitor for suspicious patterns (requires log analysis tools)

Long-term

7. Container-per-Tenant Architecture

   • Each user gets their own container
   • Complete isolation
   • Higher resource overhead

8. Kubernetes Namespaces

   • Use K8s namespaces for tenant isolation
   • Network policies for isolation
   • Resource quotas per namespace

Current Security Posture

For a decentralized, open-source git hosting service, the current security model is reasonable but not enterprise-grade:

✅ Adequate for:

• Public repositories
• Open-source projects
• Personal/community hosting
• Low-to-medium security requirements

⚠️ Not adequate for:

• Enterprise multi-tenant SaaS
• Highly sensitive/regulated data
• Environments requiring strict compliance (HIPAA, PCI-DSS, etc.)
• High-security government/military use

Conclusion

The system uses application-level security with good input validation and access control, but lacks OS-level isolation. This is a common trade-off for multi-tenant services - it's simpler and more resource-efficient, but less secure than process/container isolation.

Recommendation: For most use cases (public repos, open-source hosting), the current model is acceptable. For enterprise or high-security use cases, consider implementing process/container isolation.