Utilisation de Security-Enhanced Linux pour ThingWorx Docker
Security-Enhanced Linux (SELinux) est un ensemble de modifications du noyau et d'outils d'espace utilisateur qui sont ajoutés à différentes distributions de Linux. L'architecture SELinux permet de séparer l'application des décisions de sécurité de la stratégie de sécurité, et de rationaliser le volume de logiciels impliqués dans l'application de la politique de sécurité. Les concepts clés qui sous-tendent SELinux sont attribuables à plusieurs projets passés menés par l'agence nationale de sécurité américaine (NSA).
Les utilisateurs et les rôles SELinux n'ont pas besoin d'être liés aux utilisateurs et aux rôles réels du système. Chaque utilisateur ou processus actif se voit attribuer par SELinux un contexte de trois chaînes, avec un nom d'utilisateur, un rôle et un domaine (ou type). Ce système est plus flexible que celui qui prévaut habituellement ; en règle générale, la plupart des utilisateurs réels partagent le même nom d'utilisateur SELinux, et tous les contrôles d'accès sont gérés via le troisième tag, le domaine. Vous devez configurer les circonstances dans lesquelles autoriser un processus pour un certain domaine dans les stratégies. Bien que vous puissiez utiliser la commande runcon pour démarrer un processus dans un contexte explicitement spécifié (utilisateur, rôle et domaine), SELinux peut refuser la transition s'il n'est pas approuvé par la stratégie.
Les fichiers, les ports réseau et d'autres matériels possèdent également un contexte SELinux qui inclut un nom, un rôle (rarement utilisé) et un type. Dans le cas des systèmes de fichiers, le mappage entre les fichiers et les contextes de sécurité est appelé étiquetage. L'étiquetage est défini dans les fichiers de stratégie, mais vous pouvez également l'ajuster manuellement sans modifier les stratégies. Les types de matériel sont également détaillés ; par exemple, bin_t (tous les fichiers du dossier /bin) ou postgresql_port_t (port PostgreSQL, 5432). Vous pouvez spécifier explicitement le contexte SELinux d'un système de fichiers distant au moment du montage.
SELinux ajoute le commutateur -Z aux commandes du shell ls, ps ainsi qu'à diverses autres, ce qui permet l'identification du contexte de sécurité des fichiers ou du processus.
En règle générale, les règles des stratégies sont composées d'autorisations explicites, telles que la déclaration des domaines que l'utilisateur doit posséder pour pouvoir effectuer certaines actions en interaction avec la cible donnée, par exemple, des actions de lecture, d'exécution ou encore, dans le cas d'un port de réseau, de liaison ou de connexion. Des mappages plus complexes impliquant des rôles et des niveaux de sécurité sont également possibles.
Une stratégie type consiste en un fichier de mappage (d'étiquetage), un fichier de règles et un fichier d'interface définissant la transition de domaine. Ces trois fichiers doivent être compilés avec les outils SELinux pour produire un seul et unique fichier de stratégie. Le fichier de stratégie résultant peut être chargé dans le noyau, ce qui l'active. Les règles de chargement et de déchargement ne nécessitent pas de redémarrage. Les fichiers de stratégie sont développés manuellement ou peuvent aussi être générés de manière plus conviviale à partir de l'outil de gestion de SELinux. Ces fichiers sont généralement testés en mode permissif en premier lieu, où les violations sont consignées mais autorisées. Vous pouvez ultérieurement utiliser l'outil audit2allow pour créer des règles supplémentaires qui étendent la stratégie afin d'autoriser toutes les activités légitimes de l'application confinée.
Problèmes courants avec SELinux
Le problème le plus courant avec SELinux est le refus d'autorisation, indiquant que SELinux ne fonctionne pas. Un message d'erreur de refus d'autorisation s'affiche lorsque vous tentez d'accéder à un objet système qui n'est pas associé au programme ou aux informations d'identification utilisateur que vous utilisez pour accéder à l'objet. Ces erreurs sont difficiles à résoudre. Il existe cependant des outils qui peuvent vous aider à les corriger.
Installation de Setools et de Setroubleshoot
Pour installer ces outils sur votre système, procédez comme suit :
1. Connectez-vous à votre serveur ou bureau à l'aide d'un compte disposant de droits d'administration.
2. Ouvrez une commande shell.
3. Installez les packages setroubleshoot avec Yum :
yum install setroubleshoot setools
Alertes SELinux
Utilisez l'outil sealert pour analyser le journal d'audit utilisé par SELinux. Cet outil analyse le fichier journal et le rapport, puis génère un rapport répertoriant tous les problèmes SELinux détectés.
Pour exécuter sealert depuis la ligne de commande, pointez-la vers le journal d'audit de SELinux. Par exemple :
sealert -a /var/log/audit/audit.log
Un rapport décrit chaque problème et explique comment le résoudre. Voici un exemple tronqué de la sortie générée par 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
Les informations les plus importantes du rapport qui expliquent comment résoudre le problème figurent à la suite de chaque alerte. Par exemple, le rapport ci-dessus propose la solution suivante :
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 solution suggère la création d'une stratégie SELinux à appliquer au fichier problématique. Dans cet exemple, un fichier HTML s'est vu attribuer un contexte de fichier SELinux incorrect.
D'autres exemples de problèmes potentiels avec les conteneurs ThingWorx Docker sont évoqués ci-dessous.
L'exemple suivant illustre un problème lié à PostgreSQL. Dans ce cas, sealert génère l'alerte suivante :
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
Ce rapport suggère la solution suivante :
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'
Voici la commande qu'il vous faudrait exécuter pour implémenter cette solution :
semanage fcontext -a -t svirt_sandbox_file_t "/opt/postgresql-storage(/.*)?" restorecon -R /opt/postgresql-storage
Notez que la solution suggérée consiste à appliquer les autorisations uniquement au dossier de données pour PostgreSQL. Toutefois, étant donné que vous avez besoin d'un accès en écriture pour l'espace de table ThingWorx, vous devez accorder les mêmes autorisations à tous les éléments de ce dossier.
L'exemple suivant illustre un problème lié à la plateforme ThingWorx. Dans ce cas, sealert génère l'alerte suivante :
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
Ce rapport suggère la solution suivante :
# 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'
Voici la commande qu'il vous faudrait exécuter pour implémenter cette solution :
semanage fcontext -a -t svirt_sandbox_file_t "/opt/thingworx-storage(/.*)?"
restorecon -R /opt/thingworx-storage