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:
Anything in the audit log?
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!
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
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
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;
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
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
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.
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
Fixed in selinux-policy-3.6.12-60.fc11
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?
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.
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
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.