ancora doc

README.md

@@ -1,4 +1,22 @@
-super light hardened container:
+## Light Hardened Container
 
-automatizzo l'uso di  systemd-nspawn con la rootfs di alpine linux, installo quello che devo e elimino tutti i file non usati dal processo che mi interessa (quindi nel container rimangono pochissimi files). I containers sono dentro una partizione read-only e con systemd-nspawn uso bind su una partizione di dati che sara' noexec.
+#### Perché
-l'idea e' che tutti i servizi sono separati nei loro containers 
+Voglio esporre su internet alcuni servizi da una board (Odroid C2).
+Giocando con i vari sistemi per creare container quello piú simile ai miei desideri é `systemd-nspawn` (si, systemd é una merda ed é il male). `systemd-nspawn` é tipo una chroot ma meglio.
+
+### Come
+Uso [alpine linux](https://alpinelinux.org) come base perché la rootfs é scandalosamente piccola (1.9Mb), supporta arm64 (che é l'architettura della mia board casalinga), supporta un sistema di pacchetti degno di questo nome (apk) ed e' orientata alla sicurezza.
+
+L'assunto di base é che i servizi che girano dentro il container sono bucabili e quindi bisogna limitare i danni di un sicuro pwn.
+Per fare questo ho pensato di far girare la root di ogni container dentro una partizione read-only.
+Per i dati necessari ai vari servizi, faccio un bind di una directory da una partizione no-exec in modo che
+anche se il servizio viene bucato, l'attaccante puó scrivere solamente sulla partizione dei dati (da cui non puo'
+peró avviare niente).
+
+Per evitare di far usare interpreti e altre utilities utili all'attaccante, il container deve contenere esclusivamente i files strettamente necessari per far girare il servizio. Per fare questo, prima della fase di deploy il servizio verrá fatto girare con strace per controllare tutte le syscall a `open`.
+
+Ricapitolando, immaginiamo di voler far girare `nginx` in questa maniera:
+
+- Scarichiamo la rootfs di alpine
+- `systemd-nspawn -D ` 
+....