Utilizzo di Security-Enhanced Linux per il Docker di ThingWorx
Security-Enhanced Linux (SELinux) è un insieme di modifiche kernel e strumenti dello spazio utente aggiunti a varie distribuzioni Linux. L'architettura SELinux consente la separazione dell'applicazione delle decisioni di sicurezza dalle regole di sicurezza e riduce la quantità di software coinvolto nell'applicazione delle regole di sicurezza. I concetti chiave su cui si basa SELinux possono essere ricondotti a diversi progetti precedentemente sviluppati dalla NSA (National Security Agency) degli Stati Uniti.
Non è necessario correlare gli utenti e i ruoli di SELinux agli utenti e ai ruoli del sistema effettivo. Per ogni utente o processo corrente, SELinux assegna un contesto a tre stringhe che include un nome utente, un ruolo e un dominio (o tipo). Questo sistema è più flessibile di quanto venga normalmente richiesto; di norma, la maggior parte degli utenti reali condivide lo stesso nome utente SELinux e tutto il processo di controllo degli accessi viene gestito tramite il terzo tag, ovvero il dominio. È necessario configurare nelle regole le circostanze in cui consentire un processo in un determinato dominio. Sebbene sia possibile utilizzare il comando runcon per avviare un processo in un contesto specificato in modo esplicito (utente, ruolo e dominio), SELinux può negare la transizione se questa non è approvata dalla regola.
I file, le porte di rete e altri componenti hardware hanno anche un contesto SELinux che include un nome, un ruolo (raramente utilizzato) e un tipo. Nel caso dei file system, la mappatura tra i file e i contesti di protezione viene definita etichettatura. L'etichettatura è definita nei file di regole, ma è anche possibile regolarla manualmente senza modificare le regole. Sono forniti dettagli anche sui tipi di componenti hardware, ad esempio bin_t (tutti i file della cartella /bin) o postgresql_port_t (porta PostgreSQL, 5432). In fase di montaggio è possibile specificare il contesto SELinux per un file system remoto in modo esplicito.
SELinux aggiunge lo switch -Z ai comandi della shell ls, ps e alcuni altri, consentendo la visualizzazione del contesto di protezione dei file o del processo.
In genere, le regole sono costituite da permessi espliciti, ad esempio i domini che l'utente deve possedere per poter eseguire determinate azioni con la destinazione specificata. Esempi di queste azioni sono read, execute e, nel caso della porta di rete, bind o connect. Sono inoltre possibili mappature più complesse che coinvolgono ruoli e livelli di protezione.
Una tipica regola consiste in un file di mappatura (etichettatura), in un file di regole e in un file di interfaccia che definisce la transizione del dominio. Questi tre file devono essere compilati con gli strumenti SELinux per produrre un singolo file di regole. Il file di regole risultante può essere caricato nel kernel, in modo da renderlo attivo. Il caricamento e lo scaricamento delle regole non richiedono un riavvio. I file di regole vengono sviluppati manualmente o possono essere generati dallo strumento di gestione SELinux più facile da usare. Questi file vengono in genere testati in modalità permissiva, dove le violazioni sono registrate ma sono consentite. È possibile utilizzare lo strumento audit2allow in un secondo momento per produrre regole aggiuntive che estendono la regola con cui consentire il confinamento di tutte le attività legittime dell'applicazione.
Problemi comuni di SELinux
Il problema più comune quando si utilizza SELinux è che il permesso viene negato; questo indica che SELinux non sta funzionando. I messaggi di errore di permesso negato vengono visualizzati quando si tenta di accedere a un oggetto di sistema non associato alle credenziali del programma o dell'utente utilizzate per accedere a tale oggetto. Risolvere questo tipo di errori è piuttosto complesso, tuttavia esistono strumenti che possono essere utili a tale scopo.
Installazione di Setools e Setroubleshoot
Per installare questi strumenti nel sistema:
1. Accedere al server o al desktop utilizzando un account a cui sono stati concessi diritti amministrativi.
2. Aprire una shell dei comandi.
3. Installare i pacchetti setroubleshoot utilizzando Yum:
yum install setroubleshoot setools
Avvisi di SELinux
Utilizzare lo strumento sealert per analizzare il log verifiche utilizzato da SELinux. Questo strumento analizza il file di log e il report, quindi genera un report contenente tutti i problemi SELinux individuati.
Per eseguire sealert dalla riga di comando, puntarlo al log verifiche di SELinux. Vedere l'esempio seguente:
sealert -a /var/log/audit/audit.log
Un report descrive ogni problema e spiega come risolverlo. Di seguito è riportato un esempio abbreviato dell'output generato da sealert:
100% done found 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------
SELinux is preventing /usr/sbin/httpd from getattr access on the file
/myapps/app1/html/index.html.
***** Plugin catchall_labels (83.8 confidence) suggests ********************
If you want to allow httpd to have getattr access on the index.html file
Then you need to change the label on /myapps/app1/html/index.html
Do
# semanage fcontext -a -t FILE_TYPE '/myapps/app1/html/index.html'
where FILE_TYPE is one of the following: sssd_var_lib_t, public_content_t, anon_inodefs_t,
[..truncated..]
httpd_sys_ra_content_t, httpd_sys_rw_content_t, httpd_sys_rw_content_t,
httpd_w3c_validator_content_t.
Then execute:
restorecon -v '/myapps/app1/html/index.html'
***** Plugin catchall (17.1 confidence) suggests ***************************
If you believe that httpd should be allowed getattr access on the index.html 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:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
La parte più importante del report che spiega come risolvere il problema viene visualizzata alla fine di ogni avviso. Ad esempio, il report precedente mostra la soluzione seguente:
If you believe that httpd should be allowed getattr access on the index.html 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:
# grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
La soluzione proposta crea una regola SELinux da applicare al file problematico. In questo esempio, a un file HTML è stato assegnato il contesto del file SELinux errato.
Di seguito sono riportati altri esempi di potenziali problemi relativi ai contenitori Docker di ThingWorx.
In questo esempio viene illustrato un problema relativo a PostgreSQL. In questo caso, sealert produce l'avviso seguente:
found 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------
SELinux is preventing /bin/chown from setattr access on the directory data.
***** Plugin catchall_labels (83.8 confidence) suggests *******************
If you want to allow chown to have setattr access on the data directory
Then you need to change the label on data
Do
# semanage fcontext -a -t FILE_TYPE 'data'
where FILE_TYPE is one of the following: cgroup_t, nfs_t, svirt_home_t,
svirt_sandbox_file_t.
Then execute:
restorecon -v 'data'
***** Plugin catchall (17.1 confidence) suggests **************************
If you believe that chown should be allowed setattr access on the data directory 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 'chown' --raw | audit2allow -M my-chown
# semodule -i my-chown.pp
Additional Information:
Source Context system_u:system_r:svirt_lxc_net_t:s0:c459,c1008
Target Context unconfined_u:object_r:usr_t:s0
Target Objects data [ dir ]
Source chown
Source Path /bin/chown
Port <Unknown>
Host <Unknown>
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.13.1-166.el7_4.9.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name ip-10-99-0-109.ec2.internal
Platform Linux ip-10-99-0-109.ec2.internal
3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20
20:32:50 UTC 2017 x86_64 x86_64
Alert Count 9
First Seen 2018-04-02 17:08:08 UTC
Last Seen 2018-04-02 17:08:27 UTC
Local ID 65bb52e5-bde9-4ec5-ba44-f0752ffef319
Raw Audit Messages
type=AVC msg=audit(1522688907.927:619): avc: denied { setattr } for pid=12142
comm="initdb" name="data" dev="nvme0n1p1" ino=826278009 scontext=system_u:system_r:
svirt_lxc_net_t:s0:c459,c1008 tcontext=unconfined_u:object_r:usr_t:s0 tclass=dir
type=SYSCALL msg=audit(1522688907.927:619): arch=x86_64 syscall=chmod success=no
exit=EACCES a0=5633eefb7310 a1=1c0 a2=0 a3=7f3c78d1d6a0 items=0 ppid=12116 pid=12142
auid=4294967295 uid=1001 gid=0 euid=1001 suid=1001 fsuid=1001 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm=initdb exe=/usr/lib/postgresql/9.4/bin/initdb
subj=system_u:system_r:svirt_lxc_net_t:s0:c459,c1008 key=(null)
Hash: chown,svirt_lxc_net_t,usr_t,dir,setattr
Questo report mostra la seguente soluzione suggerita:
If you want to allow chown to have setattr access on the data directory
Then you need to change the label on data
Do
# semanage fcontext -a -t FILE_TYPE 'data'
where FILE_TYPE is one of the following: cgroup_t, nfs_t, svirt_home_t,
svirt_sandbox_file_t.
Then execute:
restorecon -v 'data'
Di seguito è riportato il comando immesso per implementare la soluzione:
semanage fcontext -a -t svirt_sandbox_file_t "/opt/postgresql-storage(/.*)?" restorecon -R /opt/postgresql-storage
Si noti che la soluzione suggerita è quella di applicare i permessi solo alla cartella dati di PostgreSQL. Tuttavia, poiché è necessario disporre dell'accesso in scrittura per lo spazio tabelle di ThingWorx, occorre concedere gli stessi permessi a tutti gli elementi della cartella.
In questo esempio viene illustrato un problema relativo alla piattaforma ThingWorx. In questo caso, sealert produce l'avviso seguente:
found 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------
SELinux is preventing /bin/mv from write access on the directory ThingworxStorage.
***** Plugin catchall_labels (83.8 confidence) suggests *******************
If you want to allow mv to have write access on the ThingworxStorage directory
Then you need to change the label on ThingworxStorage
Do
# semanage fcontext -a -t FILE_TYPE 'ThingworxStorage'
where FILE_TYPE is one of the following: cgroup_t, container_var_lib_t, nfs_t,
svirt_home_t, svirt_sandbox_file_t, tmpfs_t, virt_home_t.
Then execute:
restorecon -v 'ThingworxStorage'
***** Plugin catchall (17.1 confidence) suggests **************************
If you believe that mv should be allowed write access on the ThingworxStorage
directory 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 'mv' --raw | audit2allow -M my-mv
# semodule -i my-mv.pp
Additional Information:
Source Context system_u:system_r:svirt_lxc_net_t:s0:c320,c876
Target Context unconfined_u:object_r:usr_t:s0
Target Objects ThingworxStorage [ dir ]
Source mv
Source Path /bin/mv
Port <Unknown>
Host <Unknown>
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.13.1-166.el7_4.9.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name ip-10-99-0-109.ec2.internal
Platform Linux ip-10-99-0-109.ec2.internal
3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20
20:32:50 UTC 2017 x86_64 x86_64
Alert Count 13
First Seen 2018-04-02 17:13:18 UTC
Last Seen 2018-04-02 17:13:23 UTC
Local ID 1759a007-f347-4d80-99e8-ee414eae7602
Raw Audit Messages
type=AVC msg=audit(1522689203.86:708): avc: denied { write } forpid=14905
comm="java" name="ThingworxStorage" dev="nvme0n1p1" ino=864027929
scontext=system_u:system_r:svirt_lxc_net_t:s0:c320,c876
tcontext=unconfined_u:object_r:usr_t:s0 tclass=dir
type=SYSCALL msg=audit(1522689203.86:708): arch=x86_64 syscall=mkdir success=no
exit=EACCES a0=7f6480f76e80 a1=1ff a2=7f6480f76e80 a3=b items=0 ppid=14734
pid=14905 auid=4294967295 uid=1337 gid=1337 euid=1337 suid=1337 fsuid=1337
egid=1337 sgid=1337 fsgid=1337 tty=(none) ses=4294967295 comm=java exe=/opt/
jdk1.8.0_121/bin/java subj=system_u:system_r:svirt_lxc_net_t:s0:c320,c876 key=(null)
Hash: mv,svirt_lxc_net_t,usr_t,dir,write
Questo report mostra la seguente soluzione suggerita:
# semanage fcontext -a -t FILE_TYPE 'ThingworxStorage'
where FILE_TYPE is one of the following: cgroup_t, container_var_lib_t, nfs_t,
svirt_home_t, svirt_sandbox_file_t, tmpfs_t, virt_home_t.
Then execute:
restorecon -v 'ThingworxStorage'
Di seguito è riportato il comando utilizzato per implementare questa soluzione:
semanage fcontext -a -t svirt_sandbox_file_t "/opt/thingworx-storage(/.*)?"
restorecon -R /opt/thingworx-storage