Quanto è pericoloso non caricare le regole 'seccomp' per i contenitori di sviluppo (LXC)?

Question

Quanto è pericoloso non caricare le regole 'seccomp' per i contenitori di sviluppo (LXC)?

#1 da (2 voti)

2

Molti amministratori disattivano seccomp sulla loro piattaforma di containerizzazione in un compromesso con facilità d'uso / applicazione.

Tuttavia, disabilitare tali impostazioni di sicurezza di base che sono così pesantemente legate alla sandboxing, in una certa misura, vanifica lo scopo della containerizzazione. Dal punto di vista della sicurezza / stabilità I penseremmo saggio mantenere la lista nera della maggior parte delle chiamate di sistema quando si eseguono i contenitori LXC / Docker sui server (come configurato dai valori predefiniti di LXC in /usr/share/lxc/config/common.seccomp ) :

2
blacklist
[all]
kexec_load errno 1
open_by_handle_at errno 1
init_module errno 1
finit_module errno 1
delete_module errno 1

Domande

Non 'caricamento delle regole seccomp per i contenitori LXC' resa:

significativo * problemi di sicurezza?
qualsiasi altro problema tecnico (applicazione o stabilità)

* Domanda bonus: quali sarebbero i rischi quando si presume che uno sia l'unico che usa il sistema "madre" e i suoi contenitori LXC (ad esempio in un laboratorio sperimentale, dove potrebbe essere meno evidente avere più utenti, ma containerizzazione offre ancora molti vantaggi come la semplice snapshot / clonazione di ambienti sperimentali?

linux virtualization

posta woosting 25.08.2016 - 11:08

fonte

1 risposta

Leggi altre domande sui tag linux virtualization

Iniezione speciale per sqlmap Packet Injection durante attacchi su WPA / WPA2 / WEP - Come funziona

score 2 · Accepted Answer

La sicurezza non è una cosa assoluta come sembri assumere: nessuna cosa è pericolosa da sola, le cose sono pericolose solo se si considera una minaccia specifica.

La sicurezza può essere definita solo in base a una serie di minacce precise e fattuali che possono influire sull'uso previsto della piattaforma.

Quello che dici nella tua domanda, secondo la mia comprensione, è che non hai intenzione di usare LXC per scopi di sicurezza (ad esempio non ti affidi a LXC per isolare un'applicazione compromessa, per esempio), invece ti affidi a LXC solo per rendere più semplice la clonazione e l'istantanea degli ambienti sperimentali personali locali.

Da ciò, l'unica cosa che potrebbe importare è che l'uso di LXC riduca in qualche modo la sicurezza del sistema sottostante: la risposta è no, in peggio LXC non fornirà benefici di sicurezza ma non ridurrà la sicurezza di il sistema sottostante (avrà solo lo stesso effetto di chroot ). L'esecuzione di un'applicazione su un computer abilitato per LXC non sarà meno sicura se si esegue la stessa applicazione sullo stesso sistema senza LXC.

Non dimenticare che, se usi LXC per archiviare sistemi Linux completi (che credo sia il caso più comune), le stesse regole di igiene della sicurezza si applicano sia al sistema host che a quello ospiti:

Non utilizzare password deboli,
Applica aggiornamenti di sicurezza,
Etc.

Per una macchina di sviluppo, a seconda delle esigenze effettive, la superficie di attacco può essere notevolmente ridotta impedendo che i servizi ospitati da LXC siano raggiungibili attraverso la rete. Mantenendo tale applicazione in ascolto solo su interfacce locali, si mantiene la capacità di sviluppare ciò che si desidera pur garantendo che un utente malintenzionato remoto non sia in grado di sfruttare qualche difetto del proprio lavoro o che l'ospite sottostante acceda al proprio sistema.

Come da problemi tecnici di applicazione / stabilità, non sono a conoscenza di qualcosa di particolare. Se riscontri problemi di questo tipo, deve essere trattato singolarmente su Unix.SE o mailing list LXC per esempio.