View Issue Details

IDProjectCategoryView StatusLast Update
0001772CentOS-4sysklogdpublic2013-04-08 20:29
Reporterjoshkel 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionsuspended 
Product Version4.4 
Target VersionFixed in Version 
Summary0001772: syslog silently fails if /etc/services has bad SELinux context
DescriptionIf /etc/services has a bad SELinux context, syslogd starts but doesn't open any logfiles and doesn't log anything. It should instead error out.

To replicate:
cp /etc/services /tmp/services
mv /tmp/services /etc/services
/etc/init.d/syslog restart
TagsNo tags attached.

Activities

Apollo2000

Apollo2000

2007-04-21 14:21

reporter   ~0004910

# 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 ]
Phil Schaffner

Phil Schaffner

2007-05-03 08:41

reporter   ~0005090

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.
Charlie Brady

Charlie Brady

2007-10-02 23:39

reporter   ~0006079

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

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

Charlie Brady

2007-10-03 00:12

reporter   ~0006080

> 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
djvanenckevort

djvanenckevort

2008-02-21 09:49

reporter   ~0006916

Filed Service Request: 1806606 - 0001772 with upstream vendor
djvanenckevort

djvanenckevort

2008-02-28 14:37

reporter   ~0006961

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).
djvanenckevort

djvanenckevort

2008-03-03 20:03

reporter   ~0006975

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.

2008-03-03 20:04

 

sysklogd-1.4.1-services.patch (2,204 bytes)
--- sysklogd-1.4.1rh/syslogd.c.services	2008-02-28 21:35:10.000000000 +0100
+++ sysklogd-1.4.1rh/syslogd.c	2008-02-29 20:31:55.000000000 +0100
@@ -737,6 +737,7 @@
 char	LocalHostName[MAXHOSTNAMELEN+1];	/* our hostname */
 char	*LocalDomain;		/* our local domain name */
 int	InetInuse = 0;		/* non-zero if INET sockets are being used */
+int	Networking = 1;		/* set when we have network support */
 int	finet= -1;		/* Internet datagram socket */
 int	LogPort;		/* port number for INET connections */
 int	Initialized = 0;	/* set when we have initialized ourselves */
@@ -2309,20 +2310,28 @@
 #endif
 	struct servent *sp;
 
+	/*
+	* These lines should stay as the first two
+	*/
+	dprintf("Called init.\n");
+	Initialized = 0;
+
 	sp = getservbyname("syslog", "udp");
 	if (sp == NULL) {
 		errno = 0;
-		logerror("network logging disabled (syslog/udp service unknown).");
-		logerror("see syslogd(8) for details of whether and how to enable it.");
-		return;
+		fprintf(stderr, "network logging disabled (syslog/udp service unknown).\n");
+		fprintf(stderr, "see syslogd(8) for details of whether and how to enable it.\n");
+		/* 
+		 * Do not return but continue init(), but disable network support 
+ 		*/
+		Networking = 0;
+	} else {
+		LogPort = sp->s_port;
+		Networking = 1;
 	}
-	LogPort = sp->s_port;
-
 	/*
 	 *  Close all open log files and free log descriptor array.
 	 */
-	dprintf("Called init.\n");
-	Initialized = 0;
 	if ( nlogs > -1 )
 	{
 		dprintf("Initializing log structures.\n");
@@ -2449,7 +2458,7 @@
 #endif
 
 #ifdef SYSLOG_INET
-	if (Forwarding || AcceptRemote) {
+	if (Networking && (Forwarding || AcceptRemote)) {
 		if (finet < 0) {
 			finet = create_inet_socket();
 			if (finet >= 0) {
@@ -2709,6 +2718,8 @@
 	{
 	case '@':
 #ifdef SYSLOG_INET
+		/* Only if we have functioning Networking support */
+		if (!Networking) break;
 		(void) strcpy(f->f_un.f_forw.f_hname, ++p);
 		dprintf("forwarding host: %s\n", p);	/*ASP*/
 		 if ( (ina = not_local_address(p)) == NULL ) {
@@ -2718,7 +2729,7 @@
 		} else {
 			f->f_type = F_FORW;
 		}
-
+		
 		memset((char *) &f->f_un.f_forw.f_addr, 0,
 			 sizeof(f->f_un.f_forw.f_addr));
 		f->f_un.f_forw.f_addr.sin_family = AF_INET;

2008-03-03 20:04

 

sysklogd-1.4.1-41.i386.rpm (74,542 bytes)
djvanenckevort

djvanenckevort

2008-05-12 11:04

reporter   ~0007250

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.
range

range

2008-05-12 11:31

administrator   ~0007251

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

tigalch

2013-04-08 20:28

manager   ~0017166

CentOS4 is EOL

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-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: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
2013-04-08 20:28 tigalch Note Added: 0017166
2013-04-08 20:28 tigalch Status assigned => closed
2013-04-08 20:29 tigalch Resolution open => suspended