rsyslog

The rocket-fast system for log processing

What are "Trusted Properties"?

Rsyslog can annotate messages from system log sockets (via imuxsock) with so-called "Trusted Properties". These are message properties not provided by the logging client application itself, but rather obtained from the system. As such, they can not be faked by the user application and are trusted in this sense. This bases on the similar idea introduced in systemd.

The following trusted properties are available:

_UID The userid under which the logging process is being executed.
_GID The group id under which the logging process is being executed.
_PID The PID of the logging process. Note that this PID, if configured, is also put into the syslog tag.
_EXE Path to the binary that is logging
_COMM The name (as visible by top) of the logging process.
_EXE The full command line of the logging process. Note that this string can contain spaces, thus it is always provided in quoted form.

Property names are deliberately based on property names in the systemd proposal. Additional properties can be added upon request. User- and Group-IDs as well as the PID are obtained via SCM_CREDENTIALS and as such should be always available on a relatively recent Linux system. The other properties are obtained from the /proc virtual file system. Note that this can be somewhat racy. Most importantly, these properties can not be obtained if the process has already been terminated when the message is being processed by rsyslogd. This can occur for very quick processes (logger being a prime example) and has happened in practice (for the same reason, it is theoretical possible that invalid information is reported, if the PID are reused extremely quickly – this is so unlikely we did not care about this case).

All annotations are currently (Nov 2011) placed at the end of the message, starting with " @[" (the first character being a space). The annotation is ended with "]". This is done to keep consistent with legacy syslog implementations. However, the format will probably changed and is intended to be moved over to a RFC5424 structured data item. Also, the property names were currently chosen for best fit with systemd. As systemd does not follow the relevant standards, we may at later time change to standard names, once they become fully available. So please be prepared for some future change if you begin to use this feature. You may guess that we will preserve legacy format when doing changes, but we do not promise that ;)

A sample of a message with trusted properties looks as follows:

2011-11-29T16:57:13.634852+01:00 testhost su: pam_unix(su-l:session): session opened for user root by examp(uid=677) @[_PID=5933 _UID=0 _GID=677 _COMM=su _EXE=/bin/su _CMDLINE="su - "]

The annotation is given in boldface. Note that this is all on one line. It is broken across several lines just for readability.

This feature is available starting with version 5.9.4 in the v5 rsyslog branches.

4 thoughts on “What are "Trusted Properties"?

  1. The implementation sounds interesting and is probably great for local integrity verification. However I ask myself what rsyslog offers to ensure the integrity of data on all system layers. At present it seems to mee that neither rsyslog nor systemd journal implement sufficient hash functions and cryptography to reduce attack vectors.

  2. @J.C.Denton: Sorry for the late reply – I didn’t get comment notificaions :-(

    This is a good remark. In rsyslog, we have RFC5425 TLS-protected syslog to ensure that messages in transit are protected. But as you say, this does not address your core concern. I have just released a new secure syslog store that will address what you mean. But of course there are many questions, e.g. when reading existing app log files, or receiving messages via UDP. The correct answer probably is that there definitely is more work to do, and it is quite a hard problem. But IMHO this is something that needs to be addressed as good as possible via open standards.

  3. @Tim B: again, sorry for the late reply. I like your idea about the glibc change, but am somewhat doubtful if Ulrich will do that. One possibility I see is that CEE syslog encoding could be used inside the syslog API. Assuming that a decent logging system needs to support CEE in the medium term, syslogd’s will need parsing support for that anyways. So it would be very easy to parse that same format off the system log socket. Actually, that was what I originally was looking into, and waiting that CEE would be final released (1.0) is due.

Comments are closed.