Security: Eindeutigere pexp-Pattern für Service-Isolation #80

Closed
opened 2025-06-23 19:51:45 +02:00 by Michael · 2 comments
Michael commented 2025-06-23 19:51:45 +02:00 (Migrated from gitea.dragons-at-work.de)

Problem

Das aktuelle pexp Pattern ist potentiell nicht eindeutig genug:

pexp="/usr/local/bin/lua src/main.lua.*"

Collision-Szenarien:

  • Andere Lua-Services könnten src/main.lua verwenden
  • Multiple Furt-Instanzen auf verschiedenen Ports
  • Lua-Services mit ähnlichen Pfad-Strukturen

Beispiel-Kollision:

# Furt Service:
_furt    12345 ... /usr/local/bin/lua src/main.lua (lua51)

# Hypothetischer anderer Service:
_other   67890 ... /usr/local/bin/lua /opt/app/src/main.lua
_app     11111 ... /usr/local/bin/lua /var/service/src/main.lua

Alle würden mit dem aktuellen Pattern matchen!

Lösungsansätze

Option 1: Working Directory-spezifisch

# OpenBSD ps zeigt Working Directory nicht standardmäßig
# Müsste mit pwdx oder /proc getestet werden
pexp="lua.*furt.*src/main.lua"

Option 2: Absolute Pfad-Kontext

# Spezifischer, aber länger
pexp="/usr/local/bin/lua.*furt.*src/main.lua"

Option 3: Port-basierte Detection

# Funktional statt pattern-basiert
check_service_port() {
    walter_exec "netstat -an | grep -q ':8080.*LISTEN'"
}

Option 4: PID-File basiert

# start.sh schreibt PID-File
echo $! > /var/run/furt.pid
# rc.d verwendet PID-File statt pexp

Option 5: Command-Line-Argument einzigartig machen

# start.sh übergibt unique identifier
$LUA_CMD src/main.lua --service-id=furt-karl-8080 &

# pexp wird spezifischer:
pexp="lua.*main.lua.*--service-id=furt"

Empfohlene Lösung: Hybrid-Ansatz

1. Unique Command-Line Flag

# In start.sh:
$LUA_CMD src/main.lua --furt-service-id="$(hostname)-$(id -un)-8080" &

# In main.lua argument parsing:
if arg[1] == "--furt-service-id" then
    local service_id = arg[2]
    -- Log service ID für debugging
end

2. Spezifischeres pexp

# In rc.d-furt:
pexp="/usr/local/bin/lua src/main.lua --furt-service-id"

3. Fallback PID-File

# Zusätzlich für Robustheit:
echo $! > /var/run/furt.pid

Sicherheits-Aspekte

Warum wichtig:

  1. Service-Isolation: Verhindert versehentliches Stop/Kill falscher Services
  2. Multi-Instance-Support: Ermöglicht mehrere Furt-Instanzen
  3. Debugging: Klarere Prozess-Identification
  4. Production-Safety: Reduziert Risiko von Service-Mix-ups

Test-Szenarien:

  • Multiple Lua-Services auf einem System
  • Furt-Development + Furt-Production parallel
  • Service-Restart während andere Lua-Prozesse laufen

Implementierung

Phase 1: Command-Line-ID

  • Lua argument parsing für --furt-service-id
  • start.sh erweitern um unique ID
  • pexp Pattern entsprechend anpassen

Phase 2: PID-File-Fallback

  • PID-File Schreibung in start.sh
  • rc.d Option für PID-basierte Detection
  • Cleanup von PID-Files bei Service-Stop

Phase 3: Testing

  • Multi-Service Test-Environment
  • Edge-Case Testing (process names, collisions)
  • Performance Impact Assessment

Akzeptanzkriterien

  • Eindeutige Service-Identification
  • Keine False-Positive Process-Matches
  • Multi-Instance-fähig
  • Backwards-kompatibel
  • Performance-neutral
  • Gut dokumentiert

Technische Notes

