Uso de Security-Enhanced Linux para Docker de ThingWorx
Security-Enhanced Linux (SELinux) es un conjunto de modificaciones de kernel y herramientas de espacio de usuario que se añaden a distintas distribuciones de Linux. La arquitectura de SELinux permite la separación de la aplicación de decisiones de seguridad de la directiva de seguridad y racionaliza la cantidad de software implicado en la aplicación de la directiva de seguridad. Los conceptos clave subyacentes de SELinux se pueden encontrar en varios proyectos anteriores de la Agencia Nacional de Seguridad (NSA) de los Estados Unidos.
Los usuarios y los roles de SELinux no tienen que estar relacionados con los usuarios ni los roles reales del sistema. Para cada usuario o proceso actual, SELinux asigna un contexto de tres cadenas en el que se incluyen un nombre de usuario, un rol y un dominio (o tipo). Este sistema es más flexible de lo que suele necesitarse. Como regla general, la mayoría de los usuarios reales comparten el mismo nombre de usuario de SELinux y todo el control de acceso se gestiona a través de la tercera etiqueta, el dominio. Las circunstancias se deben configurar para permitir un proceso en un dominio determinado en las directivas. Aunque se puede utilizar el comando runcon para iniciar un proceso en un contexto especificado explícitamente (usuario, rol y dominio), SELinux puede denegar la transición si no está aprobada por la directiva.
Los ficheros, los puertos de red y otro hardware también tienen un contexto de SELinux que incluye un nombre, un rol (que rara vez se utiliza) y un tipo. En el caso de los sistemas de ficheros, la asignación entre ficheros y los contextos de seguridad se conoce como "etiquetado". El etiquetado se define en ficheros de directivas, pero también se puede ajustar manualmente sin cambiar las directivas. También se detallan los tipos de hardware, por ejemplo, bin_t (todos los ficheros de la carpeta /bin) o postgresql_port_t (puerto PostgreSQL, 5432). Se puede especificar explícitamente el contexto de SELinux para un sistema de ficheros remoto en el momento del montaje.
SELinux añade el conmutador -Z a los comandos de shell ls, ps y otros, lo que permite ver el contexto de seguridad de los ficheros o proceso.
Normalmente, las reglas de directiva constan de permisos explícitos, como los dominios que el usuario debe poseer para poder realizar determinadas acciones con el destino especificado. Algunos ejemplos de estas acciones son leer, ejecutar y, en el caso del puerto de red, enlazar o conectar. También son posibles asignaciones más complejas que implican roles y niveles de seguridad.
Una directiva típica consta de un fichero de asignación (etiquetado), un fichero de reglas y un fichero de interfaz que definen la transición del dominio. Estos tres ficheros se deben compilar con las herramientas de SELinux para producir un único fichero de directivas. El fichero de directivas resultante se puede cargar en el kernel, lo que hace que esté activo. Para cargar y descargar directivas no es necesario volver a arrancar el sistema. Los ficheros de directivas se desarrollan manualmente o se pueden generar desde la herramienta de administración de SELinux que es más fácil de usar. Normalmente, estos ficheros se prueban en el modo tolerante, donde las infracciones se registran, pero se permiten. Posteriormente, se puede utilizar la herramienta audit2allow para producir reglas adicionales que extiendan la directiva para permitir confinar todas las actividades legítimas de la aplicación.
Incidencias comunes de SELinux
La incidencia más común de SELinux es la denegación del permiso, lo que indica que SELinux no funciona. Los mensajes de error de permiso denegado aparecen cuando se intenta acceder a un objeto del sistema que no está asociado al programa o a las credenciales de usuario que se utilizan para acceder a ese objeto. Estos errores son difíciles de resolver. Sin embargo, hay herramientas que pueden ayudar a solucionar problemas.
Instalación de Setools y Setroubleshoot
Para instalar estas herramientas en el sistema:
1. Inicie sesión en el servidor o en el escritorio mediante una cuenta con derechos administrativos concedidos.
2. Abra un shell de comandos.
3. Instale los paquetes setroubleshoot con Yum:
yum install setroubleshoot setools
Alertas de SELinux
Utilice la herramienta sealert para analizar el registro de auditoría que SELinux utiliza. Esta herramienta escanea el fichero de registro y el informe y, a continuación, genera un informe con todas las incidencias de SELinux detectadas.
Para ejecutar sealert desde la línea de comandos, haga que apunte al registro de auditoría de SELinux. Consulte el siguiente ejemplo:
sealert -a /var/log/audit/audit.log
En un informe se describe cada problema y se explica cómo resolverlo. A continuación, se muestra un ejemplo truncado de la salida generada por 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 más importante del informe en la que se explica cómo resolver el problema aparece al final de cada alerta. Por ejemplo, en el informe anterior se muestra la siguiente solución:
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 solución propuesta crea una directiva de SELinux que se aplicará al fichero problemático. En este ejemplo, se ha asignado un contexto de fichero SELinux incorrecto a un fichero HTML.
A continuación, se ofrecen más ejemplos de incidencias potenciales en los contenedores Docker de ThingWorx.
En este ejemplo, se muestra un problema con PostgreSQL. En este caso, sealert genera la siguiente alerta:
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
En este informe, se muestra la siguiente solución sugerida:
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'
A continuación, se indica el comando que se debe introducir para implementar esta solución:
semanage fcontext -a -t svirt_sandbox_file_t "/opt/postgresql-storage(/.*)?" restorecon -R /opt/postgresql-storage
Se debe tener en cuenta que la solución sugerida era aplicar los permisos solo a la carpeta de datos de PostgreSQL. Sin embargo, puesto que se necesita permiso de escritura para el espacio de tabla de ThingWorx, se deben conceder los mismos permisos a todo lo que se incluye en la carpeta.
En este ejemplo, se ilustra una incidencia con la plataforma de ThingWorx. En este caso, sealert genera la siguiente alerta:
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
En este informe, se muestra la siguiente solución sugerida:
# 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'
A continuación, se indica el comando que se utiliza para implementar esta solución:
semanage fcontext -a -t svirt_sandbox_file_t "/opt/thingworx-storage(/.*)?"
restorecon -R /opt/thingworx-storage