Format non documenté des loggings du journal d'audit Linux

J'écris un parsingur pour Linux Audit et je suis tombé sur des cas bizarres qui ne semblent pas conforms à la norme.

Ma reference est la documentation de Red Hat .

Un dossier d'audit approprié devrait ressembler à ceci:

type=USER_CMD msg=audit(1464013671.517:403): pid=3569 uid=0 auid=1000 ses=7 msg='cwd="/root" cmd=123 terminal=pts/1 res=success' 

Un nom invalide = champ de valeur dans un logging

Regardons l'logging suivant:

 type=DAEMON_START msg=audit(1464013652.147:626): auditd start, ver=2.4 format=raw kernel=3.16.0-4-586 auid=4294967295 pid=3557 res=success 

La documentation ne dit rien sur le auditd start qui ne correspond pas au format name = value .

Qu'est-ce que c'est? Où je peux lire à ce sujet?

Une virgule et un espace comme séparateur

De plus, la documentation indique que

Chaque logging est composé de plusieurs paires nom = valeur séparées par un espace blanc ou une virgule.

Ce n'est clairement pas vrai puisque nous pouvons voir que auditd start, ver=2.4 sont séparés par une command et un espace.

Pourquoi est-ce ainsi? Où est la norme vraiment décrite?

Des espaces blancs supplémentaires dans un logging

Regardons l'logging suivant:

 type=CWD msg=audit(1464013682.961:409): cwd="/root" 

Il a deux espaces entre type=CWD msg=audit(1464013682.961:409): et cwd="/root" . Cela n'a aucun sens. En fait, j'ai observé ce comportement uniquement dans les loggings de type=CWD et cwd="/root" .

Pourquoi est-ce ainsi?


Note: J'ai généré ces journaux sur un récent Debian.

Donc, j'ai résolu une petite partie du problème – j'ai découvert que auditd start, ver=2.2 est valide. Je n'ai pas réussi à find de documentation. Le seul document que j'ai est un exemple du manuel de Red Hat:

Exemple 7.5. Evénements audit.log supplémentaires

L'événement Audit suivant enregistre un démarrage réussi du daemon auditd. Le champ ver affiche la version du démon d'audit qui a été démarré.

 type=DAEMON_START msg=audit(1363713609.192:5426): auditd start, ver=2.2 format=raw kernel=2.6.32-358.2.1.el6.x86_64 auid=500 pid=4979 subj=unconfined_u:system_r:auditd_t:s0 res=success 

L'événement d'audit suivant enregistre une tentative échouée d'user avec UID de 500 pour se connecter en tant qu'user root.

 type=USER_AUTH msg=audit(1364475353.159:24270): user pid=3280 uid=500 auid=500 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="root" exe="/bin/su" hostname=? addr=? terminal=pts/0 res=failed' 

La sortingste chose est que ce ne sont que des exemples. J'aimerais lire la documentation réelle de la norme puisque je ne peux pas la find nulle part.


Mettre à jour

J'ai posé ces questions de la list de diffusion officielle ( voir la réponse complète à ma question ).

Voici ce que j'ai appris:

Un nom invalide = champ de valeur dans un logging

Je ne suis pas clair pour moi pourquoi auditd start exister, mais voici la réponse de Steve Grubb à ma question.

Où sont énumérés tous les éléments comme auditd start, user, etc.? Je ne trouve aucun document qui spécifie ce qui peut se produire entre les deux points (séparant le type et le msg = audit (…) des champs) et les champs de l'logging.

Il n'y en a vraiment pas, Libauparse prend soin de tout cela pour que vous n'ayez pas à le faire. Si vous souhaitez effectuer une traduction, vous pouvez alimenter les journaux en auparse, puis formater l'événement comme vous le souhaitez.

Fondamentalement, la réponse est cachée quelque part dans la bibliothèque auparse.

Une virgule et un espace comme séparateur

Pourquoi certains loggings sont séparés par une virgule et un espace? Exemple:

 type=DAEMON_START msg=audit(1363713609.192:5426): auditd start, ver=2.2 format=raw kernel=2.6.32-358.2.1.el6.x86_64 auid=500 pid=4979 subj=unconfined_u:system_r:auditd_t:s0 res=success 

Il y a longtime, les disques étaient censés être à la fois lisibles par l'homme (ne riez pas) et consommables par la machine. Au fil du time, ces paires ont été converties nom = valeur. Même celui que vous mentionnez ci-dessus a été corrigé.

Des espaces blancs supplémentaires dans un logging

Celui-ci a déjà été patché par Steve Grubb.

Le correctif: https://www.redhat.com/archives/linux-audit/2016-juillet/msg00086.html