Security Enhanced Linux (SELinux) è un framework di sicurezza che consente e nega l'accesso ad applicazioni, file, ecc. all'interno di un sistema Linux. Per una panoramica completa di SELinux, vedere Cos'è SELinux.
Per questo articolo, esamineremo cosa succede quando viene negato l'accesso a un file o un'applicazione desiderati. Quali messaggi vedrai, dove sono archiviati questi messaggi e cosa significano effettivamente le informazioni? Quali sono alcune delle situazioni anormali, causate da falsi positivi e negazioni di fantasmi, in cui potresti trovarti? Esploreremo tutto questo qui.
Cos'è un rifiuto?
Una negazione è l'evento generato ogni volta che a un servizio, applicazione, file, ecc. viene negato l'accesso dal sistema SELinux. Quando ciò accade, il rifiuto viene memorizzato nella cache in Access Vector Cache (AVC). A volte vedrai un messaggio di rifiuto denominato Rifiuto AVC .
Dove vengono registrati i rifiuti?
Ora, questi rifiuti AVC, proprio come tutto il resto in Linux, vengono registrati dal sistema. La posizione in cui vengono registrati questi messaggi varia a seconda dei demoni di sistema in esecuzione.
- audit su - /var/log/audit/audit.log
- verifica; rsyslogd su - /var/log/messages
- setroubleshootd, rsyslogd e auditd su - Entrambe le posizioni, sebbene i messaggi in /var/log/messages siano più facili da capire
Come sarà un rifiuto?
A volte vedrai un avviso di rifiuto sul desktop. Quando selezioni mostra , questo avviso ti fornirà dettagli su cosa è andato storto e talvolta anche una soluzione per risolvere il problema.
Un'altra cosa che puoi fare è eseguire i seguenti comandi per estrarre i messaggi di rifiuto:
[root@server ~]# grep "SELinux is preventing" /var/log/messages Qui l'output è in un linguaggio più accessibile e, se leggi attentamente, viene presentata una soluzione:
Sep 22 13:35:24 server setroubleshoot[3999]: SELinux is preventing rhsmcertd-worke from read access on the file virt.module. For complete SELinux messages run: sealert -l 97a1c0df-81ed-4c08-ba27-41c5067b713b
Sep 22 13:35:24 server platform-python[3999]: SELinux is preventing rhsmcertd-worke from read access on the file virt.module.#012#012***** Plugin catchall_boolean (89.3 confidence) suggests ******************#012#012If you want to allow daemons to dump core#012Then you must tell SELinux about this by enabling the 'daemons_dump_core' boolean.#012#012Do#012setsebool -P daemons_dump_core 1#012#012***** Plugin catchall (11.6 confidence) suggests **************************#012#012If you believe that rhsmcertd-worke should be allowed read access on the virt.module file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'rhsmcertd-worke' --raw | audit2allow -M my-rhsmcertdworke#012# semodule -X 300 -i my-rhsmcertdworke.pp#012 Questo output è effettivamente molto utile, poiché la prima voce sopra ci fornisce quanto segue:
For complete SELinux messages run: sealert -l 97a1c0df-81ed-4c08-ba27-41c5067b713b Se esegui il comando suggerito, ti viene fornito un riepilogo molto dettagliato ma semplice di cosa è successo e cosa puoi fare per rimediare al problema. Visto sotto:
[root@server ~]# sealert -l 97a1c0df-81ed-4c08-ba27-41c5067b713b
SELinux is preventing rhsmcertd-worke from read access on the file virt.module.
***** Plugin catchall_boolean (89.3 confidence) suggests ******************
If you want to allow daemons to dump core
Then you must tell SELinux about this by enabling the 'daemons_dump_core' boolean.
Do
setsebool -P daemons_dump_core 1
***** Plugin catchall (11.6 confidence) suggests **************************
If you believe that rhsmcertd-worke should be allowed read access on the virt.module file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'rhsmcertd-worke' --raw | audit2allow -M my-rhsmcertdworke
# semodule -X 300 -i my-rhsmcertdworke.pp
Additional Information:
Source Context system_u:system_r:rhsmcertd_t:s0
Target Context system_u:object_r:root_t:s0
Target Objects virt.module [ file ]
Source rhsmcertd-worke
Source Path rhsmcertd-worke
Port <Unknown>
Host server.example.com
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.14.3-41.el8_2.5.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name server.example.com
Platform Linux server.example.com
4.18.0-193.13.2.el8_2.x86_64 #1 SMP Mon Jul 13
23:17:28 UTC 2020 x86_64 x86_64
Alert Count 265
First Seen 2020-06-24 13:55:40 EDT
Last Seen 2020-09-22 13:35:09 EDT
Local ID 97a1c0df-81ed-4c08-ba27-41c5067b713b
Raw Audit Messages
type=AVC msg=audit(1600796109.687:168): avc: denied { read } for pid=3912 comm="rhsmcertd-worke" name="virt.module" dev="dm-0" ino=50331783 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0
Hash: rhsmcertd-worke,rhsmcertd_t,root_t,file,read [ I lettori hanno apprezzato anche: Accesso alla documentazione delle norme di SELinux ]
Puoi anche utilizzare il comando seguente per i messaggi di controllo non elaborati, sebbene siano significativamente meno utili (e sono inclusi nel sealert uscita).
[root@server ~]# grep "denied"/var/log/audit/audit.log Qui il linguaggio è meno intuitivo e non ci sono passaggi suggeriti da eseguire.
type=AVC msg=audit(1600796109.687:168): avc: denied { read } for pid=3912 comm="rhsmcertd-worke" name="virt.module" dev="dm-0" ino=50331783 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0 Rifiuto dei fantasmi
In occasioni speciali (speciali , come nella loro capacità di generare frustrazione), SELinux AVC può negare un servizio senza avvisare l'utente che si è verificato il rifiuto. Quando ciò accade, è necessario un piccolo scavo forense. Di recente, il mio collega e scrittore straordinario, Ken Hess, ha installato un sistema di gestione dei documenti su una macchina virtuale CentOS. Durante questa installazione, il DMS non è stato installato senza alcuna spiegazione. Dopo un lungo e frustrante processo di risoluzione dei problemi, Ken ha scoperto che c'erano ripetuti messaggi di rifiuto in /var/log/audit/audit.log .
type=AVC msg=audit(1602171971.334:438): avc: denied { write } for pid=12398 comm="httpd" name="31b32f0dfa1f50d778065b767582bb9b.js" dev="dm-0" ino=553885 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file permissive=0
Dopo un'ulteriore ispezione di /var/log/messages , ha trovato quanto segue:
Oct 8 12:33:17 dms python: SELinux is preventing /usr/sbin/httpd from name_connect access on the tcp_socket port 25.#012#012***** Plugin catchall_boolean (32.5 confidence) suggests ******************#012#012If you want to allow httpd to can network connect#012Then you must tell SELinux about this by enabling the 'httpd_can_network_connect' boolean.#012#012Do#012setsebool -P httpd_can_network_connect 1#012#012***** Plugin catchall_boolean (32.5 confidence) suggests ******************#012#012If you want to allow httpd to can sendmail#012Then you must tell SELinux about this by enabling the 'httpd_can_sendmail' boolean.#012#012Do#012setsebool -P httpd_can_sendmail 1#012#012***** Plugin catchall_boolean (32.5 confidence) suggests ******************#012#012If you want to allow nis to enabled#012Then you must tell SELinux about this by enabling the 'nis_enabled' boolean.#012#012Do#012setsebool -P nis_enabled 1#012#012***** Plugin catchall (4.5 confidence) suggests ***************************#012#012If you believe that httpd should be allowed name_connect access on the port 25 tcp_socket by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'httpd' --raw | audit2allow -M my-httpd#012# semodule -i my-httpd.pp#012 Oct 8 12:33:20 dms setroubleshoot: SELinux is preventing /usr/sbin/httpd from name_connect access on the tcp_socket port 25. For complete SELinux messages run: sealert -l ce75fc38-5696-4b21-b099-7780db5960f3 Finalmente qualcosa di utile. Quindi ha eseguito questo comando:
# sealert -l ce75fc38-5696-4b21-b099-7780db5960f3 Che ha fornito queste informazioni:
[user@host ~] # SELinux is preventing /usr/sbin/httpd from name_connect access on the tcp_socket port 25. ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow httpd to can network connect Then you must tell SELinux about this by enabling the 'httpd_can_network_connect' boolean. Do setsebool -P httpd_can_network_connect 1 ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow httpd to can sendmail Then you must tell SELinux about this by enabling the 'httpd_can_sendmail' boolean. Do setsebool -P httpd_can_sendmail 1 ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow nis to enabled Then you must tell SELinux about this by enabling the 'nis_enabled' boolean. Do setsebool -P nis_enabled 1 ***** Plugin catchall (4.5 confidence) suggests *************************** If you believe that httpd should be allowed name_connect access on the port 25 tcp_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'httpd' --raw | audit2allow -M my-httpd # semodule -i my-httpd.pp Additional Information:
Additional Information: [root@dms dms]# more sealert.txt SELinux is preventing /usr/sbin/httpd from name_connect access on the tcp_socket port 25. ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow httpd to can network connect Then you must tell SELinux about this by enabling the 'httpd_can_network_connect' boolean. Do setsebool -P httpd_can_network_connect 1 ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow httpd to can sendmail Then you must tell SELinux about this by enabling the 'httpd_can_sendmail' boolean. Do setsebool -P httpd_can_sendmail 1 ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow nis to enabled Then you must tell SELinux about this by enabling the 'nis_enabled' boolean. Do setsebool -P nis_enabled 1 ***** Plugin catchall (4.5 confidence) suggests *************************** If you believe that httpd should be allowed name_connect access on the port 25 tcp_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'httpd' --raw | audit2allow -M my-httpd # semodule -i my-httpd.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:smtp_port_t:s0 Target Objects port 25 [ tcp_socket ] Source httpd Source Path /usr/sbin/httpd Port 25 Host dms Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-252.el7.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name dms Platform Linux dms 3.10.0-1062.el7.x86_64 #1 SMP Wed Aug 7 18:08:02 UTC 2019 x86_64 x86_64 Alert Count 2 First Seen 2020-10-08 12:33:15 CDT Last Seen 2020-10-08 12:33:15 CDT Local ID ce75fc38-5696-4b21-b099-7780db5960f3 Raw Audit Messages type=AVC msg=audit(1602178395.253:461): avc: denied { name_connect } for pid=12565 comm="httpd" dest=25 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:smtp_port_t :s0 tclass=tcp_socket permissive=1 Hash: httpd,httpd_t,smtp_port_t,tcp_socket,name_connect Quando ho chiesto a Ken di valutare la sua esperienza, ha detto quanto segue:
È difficile sapere quando un errore, o la mancanza di un errore, è causato da SELinux. Dopo aver verificato le eccezioni del firewall, le autorizzazioni del filesystem e i prerequisiti dell'applicazione, il passaggio successivo consiste nel verificare i problemi di contesto di SELinux. Il rimedio più comune è disabilitare SELinux mettendolo in modalità Permissiva, il che non è una buona idea perché così facendo il tuo sistema è vulnerabile. Il metodo migliore è controllare i file /var/log/messages e /var/log/audit/audit.log per i rifiuti di SELinux e lavorare da lì per rimediare individualmente ai rifiuti finché l'applicazione non funziona. SELinux deve rimanere in modalità Enforcing per farlo.
L'elenco per la risoluzione dei problemi è simile al seguente durante la configurazione di una nuova applicazione:
1. Controlla le eccezioni del firewall per le porte della tua applicazione.
2. Verifica le autorizzazioni del filesystem per assicurarti che il tuo account di servizio disponga delle autorizzazioni corrette per leggere, scrivere ed eseguire ove necessario.
3. Verifica i prerequisiti e le dipendenze della tua applicazione.
4. Controllare i file /var/log/messages e /var/log/audit/audit.log per i rifiuti di SELinux.
La modalità permissiva di SELinux può essere utilizzata brevemente per verificare se SELinux è il colpevole nell'impedire il funzionamento dell'applicazione. Dopo aver determinato che è il problema, riportalo alla modalità di applicazione e inizia a modificare i contesti rilevanti. Vedi queste informazioni per i contesti SELinux.
[ Migliora le tue capacità di gestione e utilizzo di SELinux con questa utile guida. ]
Concludi
SELinux è un framework di sicurezza efficace che può essere incredibilmente utile se implementato correttamente. Come con qualsiasi buon sistema di sicurezza, nel tempo avrai smentite. Sapere cosa fare con le informazioni a tua disposizione è fondamentale per risolvere eventuali problemi che potrebbero essere presenti o per consentire processi legittimi attraverso il sistema. Ora sai dove sono conservati i log e come interpretarli al meglio. In futuro, sarai in grado di rispondere a qualsiasi avviso SELinux segnalato sul tuo sistema.