Politiche di rete sotto AppArmor / SELinux

Dichiarazione di non responsabilità: non sono esperto di SELinux o AppArmor, quindi è necessario verificare tutto ciò che dico per te.

Penso che ci sia un modo per far funzionare SELinux e IPTables insieme. SELinux può etichettare i pacchetti con un tag che indica il contesto / origine / provenienza SELinux che si applica al pacchetto. È quindi possibile scrivere regole IPTables che ispezionano questo tag per applicare un criterio firewall diverso in base al valore di questo tag. Questo sembra un modo potenziale per eseguire un controllo a grana fine, ad es. Per far rispettare una particolare applicazione che può comunicare solo con un determinato numero o protocollo di porta. Riferimenti: rendendo SELinux e IPTables parlano tra loro , un articolo su questo e la discussione corrispondente su LWN , e background su secmark, il sottosistema di marcatura dei pacchetti .

Per AppArmor, per quanto ne so questo non è attualmente supportato. C'è una voce track tracker che richiede questa funzione.

Credo che Systrace abbia già il supporto per questo tipo di controllo a grana fine, integrato.

Per aggiungere una nota di esperienza personale a quanto sopra - usando selinux in combinazione con iptables, sia la policy che il tuo iptables appaiono estremamente complicati e complicati. È uno di quei casi in cui il trade-off della complessità deve davvero valere la pena - a meno che non si stia assicurando un'installazione militare in cui l'etichettatura dei pacchetti corretta significhi vita o morte, io non lo consiglierei.

SELinux fornisce alcune etichette di porta / protocollo di base che non si collegano con iptables. Per esempio. se si esegue semanage port -l , verrà fornito un elenco di tutte le porte definite nella politica di destinazione. Puoi usarlo per limitare le porte su cui un dominio SELinux può comunicare. Ad esempio, puoi scrivere una norma che attesti che myapp_t può solo associare a myapp_port_t e connettersi a http_port_t . Questo è già abbastanza buono: se un utente malintenzionato riesce a sfruttare l'app, non sarebbe in grado di collegarsi a nessun'altra porta o connettersi a qualcosa di diverso da 80 / tcp (ad esempio questo sventerebbe un tentativo di connettersi a IRC).

Se fossi davvero interessato, potresti andare oltre e dire - etichettare tutti i pacchetti creati da myapp_port_t come myapp_packet_t e configurare il firewall per passare solo myapp_packet_t a -d 10.10.10.1 --dport 443 . Quindi, se un utente malintenzionato riuscisse a sfruttare quell'app, sarebbe solo in grado di comunicare con 10.10.10.1 sulla porta 443, mentre altre app, come un browser, non sarebbero altrimenti limitate.

Detto questo, anche se è fantastico in teoria, in pratica le app producono molto più traffico di pacchetti rispetto a quel tcp in uscita sulla porta 443. Un'app dovrebbe fare nslookups (quindi è necessario consentire myapp_packet_t udp alla porta 53 ), e se le informazioni dell'utente provengono da ldap, probabilmente genererebbero il traffico LDAP. Di conseguenza, le tue politiche e i tuoi iptables si gonfiano rapidamente in mostruosità ingestibili. Raccomando di attenersi all'etichettatura della porta di base. :)