[systemd-devel] parsing audit messages

Lennart Poettering lennart at poettering.net
Thu Mar 26 01:41:59 PDT 2015

On Sun, 15.03.15 03:49, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> Hi,
> I was looking at some debug logs, and the audit messages are
> semi-useless in their current undecoded form:
> mar 14 22:24:02 fedora22 audit[1]: <audit-1130> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-udev-trigger comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
> mar 14 22:24:05 fedora22 audit: <audit-1327> proctitle=2F7362696E2F6D6F6470726F6265002D71002D2D0069707461626C655F7365637572697479
> You added code to parse this, and I think we should make use of it and
> put msg= field as MESSAGE=, and maybe store the original message as
> _AUDIT= or something. If there's no msg field, like with proctitle,
> print all fields that are in the message, but using our cescape, and
> not this hexadecimal form which is unreadable for humans.
> Thoughts?

Well "msg=" is just where they place the userspace message, if it is a
userspace generated message. It is little more than a separator
between the kernel generated and userspace generated parts of the
message. The userspace message is generally not more or less human
readable than the whole message I fear...

I am all for making the audit parsing logic smarter, but I don't see
how that's possible, the kernel generated format is a complete
disaster, the people who wrote that had no concept at all of computer
security, and its' impossible to parse fully correctly without

For example, if we encounter 2proctitle=41" in the message, we simply
don't know whether this is actually a process called "41", or just the
hex encoded process name "A"... The formatting is not reversible. It's
complete rubbish.

It's an embarassment for the kernel community that a technology like
audit -- that is supposed to improve security -- is so vulnerable to the
most trivial script-kiddy attacks!

I am not sure we can do much about this really...


Lennart Poettering, Red Hat

More information about the systemd-devel mailing list