Bug 506414 - 3.6.12-50 clamd fails on start
3.6.12-50 clamd fails on start
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-17 04:22 EDT by David
Modified: 2010-06-28 09:05 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 09:05:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David 2009-06-17 04:22:18 EDT
Description of problem:

Last version okay but now this version clamd fails to start. Denial, have to either set setenforce 0 of set clamd to permissive

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Daniel Walsh 2009-06-17 10:48:46 EDT
Anything in the audit log?
Comment 2 David 2009-06-17 13:15:08 EDT
Hi Daniel,

Funny you should mention that, the next bug after this one 506415 I filed as semodule -D does not work in Fedora 11.

There are no audits for the clamd so somethings changed in this policy stopping it.

Thanks!
Comment 3 David 2009-06-17 13:23:44 EDT
Hi Daniel,

Just read the next bug so that explains why semodule -D did not work - sorry.

Did you track down why with this policy clamd needs permissive?

I assume something in this policy changed as last one is okay, and since the avc is not audited by default, it's something base?

Do you have any builds in koji? I saw two subsequent builds -51 and 52 but these failed.

Cheers
Comment 4 David 2009-06-17 18:14:28 EDT
Daniel,

I did the following after I cleaned the audit.log

semodule -DB
/etc/init.d/clamd restart
grep avc / var/log/audit/audit.log

no entries :(

So what ever in policy is stopping clamd won't log.

Cheers
Comment 5 David 2009-06-17 19:13:44 EDT
Daniel,

Seems this is very hard to track down.

Anyway the only clue I can give you is:

With clamd set to enforcing:

[root@primary ~]# /etc/init.d/clamd restart
Stopping Clam AntiVirus Daemon:                            [FAILED]
Starting Clam AntiVirus Daemon: LibClamAV Error: cli_load(): Can't open file /var/clamav/rogue.hdb
ERROR: Can't open file or directory
                                                           [FAILED]

With clamd set to permissive:

[root@primary ~]# /etc/init.d/clamd restart
Stopping Clam AntiVirus Daemon:                            [  OK  ]
Starting Clam AntiVirus Daemon:                            [  OK  ]
[root@primary ~]# 


I did make some local policies for some stuff I had issues with, but this event wont audit despite a semodule -DB !

Here is my own local.te

module local 1.0;

require {
	type unconfined_t;
	type consoletype_t;
	type system_cronjob_t;
	type var_run_t;
	type hwdata_t;
	type initrc_t;
	type initrc_tmp_t;
	type system_cronjob_tmp_t;
	type tmp_t;
	type user_devpts_t;
	type ndc_t;
	type ntpd_t;
	type security_t;
	type iptables_t;
	type bin_t;
	type clamd_t;
	type ftpd_t;
	type tmpfs_t;
	type xdm_t;
	type gpsd_t;
	class process execheap;
	class chr_file { read write getattr };
	class capability { sys_admin fsetid };
	class file { write read execmod };
	class sock_file { write create unlink };
	class unix_dgram_socket { read write };
	class shm { write associate read unix_read unix_write };
	class dir { write search };
}

#============= clamd_t ==============
allow clamd_t initrc_tmp_t:file write;
allow clamd_t system_cronjob_tmp_t:file read;
allow clamd_t tmp_t:sock_file { write create unlink };

#============= consoletype_t ==============
allow consoletype_t initrc_tmp_t:file write;

#============= ftpd_t ==============
allow ftpd_t self:capability sys_admin;

#============= gpsd_t ==============
allow gpsd_t initrc_t:shm { unix_read read write unix_write associate };
allow gpsd_t self:capability fsetid;
allow gpsd_t tmpfs_t:file { read write };
allow gpsd_t user_devpts_t:chr_file { read write getattr };
allow gpsd_t var_run_t:dir write;

#============= iptables_t ==============
allow iptables_t initrc_t:unix_dgram_socket { read write };

#============= ndc_t ==============
allow ndc_t security_t:file read;

#============= ntpd_t ==============
allow ntpd_t initrc_t:shm { unix_read read write unix_write associate };

#============= system_cronjob_t ==============
allow system_cronjob_t bin_t:file execmod;
allow system_cronjob_t self:process execheap;

#============= unconfined_t ==============
allow unconfined_t bin_t:file execmod;
allow unconfined_t self:process execheap;

#============= xdm_t ==============
allow xdm_t hwdata_t:dir search;
Comment 6 Daniel Walsh 2009-06-18 12:35:03 EDT
matchpathcon /var/clamav/rogue.hdb
/var/clamav/rogue.hdb	system_u:object_r:clamd_var_lib_t:s0

Is this what is it labeled?

restorecon -R -v /var/clamav

Should fix

What process do you having running as initrc_t?

ps -eZ | grep initrc_t
Comment 7 David 2009-06-18 18:13:16 EDT
The restorecon worked :)

I set clamav back to enforcing and it stops and starts.

Any idea why it got labelled wrongly?

ps -eZ | grep initrc_t

