This page provides information (far too few currently) on how to setup and use rsyslog in a secure way.
Limit Services Needed
Rsyslog has a modular plugin architecture and almost everything is provided by plugins. Use this to your benefit and load only those plugins that you actually need. If, for example, you need only to receive messages via UDP, there is no need to load the TCP, TLS or RELP input plugins. By not loading these, you are saved from whatever vulnerabilities may be discovered in them. So think about what you actually need any apply only that what actually is in demand.
Passwords in rsyslog.conf
Passwords currently need to be stored as plain-text in rsyslog.conf. It would not make much sense to encrypt them with a well-known open symmetric key, as anybody would quite simply be able to obtain the password value. So it is advised to use as restricted accounts as possible within rsyslog.conf.
One way to limit the exposure is to store passwords in included config files, which can only be read by privileged users. So, upon rsyslog startup, the master rsyslog.conf can include these files, rsyslogd can read them but they are not accessible to any non-privileged user.
Starting with 4.1.1, rsyslogd provides the ability to drop privileges by impersonating as another user and/or group after startup.
Please note that due to POSIX standards, rsyslogd always needs to start up as root if there is a listener who must bind to a network port below 1024. For example, the UDP listener usually needs to listen to 514 and as such rsyslogd needs to start up as root.
If you do not need this functionality, you can start rsyslog directly as an ordinary user. That is probably the safest way of operations. However, if a startup as root is required, you can use the $PrivDropToGroup and $PrivDropToUser config directives to specify a group and/or user that rsyslogd should drop to after initialization. Once this happend, the daemon runs without high privileges (depending, of course, on the permissions of the user account you specified).
The privilege drop code has been added on top of the existing implementation. A full redesign was not possible due to time constraints. This results in an unprotected time window right at service startup, before the privileges are actually dropped. Due to the existing design, messages, even from remote hosts, are received and processed while rsyslogd still runs as root. The same applies to messages that are stored in on-disk queue structures. So there is a small time window at system startup where the daemon is much more in danger than after privilege drop.
Changing this requires some redesign. One may argue that it would be better to not release any privilege drop feature unless it is 100% secure (whatever this is). However, we have decided it is better to have a 99.999% percent solution with a known window of weakness, because it helps in many cases. So while it is not perfect, it is a useful security barrier in that it removes some attack vectors but introduces no new ones.
Under Linux, the kernel log can not be obtained as a non-root user. You may be able to work around this by SElinux. If not, you can run a second, privileged, instance of rsyslogd which just pulls the kernel log and forwards it to the first instance.
The HUP mode $HUPIsRestart is automatically set to "off" in restricted privilege mode. The reason simply is that a restart-type HUP is no longer possible once privileges have been dropped. We could program rsyslog in such a way that it could re-aquire privileges after restart, but than an attacker would also be able to do that. Consequently, restart-type HUPs are not permitted.
If you need to change the configuration, use an ordinary (OS-initiated) restart to apply the changes.
User and Group lookup Failures
The current supporting rsyslog runtime system does not provide a way to terminate rsyslog startup when a group or user name lookup fails. As such, if an invalid or deleted user is specified in a $PrivDropToUser or $PrivDorpToGroup directive and the name can not be looked up, no privilege drop will happen. The cure is to use the less-convenient $PrivDropToUserID or $PrivDropToGroupID config directives, which receive the ID and thus do not need to look it up. If they receive an invalid ID, the rsyslog run will be terminated. As such, it is advisable to use these directives.
If group privileges are dropped, all supplementary groups are removed from the process. There is no ability to add or restore any supplementary groups via rsyslog.conf.
If privileges are dropped, it is vital that all already-existing log files have proper permissions and/or ownership. Starting with 4.7.0/5.3.0, rsyslogd provides the $omfileForceChown directive to try to fix wrong ownership, but this is mainly a work-around for an invalid system configuration. That work-around will not be supported in future versions (see doc link above for details).
Fedora permits syslog programs to connect to type syslogd_port_t ports, but the only port of that type by default is UDP 514. Until a policy update, to permit connections to RELP's TCP 20514, run: semanage port -a -t syslogd_port_t -p tcp 20514 so that "semanage port --list | grep 514" includes lines listing both ports for syslog