Current Pattern: /usr/local/bin/lua src/main.lua.*
Risk Level: Medium (collision possible)
Impact: Service management reliability
Priority: Medium (post-Issue DAW/furt#77 cleanup)

## Problem Das aktuelle `pexp` Pattern ist potentiell nicht eindeutig genug: ```bash pexp="/usr/local/bin/lua src/main.lua.*" ``` **Collision-Szenarien:** - Andere Lua-Services könnten `src/main.lua` verwenden - Multiple Furt-Instanzen auf verschiedenen Ports - Lua-Services mit ähnlichen Pfad-Strukturen **Beispiel-Kollision:** ``` # Furt Service: _furt 12345 ... /usr/local/bin/lua src/main.lua (lua51) # Hypothetischer anderer Service: _other 67890 ... /usr/local/bin/lua /opt/app/src/main.lua _app 11111 ... /usr/local/bin/lua /var/service/src/main.lua ``` Alle würden mit dem aktuellen Pattern matchen! ## Lösungsansätze ### Option 1: Working Directory-spezifisch ```bash # OpenBSD ps zeigt Working Directory nicht standardmäßig # Müsste mit pwdx oder /proc getestet werden pexp="lua.*furt.*src/main.lua" ``` ### Option 2: Absolute Pfad-Kontext ```bash # Spezifischer, aber länger pexp="/usr/local/bin/lua.*furt.*src/main.lua" ``` ### Option 3: Port-basierte Detection ```bash # Funktional statt pattern-basiert check_service_port() { walter_exec "netstat -an | grep -q ':8080.*LISTEN'" } ``` ### Option 4: PID-File basiert ```bash # start.sh schreibt PID-File echo $! > /var/run/furt.pid # rc.d verwendet PID-File statt pexp ``` ### Option 5: Command-Line-Argument einzigartig machen ```bash # start.sh übergibt unique identifier $LUA_CMD src/main.lua --service-id=furt-karl-8080 & # pexp wird spezifischer: pexp="lua.*main.lua.*--service-id=furt" ``` ## Empfohlene Lösung: Hybrid-Ansatz ### 1. Unique Command-Line Flag ```bash # In start.sh: $LUA_CMD src/main.lua --furt-service-id="$(hostname)-$(id -un)-8080" & # In main.lua argument parsing: if arg[1] == "--furt-service-id" then local service_id = arg[2] -- Log service ID für debugging end ``` ### 2. Spezifischeres pexp ```bash # In rc.d-furt: pexp="/usr/local/bin/lua src/main.lua --furt-service-id" ``` ### 3. Fallback PID-File ```bash # Zusätzlich für Robustheit: echo $! > /var/run/furt.pid ``` ## Sicherheits-Aspekte ### Warum wichtig: 1. **Service-Isolation:** Verhindert versehentliches Stop/Kill falscher Services 2. **Multi-Instance-Support:** Ermöglicht mehrere Furt-Instanzen 3. **Debugging:** Klarere Prozess-Identification 4. **Production-Safety:** Reduziert Risiko von Service-Mix-ups ### Test-Szenarien: - Multiple Lua-Services auf einem System - Furt-Development + Furt-Production parallel - Service-Restart während andere Lua-Prozesse laufen ## Implementierung ### Phase 1: Command-Line-ID - [ ] Lua argument parsing für `--furt-service-id` - [ ] start.sh erweitern um unique ID - [ ] pexp Pattern entsprechend anpassen ### Phase 2: PID-File-Fallback - [ ] PID-File Schreibung in start.sh - [ ] rc.d Option für PID-basierte Detection - [ ] Cleanup von PID-Files bei Service-Stop ### Phase 3: Testing - [ ] Multi-Service Test-Environment - [ ] Edge-Case Testing (process names, collisions) - [ ] Performance Impact Assessment ## Akzeptanzkriterien - [ ] Eindeutige Service-Identification - [ ] Keine False-Positive Process-Matches - [ ] Multi-Instance-fähig - [ ] Backwards-kompatibel - [ ] Performance-neutral - [ ] Gut dokumentiert ## Technische Notes Current Pattern: `/usr/local/bin/lua src/main.lua.*` Risk Level: Medium (collision possible) Impact: Service management reliability Priority: Medium (post-Issue DAW/furt#77 cleanup)
michael added this to the v0.1.2 - Gateway Basics milestone 2025-08-14 05:20:48 +02:00
Owner

SCOPE-ÄNDERUNG - Teil der Deployment-Modernisierung

pexp-Pattern Security gehört zu DAW/furt#87 (Wiki + Deployment-System):

  • OpenBSD Service-Security → Wiki-Dokumentation
  • Service-Management → Teil der Helper-Scripts
  • Integration mit DAW/furt#79 (OpenBSD rc.d Dokumentation)

Integration in DAW/furt#87: Service-Security-Komponente

**SCOPE-ÄNDERUNG - Teil der Deployment-Modernisierung** pexp-Pattern Security gehört zu DAW/furt#87 (Wiki + Deployment-System): - OpenBSD Service-Security → Wiki-Dokumentation - Service-Management → Teil der Helper-Scripts - Integration mit DAW/furt#79 (OpenBSD rc.d Dokumentation) **Integration in DAW/furt#87:** Service-Security-Komponente
Owner

wird in Zukunft über PID File gelöst DAW/furt#100

wird in Zukunft über PID File gelöst DAW/furt#100
Sign in to join this conversation.
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: DAW/furt#80
No description provided.