Friday, March 12, 2010

SELinux becomes SDLinux

I still don't know how it happened, but on my CentOS 5 (a.k.a. Red Hat Enterprise Linux 5) system, something changed the SELinux context of the /etc/services file from what it is supposed to be to object_r:rpm_script_tmp_t. Several days later, I noticed that no messages were being added to system logs. /var/log/messages was empty. /var/log/secure was empty. /var/log/cron was empty. Just about every log file written to /var/log ended up with 0 (zero) bytes.

My guess is that some RPM I installed, or that got installed via yum, changed the SELinux context of /etc/services. So, without log messages, the security of the system is a bit degraded (so I'll dub that SDLinux for "Security Degraded Linux"). My first thought was that somehow someone managed to get past the certificate-only source-ip-restricted SSH login and zap the logs. However, since no additional log messages were being written, that isn't as suspect as I had feared.

To get logging started again wasn't too complicated:
  1. restorecon /etc/services
    (changes the SELinux context back to what it should be, which is
    system_u: object_r:etc_t)
  2. service syslog restart
Testing to be sure things were working was easy too:
  1. logger -p daemon-warn "this is a test"
  2. tail /var/log/messages
Verify the SELinux context for /etc/services is correct with:
  • ls -Z /etc/services

Here's a reference to the bug that makes this quieter and uglier than it should be:


No comments: