0001772: syslog silently fails if /etc/services has bad SELinux context

(0004910)
Apollo2000 (reporter)
2007-04-21 14:21

# ls -laZ /etc/services
-rw-r--r-- root root root:object_r:tmp_t /etc/services

security context is:
root:object_r:tmp_t

security context should be:
system_u:object_r:etc_t

issue commands to get syslog working again with SELinux (enforcing):
# chcon -u system_u -r object_r -t etc_t /etc/services
# service syslog restart
Shutting down kernel logger: [ OK ]
Shutting down system logger: [ OK ]
Starting system logger: [ OK ]
Starting kernel logger: [ OK ]

(0005090)
Phil Schaffner (reporter)
2007-05-03 08:41

Found this bug while trying to figure out why my /var/log/messages is empty, and why syslogd has been dying, and being flagged by rkhunter. The selinux context on /etc/services was bad as described, and changing it as described does restart loging to /var/log/messages. Can't find any other evidence of a system compromise, but it is not obvious what might have changed to cause this problem.

Unable to find reports of this problem in upstream bugzilla.

(0006079)
Charlie Brady (reporter)
2007-10-02 23:39

> Unable to find reports of this problem in upstream bugzilla.

Is there any reason you didn't report it there?

(0006080)
Charlie Brady (reporter)
2007-10-03 00:12

> cp /etc/services /tmp/services
> mv /tmp/services /etc/services

This is essentially what various vmware tools do when they modify /etc/services:

/etc/vmware-server-console/installer.sh
/usr/bin/vmware-config-server-console.pl
/etc/vmware/installer.sh
/usr/bin/vmware-config.pl

http://communities.vmware.com/message/617291 [^]

(0006916)
djvanenckevort (reporter)
2008-02-21 09:49

Filed Service Request: 1806606 - 0001772 with upstream vendor

(0006961)
djvanenckevort (reporter)
2008-02-28 14:37

response from upstream vendor:

This issue is not a bug and does not deserve a feature request. There are no defects in the mentionned programs. The problem occurs when someone or something does change the SElinux context of "/etc/services". When something like this happens, the administrator has to analyse it's files SElinux context and he can also check the audit logs located in "/var/log/audit/audit.log".
The AVC error messages are in those logs, you can also analyse those messages with:
audit2why < /var/log/audit/audit.log

What I can do is write a knowledge base article to inform users and administrators (kbase.redhat.com).

(0006975)
djvanenckevort (reporter)
2008-03-03 20:03

29-FEB-2008 14:55:52 David Van Enckevort
I have been looking at the code and found the actual cause of the problem.

The init() function will return early if sp = getservbyname("syslog", "udp"); fails, which it will if /etc/services is not readable or not existing. This causes syslog to skip initialization.

I attached a tentative patch for this issue.

(0007250)
djvanenckevort (reporter)
2008-05-12 11:04

upstream vendor rejected the issue on april 15th.

My response to that, to which I haven't had any response yet:

I do not agree with the assessment of your developer, let me try to explain why:

1) As I explained on February 29th, the issue is not a SELinux issue, but a bug in the init() function. If getservbyname("syslog", "udp") fails syslog will continue to run, but in an uninitialized state.

getservbyname can fail because of several reasons only one of them is SELinux related. getservbyname will fail for example in the following cases:
a) if syslog / udp is not in the services database
b) if the services database is not readable or not present
c) if SELinux prevents access to the services database

Only c) will cause a auditd log entry, the other cases not

Since then I haven't heard from them.

Today I have sent an e-mail to Martin Schulze as one of the upstream developers for the Linux port of syslogd.

(0007251)
range (administrator)
2008-05-12 11:31

Thank you for keeping that up and for investigating some more time into that issue ...

