1

I have a little experience with RHEL 6 from around 2016-2018 timeframe, but not much. When I took a new job in January 2025, I inherited a couple RHEL 8 systems. Those systems are not connected to a network that can access the internet, so I am unable to provide exact screenshots or copy/paste examples of what I'm seeing. At the time, they were running 8.2 and I've since upgraded them to 8.10. The purpose of the servers are just syslog servers (using syslog-ng). Part of my responsibilities is to complete and maintain DISA STIG checklists for the systems I'm responsible for (these RHEL systems are two of many non-*nix systems). One of the items I still need to improve for the servers is SELinux. The servers I inherited had SELinux in permissive mode. I of course did research before attempting to get SELinux into enforcing mode.

I have verified that the syslog and syslog-ng service have standard contexts:

system_u:system_r:syslogd_t:s0  root        1179  0.0  1.2 193620 11840 ?        Ssl  Sep22   1:15 /usr/sbin/rsyslogd -n
system_u:system_r:syslogd_t:s0  root        1140  0.0  0.3 193620 11840 ?        Ssl  Sep22   7:45 /usr/sbin/syslog-ng -F -p /var/run/syslogd.pid

I verified /var/log had standard file contexts:

ls -dZ /var/log
system_u:object_r:var_log_t:s0 /var/log

The server has a separate physical disk that is mounted as /data/. The syslog-ng logs to /data/logs/${HOST}/. The syslog config includes configuration to send the local RHEL system logs to the syslog directory. We'll say this directory ends up being /data/logs/localserver/. The syslog-ng configuration to do this looks like this:

destination d_mesg { file("/data/logs/${HOST}/messages_${YEAR}_${MONTH}_${DAY}");};
destination d_auth { file("/data/logs/${HOST}/secure_${YEAR}_${MONTH}_${DAY}");};
destination d_cron { file("/data/logs/${HOST}/cron_${YEAR}_${MONTH}_${DAY}");};
destination d_kern { file("/data/logs/${HOST}/kern_${YEAR}_${MONTH}_${DAY}");};

Initially, the context on /data/logs/ was wrong, but I fixed that.

semanage fcontext -a '/data/logs(/.*)?' -t var_log_t

I ran semanage fcontext -l | grep syslog and it showed the rule I added. Next, I used restorecon:

restorecon -Rv /data/logs/

ls -alhdZ /data/logs
drwxr-x---. 13 root myaccount unconfined_u:object_r:var_log_t:s0 4.0K Oct 10 11:56 /data/logs

ls -alhtZ /data/logs
drwx------. 2 root myaccount unconfined_u:object_r:var_log_t:s0 4.0K Oct 10 11:28 localsever
drwxr-x---. 3 root myaccount unconfined_u:object_r:var_log_t:s0 4.0K Oct 10 00:00 Firewall
drwxr-x---. 2 root myaccount unconfined_u:object_r:var_log_t:s0 4.0K Oct  8 18:56 Switch

After I run setenforce 1, and I monitor the logs being written under /data/logs/. One directory stops having logs written to it, and that is the files under the /data/logs/localserver directory. If I run setenforce 0, the logs immediately start writing to that directory again.

I started looking for denies or errors. Yesterday, I ran:

grep syslog-ng /var/log/audit/audit.log | grep denied
node=localServer type=AVC msg=audit(9OCT2025_in_epoc): avc: denied { execmem } for pid=1134 comm="syslog-ng" scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:syslogd_t:s0 tclass=process permissive=0
node=localServer type=AVC msg=audit(9OCT2025_in_epoc): avc: denied { execmem } for pid=1134 comm="syslog-ng" scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:syslogd_t:s0 tclass=process permissive=1

grep selinux /var/log/messages
Oct 9 12:26:51 localServer kernel: evm: security.selinux

grep syslog /var/log/messages results in no errors or failures. I looked for "execmem" booleans related to anything syslog and I don't see any. I used audit2allow, and it did find allow syslogd_t self:process execmem;. I created a module and imported it. Restarted the rsyslog and syslog-ng services. But even after that, logs still stop writing to /data/logs/localserver. Today, I turn on setenforce 1 again and then look again for for SELinux messages in /var/log/audit/audit.log, there is nothing. The execmem messages don't show up today. grep selinux /var/log/messages shows the same Oct 9 12:26:51 localServer kernel: evm: security.selinux.

I'm not sure what else to try or how to troubleshoot this further. I would appreciate any suggestions for further troubleshooting. Thanks in advance.

Improve this question
10
  • But even after that, logs still stop writing to /data/logs/localserver. Did the audit log entries change? Commented Oct 11 at 20:34
  • /var/log/messages and /var/log/audit/audit.log both continue to write logs. Just not at /data/logs/localserver. Commented Oct 12 at 12:09
  • Can you check if ${HOST} variable return anything, NOT empty? Commented Oct 13 at 10:13
  • Yes, I can check that tomorrow. However, I thought that if I change setenforce 0 and it immediately starts writing to the /data/logs/localserver/ directory, and it stops writing when I change it to setenforce 1, that is a clear indication that the problem is SELinux. Am I mistaken on that? Commented Oct 13 at 13:33
  • 1
    Update: I made the syslogd_t type permissive and left SELinux in enforcing mode. This immediately allowed the system to write to my syslog directory as I wanted it to. I know that's not ideal, but I figure absent any logs, having one service in permissive mode and the rest of the system enforcing is better than the whole system in permissive mode. Commented Oct 17 at 12:48

1 Answer 1

Reset to default
1

The deny messages you found about execmem are about the process (syslog-ng) trying to execute its own memory content. That should not interfere with it writing to the desired directory. I would say that the two problems are very likely unrelated.

At this point, I would look at the syslog-ng config, and the directory permissions on the locaslserver directory and the files under it. Are perhaps the local logs sent or saved to somewhere else, apart from being saved locally into the locaslserver directory? BTW, is this the open-source syslog-ng or syslog-ng-premium-edition?

Improve this answer
9
  • If I change setenforce 0, it immediately starts writing to the /data/logs/localserver/ directory. So is that not a clear indication that the problem is SELinux related? And that the syslog-ng config is working? I assume it is the open-source syslog-ng. But the person that set it up left the organization 4 years ago. No one still here would have had any way to know. Commented Oct 13 at 13:29
  • IIRC the output of syslog-ng --version should include whether it's the open-source or the commercial version. Commented Oct 13 at 14:50
  • Yes, either syslog-ng --version or rpm -qa | fgrep syslog-ng may tell you that information. Commented Oct 14 at 5:23
  • And yes, the fact that when you set setenforce 0 syslog-ng begins to log would indicate that the problem is somehow SELinux related. On the other hand there were no deny logs in the audit log, which hint that it's probably not FS labeling related. There may be configurations where logs are sent to multiple destinations and flow-control would stop the log flow for both destinations if one was stuck for some reason. Commented Oct 14 at 5:34
  • I have the open source version of syslog-ng. Commented Oct 14 at 15:20

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.