Oppure

Sul mio laptop ci sono voluti circa 15 minuti (sarà molto più veloce se lo esegui di nuovo). Il passaggio del symlink all'inizio non è necessario se la tua VM di build è standalone. Dà a Docker più spazio su disco ed evita di perdere la cache delle immagini Docker quando riavvii la Qube. Con Podman non serve, poiché i container vivono nella tua home directory per impostazione predefinita.

Nota: i file oggetto sono memorizzati nella directory _build per velocizzare le build incrementali. Se cambi le dipendenze, dovrai eliminare questa directory prima di ricompilare.

Va bene installare il pacchetto Docker o Podman in una VM template se vuoi che rimanga dopo un riavvio, ma la build del firewall stesso dovrebbe essere fatta in una normale AppVM.

Puoi anche compilare senza quello script, come per qualsiasi normale unikernel Mirage; vedi le istruzioni di installazione di Mirage per i dettagli.

Lo script di build fissa le versioni delle librerie che usa, assicurando che tu ottenga esattamente lo stesso binario della release. Se compili senza, verrà compilato contro le ultime versioni (e quindi probabilmente l'hash non corrisponderà). Tuttavia, dovrebbe funzionare comunque bene.

Deploy

Manual deployment

Se vuoi fare il deploy manualmente, devi solo scaricare qubes-firewall.xen e qubes-firewall.sha256 in domU e verificare che il file .xen abbia un hashsum corrispondente. qubes-firewall.xen è l'unikernel stesso e dovrebbe essere copiato in vmlinuz nella directory /var/lib/qubes/vm-kernels/mirage-firewall in dom0, es. (se dev è la AppVM dove hai compilato):

Esegui questo comando in dom0 per creare una VM mirage-firewall usando il kernel mirage-firewall aggiunto sopra

Deployment usando saltstack

Se sai come eseguire gli stati salt in Qubes, puoi anche usare lo script SaltScriptToDownloadAndInstallMirageFirewallInQubes.sls per distribuire automaticamente l'ultima versione del firewall mirage nel tuo Qubes OS. Un'introduzione si può trovare qui e qui. Seguendo le istruzioni del primo link, puoi eseguire lo script in dom0 con il comando sudo qubesctl --show-output state.apply SaltScriptToDownloadAndInstallMirageFirewallInQubes saltenv=user. Lo script controlla il checksum dal server di integrazione e lo confronta con l'ultima versione fornita nelle release di github. Potrebbe essere necessario adattare i template VM nello script usati per il download dell'unikernel mirage, se i tuoi template predefiniti non hanno gli strumenti curl e tar installati di default. Inoltre, non dimenticare di cambiare le VM in cui l'unikernel dovrebbe essere usato o di regolare le "Qubes Global Settings".

Upgrading

Per aggiornare da una release precedente, basta sovrascrivere /var/lib/qubes/vm-kernels/mirage-firewall/vmlinuz con la nuova versione e riavviare la VM del firewall.

Configurare le AppVM per usarlo

Puoi eseguire mirage-firewall insieme al tuo sys-firewall esistente e puoi scegliere quali AppVM usano quale firewall tramite la GUI. Per configurare una AppVM per usarlo, vai nelle impostazioni della VM app nella GUI e cambia il suo NetVM da default (sys-firewall) a mirage-firewall.

Puoi anche configurarlo eseguendo questo comando in dom0 (sostituisci my-app-vm con il nome della AppVM):

In alternativa, puoi configurare mirage-firewall come VM firewall predefinita.

Nota che di default dom0 usa sys-firewall come sua "UpdateVM" (un proxy per scaricare gli aggiornamenti). mirage-firewall non può essere usato per questo, ma qualsiasi VM Linux dovrebbe andare bene. https://www.qubes-os.org/doc/software-update-dom0/ dice:

Il ruolo di UpdateVM può essere assegnato a qualsiasi VM nel Qubes VM Manager, e non ci sono implicazioni di sicurezza significative in questa scelta. Di default, questo ruolo è assegnato alla firewallvm.

Configurare il firewall con netvm stile OpenBSD

OpenBSD attualmente non può essere usato come netvm, quindi se vuoi usare un BSD come VM sys-net, dovrai impostare il suo netvm su qubes-mirage-firewall (vedi https://github.com/mirage/qubes-mirage-firewall/issues/146 per maggiori informazioni). Ciò significa che avrai AppVMs -> qubes-mirage-firewall <- OpenBSD con la freccia che rappresenta l'impostazione della proprietà netvm.

In tal caso dovrai dire a qubes-mirage-firewall quale client AppVM deve essere usato come uplink:

con X.X.X.X l'indirizzo IP per mirage-firewall e Y.Y.Y.Y l'indirizzo IP del tuo HVM OpenBSD.

Componenti

Questo diagramma mostra i componenti principali (ogni riquadro corrisponde a un file sorgente .ml con lo stesso nome):

I frame Ethernet arrivano dai qubes client (come work o personal) o da sys-net. I pacchetti Internet (IP) vengono inviati a firewall, che consulta la tabella NAT e le regole da QubesDB per decidere cosa fare con il pacchetto. Se deve essere inoltrato, usa router per inviarlo alla destinazione scelta. client_net osserva il database XenStore fornito da dom0 per scoprire quando i client devono essere aggiunti o rimossi.

Il processo di avvio:

• config.ml descrive le librerie usate e le impostazioni di configurazione statiche (dimensione della tabella NAT). Lo strumento mirage usa questo per generare main.ml.
• main.ml inizializza i driver selezionati da config.ml e chiama la funzione start in unikernel.ml.
• unikernel.ml collega gli agenti Qubes, configura i componenti di rete, e poi attende una richiesta di spegnimento.

Deployment facile per sviluppatori

Per lo sviluppo, usa gli script test-mirage per distribuire l'unikernel (qubes-firewall.xen) dalla tua AppVM di sviluppo. La prima volta richiede un po' più di configurazione, ma dopo sarà molto più veloce. es.

Testare se il firewall funziona

Un unikernel che testa il firewall è disponibile nella sottodirectory test/. Per usarlo, esegui test.sh e segui le istruzioni per configurare l'ambiente di test.

Avvisi di sicurezza

Vedi issue etichettate "security" per gli avvisi di sicurezza che riguardano il firewall.

LICENZA

Vedi LICENSE.md