Issue History
Date Modified	Username	Field	Change
2007-03-13 16:15	joshkel	New Issue
2007-03-13 16:15	joshkel	Status	new => assigned
2007-03-13 16:15	joshkel	Assigned To	=> jhughes@hughesjr.com
2007-04-21 14:08	Apollo2000	Issue Monitored: Apollo2000
2007-04-21 14:21	Apollo2000	Note Added: 0004910
2007-05-03 08:41	Phil Schaffner	Note Added: 0005090
2007-10-02 23:39	Charlie Brady	Note Added: 0006079
2007-10-03 00:12	Charlie Brady	Note Added: 0006080
2008-02-21 09:48	djvanenckevort	Issue Monitored: djvanenckevort
2008-02-21 09:49	djvanenckevort	Note Added: 0006916
2008-02-28 14:37	djvanenckevort	Note Added: 0006961
2008-03-03 20:03	djvanenckevort	Note Added: 0006975
2008-03-03 20:04	djvanenckevort	File Added: sysklogd-1.4.1-services.patch
2008-03-03 20:04	djvanenckevort	File Added: sysklogd-1.4.1-41.i386.rpm
2008-05-12 11:04	djvanenckevort	Note Added: 0007250
2008-05-12 11:31	range	Note Added: 0007251
2008-06-16 17:10	juajuara	Issue Monitored: juajuara

Notes
(0004910) Apollo2000 (reporter) 2007-04-21 14:21	# ls -laZ /etc/services -rw-r--r-- root root root:object_r:tmp_t /etc/services security context is: root:object_r:tmp_t security context should be: system_u:object_r:etc_t issue commands to get syslog working again with SELinux (enforcing): # chcon -u system_u -r object_r -t etc_t /etc/services # service syslog restart Shutting down kernel logger: [ OK ] Shutting down system logger: [ OK ] Starting system logger: [ OK ] Starting kernel logger: [ OK ]

(0005090) Phil Schaffner (reporter) 2007-05-03 08:41	Found this bug while trying to figure out why my /var/log/messages is empty, and why syslogd has been dying, and being flagged by rkhunter. The selinux context on /etc/services was bad as described, and changing it as described does restart loging to /var/log/messages. Can't find any other evidence of a system compromise, but it is not obvious what might have changed to cause this problem. Unable to find reports of this problem in upstream bugzilla.

(0006079) Charlie Brady (reporter) 2007-10-02 23:39	> Unable to find reports of this problem in upstream bugzilla. Is there any reason you didn't report it there?

(0006080) Charlie Brady (reporter) 2007-10-03 00:12	> cp /etc/services /tmp/services > mv /tmp/services /etc/services This is essentially what various vmware tools do when they modify /etc/services: /etc/vmware-server-console/installer.sh /usr/bin/vmware-config-server-console.pl /etc/vmware/installer.sh /usr/bin/vmware-config.pl http://communities.vmware.com/message/617291 [^]

(0006916) djvanenckevort (reporter) 2008-02-21 09:49	Filed Service Request: 1806606 - 0001772 with upstream vendor

(0006961) djvanenckevort (reporter) 2008-02-28 14:37	response from upstream vendor: This issue is not a bug and does not deserve a feature request. There are no defects in the mentionned programs. The problem occurs when someone or something does change the SElinux context of "/etc/services". When something like this happens, the administrator has to analyse it's files SElinux context and he can also check the audit logs located in "/var/log/audit/audit.log". The AVC error messages are in those logs, you can also analyse those messages with: audit2why < /var/log/audit/audit.log What I can do is write a knowledge base article to inform users and administrators (kbase.redhat.com).

(0006975) djvanenckevort (reporter) 2008-03-03 20:03	29-FEB-2008 14:55:52 David Van Enckevort I have been looking at the code and found the actual cause of the problem. The init() function will return early if sp = getservbyname("syslog", "udp"); fails, which it will if /etc/services is not readable or not existing. This causes syslog to skip initialization. I attached a tentative patch for this issue.

(0007250) djvanenckevort (reporter) 2008-05-12 11:04	upstream vendor rejected the issue on april 15th. My response to that, to which I haven't had any response yet: I do not agree with the assessment of your developer, let me try to explain why: 1) As I explained on February 29th, the issue is not a SELinux issue, but a bug in the init() function. If getservbyname("syslog", "udp") fails syslog will continue to run, but in an uninitialized state. getservbyname can fail because of several reasons only one of them is SELinux related. getservbyname will fail for example in the following cases: a) if syslog / udp is not in the services database b) if the services database is not readable or not present c) if SELinux prevents access to the services database Only c) will cause a auditd log entry, the other cases not Since then I haven't heard from them. Today I have sent an e-mail to Martin Schulze as one of the upstream developers for the Linux port of syslogd.

(0007251) range (administrator) 2008-05-12 11:31	Thank you for keeping that up and for investigating some more time into that issue ...

Relationships