audit2allow - En ligne dans le Cloud

PROGRAMME:

Nom

audit2autoriser - générer des règles d'autorisation/dontaudit de la politique SELinux à partir des journaux des opérations refusées

audit2pourquoi - traduit les messages d'audit SELinux en une description de la raison pour laquelle l'accès a été
refusé (audit2allow -w)

SYNOPSIS

audit2autoriser [Options]

OPTIONS

-a | --tout
Lire les entrées du journal d'audit et des messages, conflits avec -i

-b | --botte
Lire l'entrée des messages d'audit depuis le dernier démarrage en conflit avec -i

-d | --dmesg
Lire l'entrée de la sortie de /bin/dmesg. Notez que tous les messages d'audit ne sont pas
disponible via dmesg lorsque auditd est en cours d'exécution ; utilisez "ausearch -m avc | audit2allow" ou
"-a" à la place.

-D | --ne pas auditer
Générer des règles dontaudit (Par défaut : autoriser)

-h | --Aidez-moi
Imprimer un court message d'utilisation

-i | --saisir
lire l'entrée de

-l | --lastreload
lire l'entrée uniquement après le dernier rechargement de la politique

-m | --module
Générer un module/exiger une sortie

-M
Générer un package de module chargeable, en conflit avec -o

-p | --politique
Fichier de stratégie à utiliser pour l'analyse

-o | --output
ajouter la sortie à

-r | --a besoin
Générer une syntaxe de sortie requise pour les modules chargeables.

-N | --noréférence
Ne générez pas de stratégie de référence, le style traditionnel autorise les règles. C'est le
comportement par défaut.

-R | --référence
Générez une stratégie de référence à l'aide des macros installées. Cela tente de faire correspondre les refus
contre les interfaces et peut être inexact.

-w | --Pourquoi
Traduit les messages d'audit SELinux en une description de la raison pour laquelle l'accès a été refusé

-v | --verbeux
Activer la sortie détaillée

DESCRIPTION

Cet utilitaire recherche dans les journaux les messages enregistrés lorsque le système a refusé l'autorisation de
opérations et génère un extrait de règles de stratégie qui, si elles sont chargées dans la stratégie, peuvent
ont permis à ces opérations de réussir. Cependant, cet utilitaire ne génère que Type
Règles d'autorisation d'application (TE). Certains refus d'autorisation peuvent nécessiter d'autres types de
changements de politique, par exemple l'ajout d'un attribut à une déclaration de type pour satisfaire un
contrainte, l'ajout d'une règle d'autorisation de rôle ou la modification d'une contrainte. Les audit2pourquoi(8) utilitaire
peut être utilisé pour diagnostiquer la raison lorsqu'elle n'est pas claire.

Des précautions doivent être prises lors de l'action sur la sortie de cet utilitaire pour s'assurer que le
les opérations autorisées ne constituent pas une menace pour la sécurité. Il est souvent préférable de définir de nouvelles
domaines et/ou types, ou apporter d'autres changements structurels pour permettre un ensemble optimal de
opérations pour réussir, au lieu de mettre en œuvre aveuglément les changements parfois vastes
recommandé par cet utilitaire. Certains refus d'autorisation ne sont pas fatals au
l'application, auquel cas il peut être préférable de simplement supprimer l'enregistrement du refus
via une règle 'dontaudit' plutôt qu'une règle 'allow'.

EXEMPLE

REMARQUE: Ces exemples en les systèmes en utilisant le audit paquet. If you do
ne sauraient utilisé le audit paquet, le AVC messages sera be in / var / log / messages.
Veuillez remplacer / var / log / messages en /var/log/audit/audit.log in le
exemples.

En utilisant audit2autoriser à générer module politique

$ cat /var/log/audit/audit.log | audit2allow -m local > local.te
$ chat local.te
module local 1.0 ;

exiger {
fichier de classe { getattr open read } ;

tapez monapp_t ;
tapez etc_t ;
};

allow myapp_t etc_t:file { getattr open read } ;


En utilisant audit2autoriser à générer module politique en utilisant référence politique

$ cat /var/log/audit/audit.log | audit2allow -R -m local > local.te
$ chat local.te
module_politique (local, 1.0)

gen_require(`
tapez monapp_t ;
tapez etc_t ;
};

fichiers_read_etc_files(monapp_t)


Développement module politique en utilisant Makefile

# SELinux fournit un environnement de développement de politiques sous
# /usr/share/selinux/devel incluant tous les
# fichiers d'interface.
# Vous pouvez créer un fichier te et le compiler en exécutant

$ make -f /usr/share/selinux/devel/Makefile local.pp

# Cette commande make compilera un fichier local.te dans le
# répertoire. Si vous n'avez pas spécifié de fichier "pp", le fichier make
# compilera tous les fichiers "te" dans le répertoire courant. Après
# vous compilez votre fichier te dans un fichier "pp", vous devez installer
# à l'aide de la commande semodule.

$ semodule -i local.pp

Développement module politique manuellement

# Compiler le module
$ checkmodule -M -m -o local.mod local.te

# Créer le package
$ semodule_package -o local.pp -m local.mod

# Charger le module dans le noyau
$ semodule -i local.pp

En utilisant audit2autoriser à générer ainsi que construire module politique

$ cat /var/log/audit/audit.log | audit2allow -M local
Type de génération du fichier d'application : local.te

Politique de compilation : checkmodule -M -m -o local.mod local.te
Package de construction : semodule_package -o local.pp -m local.mod

******************** IMPORTANT ***********************

Afin de charger ce paquet de règles nouvellement créé dans le noyau,
vous devez exécuter

semodule -i local.pp

En utilisant audit2autoriser à générer monolithique (hors module) politique

$ cd /etc/selinux/$SELINUXTYPE/src/politique
$ cat /var/log/audit/audit.log | audit2allow >> domaines/misc/local.te
$ cat domaines/misc/local.te
autoriser cupsd_config_t unconfined_t:fifo_file { getattr ioctl } ;

$ faire la charge

Utilisez audit2allow en ligne en utilisant les services onworks.net