Orlok

Modello di sicurezza

Cosa protegge Orlok, come, e cosa lascia a te.

Orlok permette ai colleghi virtuali di leggere la tua wiki ed eseguire comandi sui tuoi sistemi. Questa pagina spiega cosa si mette tra un collega e un errore, e cosa invece non copre.

Principi

  • Un collega non ha mai più diritti della sua persona. Lavora con il profilo, gli uffici e le credenziali di quella persona, e con nient'altro. Vedi Ruoli e permessi.
  • Le credenziali appartengono alle persone. Ogni persona salva le proprie, una per host. Su un server un collega agisce come la persona per cui lavora, quindi i permessi e i log del server continuano a valere.
  • Decidono le persone. In modalità Chiedi, tutto ciò che non è chiaramente di sola lettura attende l'approvazione della persona.
  • Tutto viene messo per iscritto. Ogni modifica e ogni job finiscono in un registro in sola aggiunta, senza segreti.

Account e sessioni

  • Le password sono salvate come hash con Argon2.
  • L'accesso viene rallentato dopo 10 tentativi falliti su un account o 50 da un indirizzo in 15 minuti.
  • Una sessione è un token casuale in un cookie HttpOnly, SameSite=Lax. Viene salvato solo il suo hash SHA-256. Il cookie è marcato Secure quando ORLOK_PUBLIC_URL usa https.
  • Una sessione dura 12 ore, o 30 giorni con Ricordami su questo dispositivo, e si rinnova mentre la usi. Ogni persona vede i propri dispositivi collegati in Account e può disconnetterli.
  • Disattivare una persona termina subito le sue sessioni ed elimina le sue credenziali. L'app torna alla pagina di accesso, che spiega il motivo.
  • I caricamenti e gli invii dei moduli devono arrivare dall'indirizzo di Orlok stesso (controllo CSRF), e il cookie di sessione non viene inviato con le richieste che altri siti avviano in background.
  • I link di invito contengono un token casuale, salvato solo come hash, e scadono dopo 7 giorni.

Segreti a riposo

  • Le chiavi API dei provider dei modelli e le credenziali delle persone sono cifrate con AES-256-GCM, usando ORLOK_SECRET_KEY. La chiave non viene mai salvata nel database.
  • Una credenziale viene decifrata solo per consegnarla al runner per un singolo job. L'API non la restituisce mai, nemmeno al suo proprietario o a un amministratore.

Fai il backup della chiave a parte. Un backup del database senza ORLOK_SECRET_KEY non può decifrare niente, e la chiave senza il database è inutile. Tienili separati, e tienili entrambi. Vedi Backup.

Segreti nella wiki e negli output

La wiki dell'ufficio la leggono tutti nell'ufficio e viene inviata ai provider dei modelli, quindi Orlok cerca di tenerne fuori i segreti:

  • la scrittura di una pagina da parte di un collega viene rifiutata se sembra contenere una password, una chiave privata o un token API;
  • i comandi e il loro output vengono mascherati dove sembrano segreti prima di essere salvati, così la conversazione, il registro e il modello vedono il testo mascherato.

Il riconoscimento dei pattern è una rete, non un muro. Cattura le chiavi private, i formati di token più comuni e le righe del tipo «password: valore». Un segreto scritto in un modo insolito può comunque passare. Non incollare password nella wiki o in una conversazione: salvale in Account → Credenziali.

Il runner

I colleghi non eseguono mai comandi dentro l'app. Li chiedono al runner, un container separato:

  • non pubblica porte, lo raggiunge solo l'app, e condivide un token con l'app;
  • non è sulla rete del database e non contiene dati di Orlok;
  • rinuncia a tutte le capability Linux tranne le tre che gli servono: far girare ogni job con un utente dedicato, e ICMP raw per ping;
  • ogni job gira con un utente dedicato, in una cartella di lavoro nuova, con limiti su memoria, tempo di CPU, dimensione dei file, file aperti e processi (vedi Variabili d'ambiente);
  • il suo filesystem è di sola lettura, tranne una cartella temporanea.

Anche il container dell'app gira con un filesystem di sola lettura, senza capability Linux e senza modo di ottenere nuovi privilegi. Postgres è raggiungibile solo dall'app. Vedi Protezione dell'installazione.

Host

  • La chiave host SSH diventa attendibile alla prima connessione che riesce a entrare, poi viene imposta: se la macchina presenta una chiave diversa, la connessione viene rifiutata, qualunque credenziale si usi.
  • Cambiare l'indirizzo di un host ne dimentica la chiave, e un amministratore può dimenticarla di proposito con Dimentica chiave host.

La prima connessione si fida di chiunque risponda. Fai la prima connessione a un nuovo host da una rete di cui ti fidi, oppure confronta la chiave salvata con quella della macchina.

Comandi

Come un collega esegue i comandi dipende dalla modalità del suo profilo (vedi Modalità):

Modalità Comandi di sola lettura Altri comandi Comandi catastrofici
Nega — — —
Chiedi partono attendono l'approvazione, a meno che la persona abbia scelto «Consenti sempre» per quel tipo di comando rifiutati
Accesso completo partono partono rifiutati
Yolo partono partono partono
  • I comandi di sola lettura si riconoscono da un elenco di comandi di diagnostica che ispezionano lo stato senza cambiarlo e senza rivelare segreti.
  • I comandi catastrofici sono un breve elenco sempre rifiutato fuori da Yolo: per esempio cancellare dischi o filesystem, rimuovere la cartella radice, eliminare le copie shadow, svuotare i registri eventi, rimuovere un dominio o una foresta AD, o cambiare il proprietario o i permessi dell'intero filesystem.
  • Solo la persona per cui gira un comando può approvarlo.
  • Un tipo di comando approvato con «Consenti sempre» appartiene a una sola persona: vale per i colleghi di quella persona, e per nessun altro. Un amministratore può disattivarlo.
  • Un comando che non si può leggere fino in fondo, come uno script o una riga costruita con variabili, si può approvare solo una volta, mai «sempre».

Approvare è leggere. Un'approvazione lascia passare esattamente il comando mostrato. Leggilo prima di approvare, soprattutto se è un lungo script: Orlok non può dirti cosa farà uno script opaco.

Da cosa Orlok non protegge

  • Ciò che vede il provider del modello. Le conversazioni, le pagine della wiki che un collega legge e l'output dei suoi comandi vengono inviati al provider del modello del profilo. Per i dati che non devono uscire dalla tua rete, usa un modello che ospiti tu (Ollama o un server compatibile con OpenAI).
  • Una credenziale con troppi diritti. Su un server un collega può fare tutto ciò che l'account della sua persona può fare lì. Dai alle persone account con i diritti minimi che bastano per il lavoro.
  • Istruzioni nascoste nei contenuti. Il testo in un documento, in una pagina della wiki, in una pagina web, nell'output di un comando o nella risposta di un server MCP può cercare di guidare un collega. In modalità Chiedi, le approvazioni fanno da freno. In Accesso completo e Yolo niente ferma un comando che le regole lasciano passare.
  • L'host Docker. Chi controlla il server, i volumi o .env.production controlla Orlok e tutto quello che contiene.
  • HTTP in chiaro. Senza HTTPS, i cookie e tutto il resto viaggiano in chiaro sulla rete. Vedi HTTPS.