La scorsa settimana abbiamo discusso su come configurare AppArmor per i set di repliche MongoDB, che sostanzialmente ha gli stessi concetti applicabili durante la configurazione per i sistemi basati su MySQL. In effetti, la sicurezza è molto importante perché devi assicurarti che i tuoi dati siano ben protetti e incapsulati contro la raccolta indesiderata di informazioni dal tuo dominio aziendale.
Un po' di storia su AppArmor
AppArmor è stato utilizzato per la prima volta in Immunix Linux dal 1998 al 2003. All'epoca, AppArmor era noto come SubDomain, un riferimento alla capacità di un profilo di sicurezza per un programma specifico di essere segmentato in domini diversi, tra i quali il programma può passare dinamicamente. AppArmor è stato reso disponibile per la prima volta in SLES e openSUSE ed è stato abilitato per impostazione predefinita in SLES 10 e in openSUSE 10.1.
Nel maggio 2005 Novell ha acquisito Immunix e ha rinominato SubDomain come AppArmor e ha iniziato la pulizia e la riscrittura del codice per l'inclusione nel kernel Linux. Dal 2005 al settembre 2007, AppArmor è stata gestita da Novell. Novell è stata rilevata da SUSE, che ora sono i proprietari legali del nome del marchio AppArmor.
AppArmor è stato portato/impacchettato per la prima volta con successo per Ubuntu nell'aprile 2007. AppArmor è diventato un pacchetto predefinito a partire da Ubuntu 7.10 ed è arrivato come parte del rilascio di Ubuntu 8.04, proteggendo solo CUPS per impostazione predefinita. A partire da Ubuntu 9.04 altri elementi come MySQL hanno installato profili. La protezione avanzata di AppArmor ha continuato a migliorare in Ubuntu 9.10 poiché viene fornito con i profili per la sua sessione ospite, le macchine virtuali libvirt, il visualizzatore di documenti Evince e un profilo Firefox opzionale.
Perché abbiamo bisogno di AppArmor?
Nel nostro blog precedente, abbiamo affrontato un po' l'uso di AppArmor. È un sistema di controllo dell'accesso obbligatorio (MAC), implementato sui moduli di sicurezza Linux (LSM). È usato e per lo più abilitato per impostazione predefinita in sistemi come Ubuntu, Debian (da Buster), SUSE e altre distribuzioni. È paragonabile a RHEL/CentOS SELinux, che richiede una buona integrazione dello spazio utente per funzionare correttamente. SELinux allega etichette a tutti i file, processi e oggetti ed è quindi molto flessibile. Tuttavia, la configurazione di SELinux è considerata molto complicata e richiede un filesystem supportato. AppArmor, invece, funziona utilizzando i percorsi dei file e la sua configurazione può essere facilmente adattata.
AppArmor, come la maggior parte degli altri LSM, integra anziché sostituire il controllo di accesso discrezionale (DAC) predefinito. In quanto tale, è impossibile concedere a un processo più privilegi di quelli che aveva in primo luogo.
AppArmor protegge in modo proattivo il sistema operativo e le applicazioni da minacce esterne o interne e persino da attacchi zero-day, applicando un set di regole specifico in base all'applicazione. Le politiche di sicurezza definiscono completamente a quali risorse di sistema possono accedere le singole applicazioni e con quali privilegi. L'accesso è negato per impostazione predefinita se nessun profilo dice diversamente. Alcuni criteri predefiniti sono inclusi in AppArmor e, utilizzando una combinazione di analisi statica avanzata e strumenti basati sull'apprendimento, i criteri di AppArmor per applicazioni anche molto complesse possono essere implementati con successo nel giro di poche ore.
Ogni violazione delle norme attiva un messaggio nel registro di sistema e AppArmor può essere configurato per notificare agli utenti avvisi di violazione in tempo reale.
AppArmor per MySQL
Ho configurato un cluster basato su replica MySQL utilizzando ClusterControl sui miei nodi di database di destinazione in esecuzione in Ubuntu Bionic. Puoi seguire ulteriormente questo blog su come distribuirlo o seguire questo tutorial video. Tieni presente che ClusterControl controlla o disabilita AppArmor durante la distribuzione. Potrebbe essere necessario deselezionarlo in base alla configurazione, proprio come di seguito:
ClusterControl emetterà semplicemente un avviso che non sta toccando la configurazione di AppArmor corrente . Vedi sotto:
Gestire i tuoi profili AppArmor
L'installazione standard di AppArmor in Ubuntu non includerebbe utilità che aiuterebbero a gestire i profili in modo efficiente. Quindi installiamo questi pacchetti in questo modo:
$ apt install apparmor-profiles apparmor-utilsUna volta installato, controlla lo stato di AppArmor nel sistema eseguendo il comando aa-status. Nel nodo che sto usando, ho il seguente output senza MySQL 8 installato.
$ aa-status
apparmor module is loaded.
15 profiles are loaded.
15 profiles are in enforce mode.
/sbin/dhclient
/usr/bin/lxc-start
/usr/bin/man
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/connman/scripts/dhclient-script
/usr/lib/snapd/snap-confine
/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
/usr/sbin/tcpdump
lxc-container-default
lxc-container-default-cgns
lxc-container-default-with-mounting
lxc-container-default-with-nesting
man_filter
man_groff
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.Dato che sto usando ClusterControl per distribuire il mio cluster basato su replica MySQL con AppArmor (ovvero ClusterControl non toccherà la mia attuale configurazione di AppArmor), la distribuzione dovrà avere il profilo MySQL in posizione e questo apparirà in l'elenco che esegue aa-status.
$ aa-status
apparmor module is loaded.
56 profiles are loaded.
19 profiles are in enforce mode.
...
/usr/sbin/mysqld
...
37 profiles are in complain mode.
...
1 processes have profiles defined.
1 processes are in enforce mode.
/usr/sbin/mysqld (31501)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
Vale la pena notare che un profilo è in una delle seguenti modalità:
-
Applica - Impostazione predefinita. Le applicazioni non possono eseguire azioni limitate dalle regole del profilo.
-
Reclamo:le applicazioni possono eseguire azioni limitate e le azioni vengono registrate.
-
Disabilitato:le applicazioni possono eseguire azioni limitate e le azioni non vengono registrate.
Puoi anche combinare i profili di applicazione e di reclamo nel tuo server.
Sulla base dell'output sopra, elaboriamo di più sul reclamo del profilo. AppArmor gli consentirà di eseguire (quasi come lo stato della modalità reclamo applicherà comunque qualsiasi regola di rifiuto esplicito in un profilo) tutte le attività senza restrizioni ma le registrerà nel registro di controllo come eventi. Ciò è utile quando si tenta di creare un profilo per un'applicazione ma non si è sicuri a quali elementi deve accedere. Considerando che lo stato non confinato, d'altra parte, consentirà al programma di eseguire qualsiasi attività e non lo registrerà. Questo di solito si verifica se un profilo è stato caricato dopo l'avvio di un'applicazione, il che significa che viene eseguito senza restrizioni da AppArmor. È anche importante notare che solo i processi che hanno profili sono elencati in questo stato non confinato. Tutti gli altri processi eseguiti sul tuo sistema ma per i quali non è stato creato un profilo non verranno elencati in aa-status.
Se hai disabilitato AppArmor ma poi ti rendi conto che volevi migliorare la tua sicurezza o rispettare le normative di sicurezza, puoi utilizzare questo profilo MySQL 8.0 fornito da MySQL stesso. Per applicarlo, esegui il seguente comando:
$ cat /etc/apparmor.d/usr.sbin.mysqld | sudo apparmor_parser -aVale la pena notare che i profili AppArmor sono memorizzati per impostazione predefinita in /etc/apparmor.d/. È buona norma aggiungere i tuoi profili in quella directory.
Diagnostica dei profili AppArmor
I log di AppArmor possono essere trovati nel diario di sistema, in /var/log/syslog e /var/log/kern.log (e /var/log/audit.log quando auditd è installato). Quello che devi cercare è il seguente:
-
AMMESSO (registrato quando un profilo in modalità reclamo viola le norme)
-
DENIED (registrato quando un profilo in modalità di applicazione blocca effettivamente un'operazione)
Il messaggio di registro completo dovrebbe fornire maggiori informazioni sull'esatto accesso negato. Puoi usarlo per modificare i profili prima di attivarli in modalità di applicazione.
Ad esempio,
$ grep -i -rn -E 'apparmor=.*denied|apparmor=.*allowed' /var/log/
/var/log/kern.log:503:Jun 18 18:54:09 ubuntu-bionic kernel: [ 664.680141] audit: type=1400 audit(1624042449.006:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/mysqld" pid=30349 comm="mysqld" capability=2 capname="dac_read_search"
Binary file /var/log/journal/877861ee473c4c03ac1512ed369dead1/system.journal matches
/var/log/syslog:1012:Jun 18 18:54:09 ubuntu-bionic kernel: [ 664.680141] audit: type=1400 audit(1624042449.006:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/mysqld" pid=30349 comm="mysqld" capability=2 capname="dac_read_search"Personalizzazione del profilo AppArmor
I profili preparati da Oracle MySQL non devono essere un modello valido per tutti. In tal caso, potresti decidere di modificare, ad esempio, la directory dei dati in cui si trovano i dati dell'istanza MySQL. Dopo aver applicato le modifiche al file di configurazione e aver riavviato le istanze MySQL, AppArmor negherà questa azione. Ad esempio,
$ egrep -i -rn 'apparmor=.*denied|apparmor=.*allowed' /var/log/
/var/log/kern.log:503:Jun 18 18:54:09 ubuntu-bionic kernel: [ 664.680141] audit: type=1400 audit(1624042449.006:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/mysqld" pid=30349 comm="mysqld" capability=2 capname="dac_read_search"
/var/log/kern.log:522:Jun 18 19:46:26 ubuntu-bionic kernel: [ 3801.151770] audit: type=1400 audit(1624045586.822:67): apparmor="DENIED" operation="mknod" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.sock.lock" pid=5262 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1002 ouid=1002
Binary file /var/log/journal/877861ee473c4c03ac1512ed369dead1/system.journal matches
/var/log/syslog:1012:Jun 18 18:54:09 ubuntu-bionic kernel: [ 664.680141] audit: type=1400 audit(1624042449.006:19): apparmor="DENIED" operation="capable" profile="/usr/sbin/mysqld" pid=30349 comm="mysqld" capability=2 capname="dac_read_search"
/var/log/syslog:1313:Jun 18 19:46:26 ubuntu-bionic kernel: [ 3801.151770] audit: type=1400 audit(1624045586.822:67): apparmor="DENIED" operation="mknod" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.sock.lock" pid=5262 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1002 ouid=1002Insieme all'errore che avevo in precedenza, ora aggiunge che avevo appena deciso di utilizzare la directory /mysql-data ma è stato negato.
Per applicare le modifiche, procediamo come segue. Modifica il file /etc/apparmor.d/usr.sbin.mysqld. Potresti trovare queste righe:
# Allow data dir access
/var/lib/mysql/ r,
/var/lib/mysql/** rwk,
Those flags such as r, rwk are the so-called access modes. These mean the following:
r - read
w - write -- conflicts with append
k - lock
La pagina man spiega questi flag in modo più dettagliato.
Ora, l'ho modificato come segue:
# Allow data dir access
/mysql-data/ r,
/mysql-data/** rwk,Poi ricarico i profili come segue:
$ apparmor_parser -r -T /etc/apparmor.d/usr.sbin.mysqldRiavvia il server MySQL:
$ systemctl restart mysql.serviceCosa succede se imposto mysqld in modalità reclamo?
Come accennato in precedenza, lo stato della modalità reclamo applicherà comunque le regole di rifiuto esplicite in un profilo. Anche se questo funziona per esempio:
$ aa-complain /usr/sbin/mysqldImpostazione di /usr/sbin/mysqld in modalità reclamo.
Allora,
$ aa-status
apparmor module is loaded.
56 profiles are loaded.
18 profiles are in enforce mode.
...
38 profiles are in complain mode.
...
1 processes have profiles defined.
0 processes are in enforce mode.
1 processes are in complain mode.
/usr/sbin/mysqld (23477)
0 processes are unconfined but have a profile defined.Dopo aver riavviato MySQL, verrà eseguito e mostrerà file di registro come:
/var/log/syslog:1356:Jun 18 19:58:51 ubuntu-bionic kernel: [ 4545.427074] audit: type=1400 audit(1624046331.098:83): apparmor="ALLOWED" operation="open" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.sock.lock" pid=5760 comm="mysqld" requested_mask="wrc" denied_mask="wrc" fsuid=1002 ouid=1002
/var/log/syslog:1357:Jun 18 19:58:51 ubuntu-bionic kernel: [ 4545.432077] audit: type=1400 audit(1624046331.102:84): apparmor="ALLOWED" operation="mknod" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.sock" pid=5760 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1002 ouid=1002
/var/log/syslog:1358:Jun 18 19:58:51 ubuntu-bionic kernel: [ 4545.432101] audit: type=1400 audit(1624046331.102:85): apparmor="ALLOWED" operation="mknod" profile="/usr/sbin/mysqld" name="/mysql-data/mysql.pid" pid=5760 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1002 ouid=1002
And it will work. However, it will probably have issues with networking as it still denies entries as what we have in /etc/apparmor.d/usr.sbin.mysqld. For example, my replica is not able to connect to the primary:
Last_IO_Error: error connecting to master '[email protected]:3306' - retry-time: 10 retries: 1 message: Host '192.168.40.247' is not allowed to connect to this MySQL server
Last_SQL_Errno: 0In tal caso, utilizzare l'applicazione e ricaricare il tuo profilo sarà un approccio semplice ed efficiente per gestire i tuoi profili MySQL con AppArmor.
