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 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.
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
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