audit2allow - Online nel cloud

PROGRAMMA:

NOME

audit2allow - genera regole di autorizzazione/dontaudit della policy SELinux dai log delle operazioni negate

audit2perché - traduce i messaggi di audit di SELinux in una descrizione del motivo dell'accesso
negato (audit2allow -w)

SINOSSI

audit2allow [Opzioni]

VERSIONI

-a | --tutti
Leggi input da audit e log dei messaggi, conflitto con -i

-b | --avvio
Leggi l'input dai messaggi di controllo dall'ultimo avvio in conflitto con -i

-d | --dmesg
Leggi l'input dall'output di /bin/dmesg. Nota che tutti i messaggi di controllo non lo sono
disponibile tramite dmesg quando auditd è in esecuzione; usa "ausearch -m avc | audit2allow" o
"-a" invece.

-D | --non verificare
Genera regole di dontaaudit (impostazione predefinita: consenti)

-h | --Aiuto
Stampa un breve messaggio di utilizzo

-i | --ingresso
leggi input da

-l | --lastreload
leggi l'input solo dopo l'ultimo ricaricamento dei criteri

-m | --modulo
Genera modulo/richiedi output

-M
Genera pacchetto modulo caricabile, conflitto con -o

-p | --politica
File di criteri da utilizzare per l'analisi

-o | --produzione
aggiungi output a

-r | --richiede
Genera sintassi di output richiesta per i moduli caricabili.

-N | --nessun riferimento
Non generare policy di riferimento, lo stile tradizionale consente regole. Questo è il
comportamento predefinito.

-R | --riferimento
Genera criteri di riferimento utilizzando le macro installate. Questo tenta di abbinare le smentite
contro le interfacce e potrebbe essere impreciso.

-w | --perché
Traduce i messaggi di audit di SELinux in una descrizione del motivo per cui l'accesso è stato negato

-v | --verboso
Attiva l'output dettagliato

DESCRIZIONE

Questa utility esegue la scansione dei registri per i messaggi registrati quando il sistema ha negato l'autorizzazione per
operazioni e genera uno snippet di regole della policy che, se caricate nella policy, potrebbe
hanno permesso a quelle operazioni di avere successo. Tuttavia, questa utility genera solo Type
L'applicazione (TE) consente regole. Alcuni dinieghi di autorizzazione possono richiedere altri tipi di
modifiche alla politica, ad esempio l'aggiunta di un attributo a una dichiarazione di tipo per soddisfare un esistente
vincolo, aggiunta di una regola di autorizzazione del ruolo o modifica di un vincolo. Il audit2perché(8) utilità
può essere utilizzato per diagnosticare il motivo quando non è chiaro.

È necessario prestare attenzione mentre si agisce sull'output di questa utilità per garantire che il
le operazioni consentite non rappresentano una minaccia per la sicurezza. Spesso è meglio definire nuovo
domini e/o tipi, o apportare altre modifiche strutturali per consentire in modo restrittivo un insieme ottimale di
operazioni per avere successo, invece di implementare alla cieca i cambiamenti a volte ampi
consigliato da questa utility. Certe negazioni di autorizzazione non sono fatali per il
applicazione, nel qual caso potrebbe essere preferibile sopprimere semplicemente la registrazione del rifiuto
tramite una regola "dontaaudit" piuttosto che una regola "allow".

ESEMPIO

NOTA: Strumenti Bowman per analizzare le seguenti finiture: Esempi sono per di riferimento utilizzando , il revisione pacchetto. If Tu do
non uso , il revisione pacchetto, , il AVC messaggi volere be in / Var / log / messages.
Per favore, sostituirlo / var / log / messages per /var/log/audit/audit.log in , il
esempi.

utilizzando audit2allow a generare modulo politica

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

richiedere {
file di classe { getattr open read };

digita miaapp_t;
digita etc_t;
};

consenti myapp_t etc_t:file { getattr open read };


utilizzando audit2allow a generare modulo politica utilizzando riferimento politica

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

gen_require(`
digita miaapp_t;
digita etc_t;
};

files_read_etc_files(miaapp_t)


Costruzione modulo politica utilizzando Makefile

# SELinux fornisce un ambiente di sviluppo delle policy sotto
# /usr/share/selinux/devel inclusi tutti gli spediti
# file di interfaccia.
# Puoi creare un file te e compilarlo eseguendo

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

# Questo comando make compilerà un file local.te nella corrente
# rubrica. Se non hai specificato un file "pp", il file make
# compilerà tutti i file "te" nella directory corrente. Dopo
# compili il tuo file te in un file "pp", devi installarlo
# usando il comando semodule.

$ modulo -i local.pp

Costruzione modulo politica manualmente

# Compila il modulo
$ modulo di controllo -M -m -o local.mod local.te

# Crea il pacchetto
$ pacchetto_semodule -o local.pp -m local.mod

# Carica il modulo nel kernel
$ modulo -i local.pp

utilizzando audit2allow a generare ed costruire modulo politica

$ cat /var/log/audit/audit.log | audit2allow -M locale
Generazione del file di imposizione del tipo: local.te

Politica di compilazione: checkmodule -M -m -o local.mod local.te
Pacchetto di compilazione: pacchetto_semodule -o local.pp -m local.mod

******************** IMPORTANTE ***********************

Per caricare questo pacchetto di criteri appena creato nel kernel,
sei tenuto ad eseguire

semodulo -i local.pp

utilizzando audit2allow a generare monolitico (non modulo) politica

$ cd /ecc/selinux/$SELINUXTYPE/sorgente/policy
$ cat /var/log/audit/audit.log | audit2allow >> domini/misc/local.te
$ cat domini/misc/local.te
consenti cupsd_config_t unconfined_t:fifo_file { getattr ioctl };

$ fai il carico

Utilizzare audit2allow online utilizzando i servizi onworks.net