linux-system-roles.selinux

SELinux

Fonctionnalité attendue

Fournir essentiellement des mécanismes pour gérer des personnalisations locales :

Définitif/permissif
Restaurer certaines parties de l'arborescence du système de fichiers
Définir/obtenir des booléens
Définir/obtenir des contextes de fichiers
Gérer les connexions
Gérer les ports

Remarque : Si vous souhaitez gérer les personnalisations de SELinux en mode désactivé, vous devez avoir le plan de gestion targeted de SELinux installé.

Exigences

Voir ci-dessous

Exigences de la collection

Le rôle nécessite des collections externes. Utilisez la commande suivante pour les installer :

ansible-galaxy collection install -vv -r meta/collection-requirements.yml

Modules fournis par ce dépôt

selinux_modules_facts

Collecte l'état des modules SELinux

Variables de rôle

Purge des modifications locales

Par défaut, les modifications spécifiées dans selinux_booleans, selinux_fcontexts, selinux_ports et selinux_logins sont appliquées en plus des modifications préexistantes. Pour purger les modifications locales avant de définir de nouvelles, définissez les variables suivantes sur true :

selinux_booleans_purge - Booleans SELinux
selinux_fcontexts_purge - Contextes de fichiers SELinux
selinux_ports_purge - Ports SELinux
selinux_logins_purge - Mappage des utilisateurs SELinux

Vous pouvez purger toutes les modifications en utilisant selinux_all_purge: true :

selinux_all_purge: true

selinux_policy, selinux_state

Gérer le type et le mode de la politique SELinux.

selinux_policy: targeted
selinux_state: enforcing

Les valeurs autorisées pour selinux_state sont disabled, enforcing et permissive.

Si selinux_state n'est pas défini, l'état de SELinux n'est pas modifié. Si selinux_policy n'est pas défini et que SELinux doit être activé, il par défaut à targeted. Si SELinux est déjà activé, la politique n'est pas modifiée.

Ceci utilise le module selinux pour gérer le mode et la politique SELinux.

selinux_booleans

Gérer l'état des booleans SELinux. C'est une liste de dict, où chaque dict est dans le même format que celui utilisé par le seboolean module.

selinux_booleans:
  - name: samba_enable_home_dirs
    state: true
  - name: ssh_sysadm_login
    state: true
    persistent: true

selinux_fcontexts

Gérer l'état des définitions de mappage de contexte de fichiers SELinux. C'est une liste de dict, où chaque dict est dans le même format que celui utilisé par le sefcontext module.

selinux_fcontexts:
  - target: '/tmp/test_dir(/.*)?'
    setype: 'user_home_dir_t'
    ftype: d
    state: present

Les utilisateurs peuvent également passer les paramètres optionnels suivants :

seuser: pour définir l'utilisateur SELinux
selevel: pour définir la plage de sécurité MLS/MCS (uniquement pour les systèmes MLS/MCS). La plage SELinux pour le mappage des connexions SELinux par défaut à la plage du registre de l'utilisateur SELinux.

Les modifications individuelles peuvent être annulées en définissant state sur absent.

selinux_ports

Gérer l'état de la politique de port SELinux. C'est une liste de dict, où chaque dict est dans le même format que celui utilisé par le seport module.

selinux_ports:
  - ports: 22100
    proto: tcp
    setype: ssh_port_t
    state: present
    local: true

selinux_restore_dirs

C'est une liste de chaînes, où chaque chaîne est un arbre de fichiers dans lequel vous souhaitez exécuter restorecon :

selinux_restore_dirs:
  - /tmp/test_dir

selinux_logins

Gérer la mappage des utilisateurs Linux avec les utilisateurs SELinux. C'est une liste de dict, où chaque dict est dans le même format que celui utilisé par le selogin module.

selinux_logins:
  - login: plautrba
    seuser: staff_u
    state: absent
  - login: default
    seuser: staff_u
    serange: s0-s0:c0.c1023
    state: present

selinux_modules

Il est possible de gérer les modules SELinux en utilisant la variable selinux_modules qui contiendrait une liste de dict, par exemple :

selinux_modules:
  - path: localmodule.pp
    state: enabled
  - path: localmodule.cil
    priority: 350
    state: enabled
  - name: unconfineduser
    state: disabled
  - name: localmodule
    priority: 350
    state: absent

path: un fichier de module local (soit .cil ou .pp) à installer sur un nœud, utilisé pour installer de nouveaux modules
name: nom du module, utilisé pour activer des modules désactivés, désactiver des modules activés, supprimer des modules
priority: priorité du module SELinux, par défaut "400". "100" est utilisé pour les modules installés à partir de paquets selinux-policy, "200" pour d'autres modules installés à partir de rpms tiers, "300" est utilisé par SETroubleshoot
state: l'une des valeurs suivantes
- enabled: installer ou activer le module
- disabled: désactiver le module
- absent: supprimer le module

Remarque : La construction de modules à partir de la source sur des nœuds n'est pas prise en charge. Cependant, dans de nombreux cas, un module binaire pp ou cil pourrait être utilisé sur différents systèmes si tous les systèmes prennent en charge les types, les classes et les permissions utilisés dans le module. Dans le cas d'un module pp, il doit également être construit avec la version de module policydb prise en charge la plus ancienne sur les systèmes cibles, c'est-à-dire sur le système le plus ancien.

Remarque : Les priorités des modules sont ignorées dans Red Hat Enterprise Linux 6.

Remarque : Gérer des modules est idempotent uniquement sur Fedora, et EL 8.6 et versions ultérieures. Vous pouvez gérer des modules sur des versions plus anciennes, mais cela ne sera pas idempotent.

selinux_transactional_update_reboot_ok

Cette variable est utilisée pour gérer les redémarrages requis par les mises à jour transactionnelles. Si une mise à jour transactionnelle nécessite un redémarrage, le rôle poursuivra avec le redémarrage si selinux_transactional_update_reboot_ok est défini sur true. S'il est défini sur false, le rôle informera l'utilisateur qu'un redémarrage est requis, permettant une gestion personnalisée de l'exigence de redémarrage. Si cette variable n'est pas définie, le rôle échouera pour s'assurer que l'exigence de redémarrage n'est pas négligée.

selinux_transactional_update_reboot_ok: true

Faits Ansible

selinux_reboot_required

Ce fait personnalisé est défini sur true si un redémarrage du système est nécessaire lorsque SELinux est défini de disabled à enabled ou vice versa. Sinon, le fait est défini sur false. Dans le cas où un redémarrage du système est nécessaire, cela sera indiqué par un échec du rôle qui doit être géré à l'aide d'une construction block:...rescue:. Le redémarrage doit être effectué dans le playbook, le rôle lui-même ne redémarre jamais l'hôte géré. Après le redémarrage, le rôle doit être réappliqué pour terminer les modifications.

selinux_installed_modules

Ce fait personnalisé représente la structure du magasin de modules SELinux

"selinux_installed_modules": {
  <nom du module>: {
    <priorité du module>: ("enabled"|"disabled"),
    ...
  },
  ...
}

par exemple.

"ansible_facts": {
  "selinux_installed_modules": {
    "abrt": {
      "100": "enabled",
      "400": "disabled"
    },
    "accountsd": {
      "100": "enabled"
    },
    "acct": {
      "100": "enabled"
    }
  }
}