SELinux context gone from key files...

Support for security such as Firewalls and securing linux
Post Reply
shooker
Posts: 1
Joined: 2005/01/04 00:17:13
Location: Burlington, VT USA

SELinux context gone from key files...

Post by shooker » 2006/06/08 19:01:51

I work at an ISP, and we've had a machine colo'ed at another provider for the last few months for various reasons. I prepped it back in, like, February for the role it's soon to assume and, as is wont to happen, forgot about it on account of other projects cropping up (apart from periodically logging in to run 'yum update'). I checked in today, and noted that there are some big holes in the log files (entries through February, then a smattering in late May, then another small batch on 1 June). Checked around, and discovered that syslogd is being denied access to the logfiles by SELinux (yes, it's "enforcing").

To wit:


[root@remote00 ~]# dmesg | grep avc | grep syslog | grep append
audit(1149784470.247:4): avc: denied { append } for pid=2084 comm="syslogd" name="messages" dev=sda3 ino=359092
scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file
audit(1149784470.247:5): avc: denied { append } for pid=2084 comm="syslogd" name="secure" dev=sda3 ino=359093
scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file
audit(1149784470.247:6): avc: denied { append } for pid=2084 comm="syslogd" name="maillog" dev=sda3 ino=359094
scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file
audit(1149784470.247:7): avc: denied { append } for pid=2084 comm="syslogd" name="cron" dev=sda3 ino=359097
scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file
audit(1149784470.247:8): avc: denied { append } for pid=2084 comm="syslogd" name="spooler" dev=sda3 ino=359095
scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file
audit(1149784470.247:9): avc: denied { append } for pid=2084 comm="syslogd" name="boot.log" dev=sda3 ino=359096
scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file


(It's also being denied reads of /etc/hosts and /etc/resolv.conf for some weird reason.)

I checked the contexts of those files, and can see the problem pretty plainly (just a sample, here):


[root@remote00 var]# ls -alZ /var/log/messages* /var/log/secure* /var/log/maillog*
-rw------- root root /var/log/maillog
-rw------- root root /var/log/maillog.1
-rw------- root root user_u:object_r:var_log_t /var/log/maillog.2
-rw------- root root /var/log/messages
-rw------- root root /var/log/messages.1
-rw------- root root user_u:object_r:var_log_t /var/log/messages.2
-rw------- root root /var/log/secure
-rw------- root root /var/log/secure.1
-rw------- root root user_u:object_r:var_log_t /var/log/secure.2


So, clearly, the files had the right context, originally. I was originally thinking that either logrotate was borking the creation of new logs, or there's been some sort of system compromise. I checked the contexts of the hosts file and resolv.conf on both this colo machine and compared to another, local CentOS4 box:


[root@remote00 var]# ls -alZ /etc/hosts
-rw-r--r-- root root /etc/hosts
[root@remote00 var]# ls -alZ /etc/resolv.conf
-rw-r--r-- root root /etc/resolv.conf


vs.


[root@local09 log]# ls -alZ /etc/hosts
-rw-r--r-- root root user_u:object_r:etc_t /etc/hosts
[root@local09 log]# ls -alZ /etc/resolv.conf
-rw-r--r-- root root user_u:object_r:etc_t /etc/resolv.conf


Kind of disturbing. In fact, many files in /etc (including passwd and shadow) have lost their context, as have home directories. My instinct is to think "jacked box". (Up-to-date) SSH is limited to keys-only and (via firewall) connections sourced from our corporate network. The firewall (Shorewall) is of the "deny-all" variety and otherwise only allows HTTPS connections inbound. (It was allowing iperf connections on tcp/5001 and udp/5001 from a single customer's network, but the iperf server hasn't been run for a long, long while.) The machine has been running a test website for a while (with CGI scripts and password-protected DAV enabled), which is the only source of opportunities I can think of for compromise.

I've been Googling other possibilities, but I think I'm on a collision course with rebuilding this machine out of professional paranoia unless someone out there says, "Wait a minute! There was an update to ____________ that did this same thing! Just run 'fixfiles'..." or whatever.

So: anyone? Anyone? Bueller?

Post Reply

Return to “CentOS 4 - Security Support”