system_u:system_r:initrc_t:s0    2476 ?        00:00:03 gpsd
system_u:system_r:initrc_t:s0    2529 ?        00:00:18 restart-httpd.p
system_u:system_r:initrc_t:s0    2568 ?        00:00:00 ossec-dbd
system_u:system_r:initrc_t:s0    2573 ?        00:00:00 ossec-maild
system_u:system_r:initrc_t:s0    2577 ?        00:00:00 ossec-execd
system_u:system_r:initrc_t:s0    2581 ?        00:00:12 ossec-analysisd
system_u:system_r:initrc_t:s0    2585 ?        00:00:01 ossec-logcollec
system_u:system_r:initrc_t:s0    2611 ?        00:00:00 ossec-monitord
Comment 8 Daniel Walsh 2009-06-19 07:08:16 EDT
Any chance you ran clamav directly?

http://danwalsh.livejournal.com/29041.html

gpsd is running with the wrong context on your system.  Which is causing some of your problems.  Miroslav, can you look at this.

I don't know what ossec is, but it does not look like it is part of Fedora, so having no policy is fine.
Comment 9 David 2009-06-21 04:56:13 EDT
Hi Daniel,

clamav runs at bootup (the clamd daemon) as its used by ossec-hids to scan httpd intrusion attempts.

http://www.ossec.net/

Host intrusion detection system.

Once Miroslav looks at the contexts I can drop the local.pp and make sure gpsd is locking ntpd via shm

Also Miroslav there are some errors in the gpsd for F11 also, I had to replace the init.d file as gspd will not start.

Here is the older /etc/init.d/gpsd I used:

#!/bin/bash
#
# gpsd  This shell script starts and stops gpsd.
#
# chkconfig: 345 90 40
# description: Gpsd manages access to a serial- or USB-connected GPS
# processname: gpsd

# If you must specify a non-NMEA driver, uncomment and modify the next line
#GPSD_OPTS=

# Source function library.
. /etc/rc.d/init.d/functions

RETVAL=0
prog="gpsd"

start() {
        # Start daemons.
        echo -n "Starting $prog: "
        # We don't use the daemon function here because of a known bug
        # in initlog -- it spuriously returns a nonzero status when 
        # starting daemons that fork themselves.  See
        # http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130629
        # for discussion.  Fortunately:
        #
        # 1. gpsd startup can't fail, or at least not in the absence of
        # much larger resource-exhaustion problems that would be very obvious.
        #
        # 2. We don't need all the logging crud that daemon/initlog sets
        # up -- gpsd does its own syslog calls.
        #
        if [ -e "/dev/ttyS0" ]
        then
            /usr/sbin/gpsd ${GPSD_OPTS} -n /dev/ttyS0
            success
        else
            # User needs to symlink /dev/gps to the right thing
            failure "No /dev/gps device, aborting gpsd startup."
        fi
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/gpsd
        return $RETVAL
}

stop() {
        # Stop daemons.
        echo -n "Shutting down $prog: "
        killproc gpsd
        RETVAL=$?
        echo
        if [ $RETVAL -eq 0 ]
        then
            rm -f /var/lock/subsys/gpsd;
        fi
        return $RETVAL
}

# See how we were called.
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart|reload)
        stop
        start
        RETVAL=$?
        ;;
  condrestart)
        if [ -f /var/lock/subsys/gpsd ]; then
            stop
            start
            RETVAL=$?
        fi
        ;;
  status)
        status gpsd
        RETVAL=$?
        ;;
  *)
        echo "Usage: $0 {start|stop|restart|condrestart|status}"
        exit 1
esac

exit $RETVAL
Comment 10 Miroslav Grepl 2009-06-25 05:25:09 EDT
Fixed in selinux-policy-3.6.12-60.fc11
Comment 11 David 2009-07-02 15:35:59 EDT
Confirmed it's now fixed for gpsd.

Back to clamd, clamav.

I found that freshclam is mislabling the downloaded updates when it's run from cron.daily.

I modified freshclam to restorecon the files in /var/clamav, so they are not mislabled. This works however I get cron messages emailed about this:

/etc/cron.daily/freshclam:

/sbin/restorecon reset /var/clamav/junk.ndb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/rogue.hdb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/mbl.db context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/lott.ndb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/MSRBL-SPAM.ndb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/spamimg.hdb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/scam.ndb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/spear.ndb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/vx.hdb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/MSRBL-Images-FULL-SoN.hdb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/honeynet.hdb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/securiteinfo.hdb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/phish.ndb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0
/sbin/restorecon reset /var/clamav/spam.ldb context system_u:object_r:unconfined_tmp_t:s0->system_u:object_r:var_t:s0

Can policy be modified so a cron or clamav can be on all the update files?
Comment 12 Daniel Walsh 2009-07-09 09:22:05 EDT
An unconfined process is creating the content in /tmp and then mv'ing it to /var/clamav. What ever is doing this needs to run restorecon after it is done, or use cp instead of mv.  If it is able to create the content as root then it should not be doing it in /tmp.
Comment 14 Bug Zapper 2010-04-27 11:01:04 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Bug Zapper 2010-06-28 09:05:42 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.