No, SELinux is not the cause of all permission troubles on Linux. For example, syslog-ng makes use of the capabilities system on Linux to drop as many privileges as possible, as early as possible. But it might cause problems in some corner cases, as even when running as root, syslog-ng cannot read files owned by a different user. Learn from this blog how you can figure out if you have a SELinux or capabilities problem and how to fix it if you do.
SELinux
Yes, SELinux is the primary suspect when something does not work as expected on your RHEL or CentOS system. It can cause any kind of mysterious file permission problems and can even prevent network connections when the configuration contains an unusual port number. To verify if a problem is caused by SELinux, check the audit logs on your system, normally in /var/log/audit/audit.log. If it is SELinux preventing syslog-ng from running as expected, you will see one or more related messages in that file. Check my earlier blog at https://www.syslog-ng.com/community/b/blog/posts/using-syslog-ng-with-selinux-in-enforcing-mode for more information about how to resolve these problems.
No, turning off SELinux does not solve your problems, merely treats the symptoms. Unless you are just quickly testing something, you should take the time and create the additional rules for SELinux. Even if SELinux comes from the NSA, it actually enhances the security of your systems. Just search for “vulnerabilities stopped by SELinux” on Google or your favorite search engine.
Capabilities
Spotting a Linux capabilities problem is not as easy as for SELinux, since there are no audit logs mentioning them. Right now, I am only aware of a file permission problem. Even when syslog-ng is running as root, it cannot read files owned by a different user.
This problem was reported to me as something related to TLS. So – using the TLS guide I created many years ago – I configured and tested an encrypted connection between syslog-ng instances. Then, I started to play with file ownership and permissions, and it turned out that the problem is not limited to certificates, but more generic instead. That moment, Linux capabilities came to my mind, and a minute later I had a working solution for the problem.
Why might you have files with different owners? A typical source of the problem is when you compile syslog-ng as a regular user and then try to run it as root to gain additional privileges, like opening network ports under 1024. Another case is when syslog-ng is running as root, but certificates or configuration are managed by scripts running as a regular user. In either case, Linux capabilities support enabled in syslog-ng prevents reading these files.
Most syslog-ng packages on Linux have capabilities support enabled. You can check it from the command line by running syslog-ng with the -V option:
[root@centos7 ~]# syslog-ng -V syslog-ng 3 (3.27.1) Config version: 3.22 Installer-Version: 3.27.1 Revision: Compile-Date: May 4 2020 08:17:51 Module-Directory: /usr/lib64/syslog-ng Module-Path: /usr/lib64/syslog-ng Include-Path: /usr/share/syslog-ng/include Available-Modules: add-contextual-data,affile,afprog,afsocket,afstomp,afuser,appmodel,basicfuncs,cef,confgen,cryptofuncs,csvparser,dbparser,disk-buffer,examples,graphite,hook-commands,json-plugin,kvformat,linux-kmsg-format,map-value-pairs,pseudofile,sdjournal,stardate,syslogformat,system-source,tags-parser,tfgetent,timestamp,xml Enable-Debug: off Enable-GProf: off Enable-Memtrace: off Enable-IPv6: on Enable-Spoof-Source: on Enable-TCP-Wrapper: on Enable-Linux-Caps: on Enable-Systemd: on
The “Enable-Linux-Caps: on” line shows that capabilities support is enabled. This way, syslog-ng can drop most of its privileges on start.
Workaround / fix
Just like with SELinux, there are multiple ways of resolving this problem. One way is to disable capabilities support in syslog-ng completely. You can do this with the --no-caps command line option of syslog-ng. Even if there were no known security problems within syslog-ng for a long time, I do not recommend using it. Just like with SELinux, it can protect against unknown problems.
If you take a look at the syslog-ng manual page, you can see a nice, long list of capabilities. You can modify it to get file reading working by adding a single “e” to cap_fowner parameters. The full command line would look like this:
syslog-ng --caps cap_sys_admin,cap_chown,cap_dac_override,cap_net_bind_service,cap_fowner=eip
Checking something quickly from the command line using --no-caps is definitely easier. For production environments, I would rather recommend using the longer form, as it enables just a single additional privilege instead of everything.
Depending on your Linux distribution, the configuration of services might be different. In CentOS 7, you can pass command line parameters to syslog-ng using the /etc/sysconfig/syslog-ng file and adding the following line to it:
SYSLOGNG_OPTS="--caps cap_sys_admin,cap_chown,cap_dac_override,cap_net_bind_service,cap_fowner=eip"
If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik.