New Red Hat Enterprise Linux 7 Security Feature: systemd-journald

A lot has already been written about systemd-journald. For example, this article describes the security benefits of the journal.

I would argue that systemd-journal is not a full replacement for syslog. The syslog format is ubiquitous, and I don't see it going away. On all Red Hat Enterprise Linux 7 machines, syslog will still be on by default. This is because it's still the defacto mechanism for centralizing your logging data, and most tools that analyze log data read syslog data. The journald actually makes syslog better, as syslog gathers its data from the journal, and because the journal runs from bootup to shutdown, it can feed more data to syslog, saving it until the syslog process starts.

When journald was first being created, many people who were working on Structured Logging got all up in arms over it because Lennart Poettering and Kay Sievers did not work with them. Despite that problem, I still like it.

When it comes to launching system apps, systemd has become the central point. It can be thought of as the systems process manager. It knows more about what is going on in the system then any other process, save for the kernel.

Years ago when the audit system was being built, Karl MacMillan of Tresys believed that some of the problems that the audit system was trying to fix could be handled by extending syslog to record all information about the sending process. You see syslog records very little metadata about who sent the syslog message. The audit subsystem was created to record all of the critical identity data, such as all of the UIDs associated with a process as well as the SELinux context; journald now collects all of data.

Let me give an example of where systemd-journal could be used to increase security.

SELinux controls what a process is allowed to do based on what it was designed to do. Sometimes even less, depending on the security goals of the policy writer. This means SELinux would prevent a hacked ntpd process from doing anything other then handling Network Time. SELinux would prevent the hacked ntpd from reading MySQL databases or credit-card data from a user's home directory, even if the ntpd process was running as root. However, as the ntpd process sends syslog messages, SELinux would allow the hacked process to continue to send syslog messages.

The hacked ntpd could format syslog messages to match other daemons and potentially trick an administrator or (even better) a tool that reads the syslog file (like intrusion detection tools) into doing something bad. If all messages were verified with the systemd-journal, then the administrator or syslog analysis tool could see that ntpd_t was sending messages forged as if they were coming from the sshd daemon. The intrusion detection tools, realizing the ntpd daemon had been hacked, could then be coded to recognize those bad messages.

.cursor=s=f328cc4b2615417189ab76b00c7ae041;i=2;b=4c3d0faf6b774fb7930972c1a4a5f87
.realtime=1329940273078467
...skipping...
SYSLOG_IDENTIFIER=sshd
SYSLOG_PID=2302
MESSAGE=sshd Fake message from sshd.
_PID=2302
_UID=0
_GID=0
_COMM=ntpd
_EXE=/usr/sbin/ntpd
_CMDLINE=/usr/sbin/ntpd -n -u ntp:ntp -g
_SYSTEMD_CGROUP=/system/ntpd.service
_SYSTEMD_UNIT=ntpd.service
_SELINUX_CONTEXT=system_u:system_r:ntpd_t:s0
_SOURCE_REALTIME_TIMESTAMP=1330527027590337
_BOOT_ID=4c3d0faf6b774fb7930972c1a4a5f870
_MACHINE_ID=432d8198a8fc421caf2dca48ccde1cf2\
_HOSTNAME=x.example.com