Created attachment 512126 [details]
This is a summation of the calls I am using
1 of 7 attachments
Created attachment 512127 [details]
This shows that the freshclam is happening from its log file
2 of 7
Created attachment 512128 [details]
This shows that the clamscan is happening via the log file
Created attachment 512129 [details]
This is what I see in /var/log/messages starting with the power-up
4 of 7
Created attachment 512130 [details]
This is some sealert info with cut-and-paste from gui as well
5 of 7
Created attachment 512131 [details]
This is mail trail with freshclam removed (see description)
6 of 7
Created attachment 512132 [details]
Mail trail from yesterday when I got a clean run (see descriptions)
7 of 7
What AVC messages are you seeing in /var/log/audit/audit.log Created attachment 512305 [details]
copy of /var/log/audit/audit.log from 11jul11
Thanks for prompt reply.
I scanned the file and didn't spot how I could isolate out only information from the 10jul11 run that I sent with the original bug ... don't know if the audit.log is cumulative or not?
But, I see all sorts of AVC notes and they "look" like what I see on my various tests, so hopefully it doesn't matter if matched with yesterday (10jul11)
Let me know if there is more I can provide,
Thanks,
Paul
I wanted to check in to see how things were going and if there was anything else I could provide. Though I am getting near the dark ages by being on F14, it would sure be nice to be able to run clamav without SELinux alerts ... or maybe it is run SELinux without clamav mucking things up (smile) Thanks in advance for bearing with this gentle query, Paul Sorry we dropped the ball on this one. Why is clamscan opening and reading every executable on the system? Daniel: Thanks for getting back to me. The best documentation I could find on installing clamav was on the web (rather than on official doc from clamav ... see 718642) suggested the following for directories to scan: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/kerberos/bin /usr/kerberos/sbin /usr/lib/qt* /home /tmp I edited it down to reflect what my system actually has/uses: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /home /tmp Is there a reason why I should not be scanning any of these? Please note that I am seeing SELinux errors in all of these directories Thanks, Paul Maybe I don't understand what this application is doing, I thought it examined incoming EMAIL, are you saying you can set it up to examine all executables for known virus patterns? So it needs to read all executables? Daniel: When I installed clamav on my F14 system, I scanned the web for any and all documentation. I bookmarked a couple ... one of them was http://www.geekamongus.com/2009/10/03/personal-antivirus-for-linux-clamav-with-fedora-11/ which, though its for f11, gave the impression that clamav could not only scan incoming email but also directories on one's system. If this is not an appropriate use of clamav, then I will gladly accept a correction. Once again, I couldn't find any user docs on the clamav site which indicated this is what one should (or shouldn't) use it for and/or generic set-up example/template. For example, in the FAQ (http://www.clamav.net/lang/en/faq/faq-misc/), it says at the bottom to "Please read the complete documentation in pdf/ps format. You will find it inside the package or in the documentation section of this website." with the second documentation being a link to http://www.clamav.net/lang/en/faq/faq-misc/hudoc. Going there gives a page that says "Search Results: Sorry, but you are looking for something that isn't here" Thanks in advance for your help, Paul Well I kind of like allowing it to read executables but am a little weary of allowing it to read user home dir content. (That is where I store my credit card data). Miroslav lets add corecmd_read_all_executables(clamscan_t) Daniel: Regarding your being wary, such implies a lack of trust in clamav not being hijacked (or whatever)? Since I would figure that my home directory is where I probably would download anything to, that seems to be a directory I would certainly want scanned. Just trying to understand the reasoning behind your thoughts ... Thanks, Paul ps: I presume the "Miroslav" sentence is for someone named "Miroslav"? Miroslav is the person responsible for this package. Yes I worry about every package being highjacked. That is what SELinux is about. Then I need to examine what access I give to a package. Allowing a package like clamav which reads potentially really bad stuff, to also read the users home directory could be bad. For example if there is a bug in clamscan that is triggered when it reads some thing, clamscan potentially could be taken control of, reading my home dir and sending valuable information to the hacker. If I only use clamav to look at email, why would I let it look at my users homedirs. Daniel: Thanks for your explanation of your comments. Your point is well taken. If I take such into consideration, should I also assume that the developers of clamav intend it for *only* email and that it should not be used for scanning files on the computer (or, maybe the question is "which files should it be used for")? I would then ask what your thoughts are regarding how to deal with stuff downloaded from the web. I am pretty dang conservative about what I grab (and usually do it through my Windows XP system w/ Norton and Zone Alarm) but it would seem that one would want something on the Linux box to allow for at least some security if one wanted to download something. There is also the question of trying to validate that nothing on the system has been mucked with. I think this may look like it OT, but I think it is more trying to understand if my bug is really a bug ... maybe I am not using clamav as the developers planned it to be used? Thanks for your responses / suggestions, Paul Well I am sure they would say they want to handle both, and that is why we have a boolean to handle both use cases. People just scanning system content and people scanning user homedirs. Daniel: Thanks, that's kinda of how I saw it from Googling on the web (scan mail or files). I guess I'll wait to see what ends up happening and whether it comes with "best practice" advice Paul I have just installed F16 (i686 Xfce) and am not seeing this problem when running the same scripts from F14 that I reported this bug on. Has something changed (as in fixed) and the bug didn't get updated or is this a unintended side-effect of some other change (in which case I wanted to let you know that it appears it is not an issue on F16)? Thanks in advance, Paul Is the action of closing with the notation "nextrelease" a way of saying it has been fixed or a way of saying "you reported it, you said you aren't seeing it anymore, we are calling it fixed without comment"? I don't mind above and beyond wanting to know if it was an active fix or an accidental fix Thanks for understanding, Paul Can we please reopen this. While working on bug 783364, I had to grep for avc in /var/log/audit/audit.log and I can see that there are avc denied warning for clamscan. The gotcha is that F16 Xfce doesn't pop up a warning when it happens, so the denials go by sight unseen. I have no idea what needs to be done to get it to pop up a window asking if I want to see the SELinux Alert Browser ... any idea or do I need to send a question out to Fedora lists. It would be handy for debugging 783364 which may be a freshclam bug (Enrico wants to know whether I am getting any AVCs) Thanks, Paul setroubleshoot problem is going to be fixed. Could you open a new bug on F16 selinux-policy with avc msgs from the /var/log/audit/audit.log. Thank you. I am watching 782269 for the setrobuleshoot and will test once it is pushed out I am created 784122 per your request ... I hope I got it right in regards to what you wanted and what I attached Thanks for your help, Paul |
Description of problem: I am trying to get my system to kick off a clamscan whenever I power-up / reboot and thereafter once an hour. I have a modified virus-scan.sh script that works great as a cron.d job but generates SELinux errors when called in rc.local. I am able to turn the errors into warnings with setenforce 0 (turning back to 1 after the clamscan in rc.local). I searched online and the best I could find was a thread about rc.local and mail. I search under "clamscan rc.local" and "selinux rc.local" but could not see any extant bug (I would think this is something someone else would have tried?) I will enclose attachments after I've logged the bug of what I am seeing in the /var/log/{messages,clamscan,clam-update}, what I am seeing in mail to root (my means of debugging), what I have in rc.local and /usr/local/bin/virus-scan.sh, and what I could cut-and-paste out of SELinux Alert and sealert. Alot of problems seem to have gotten lost owing to queue being filled (in messages?) and I therefore grabbed the last error I was seeing. The errors are all over the place in the directories/files that I am scanning. I am having a bit of trouble with mail on the freshclam when an update occurs and therefore don't have a clean email trail from this 10jul11 run. I enclose both it with freshclam removed and one from yesterday 09jul11 which is what I am expecting. I would think that clamscan would be run "the same way" in rc.local as it is as a job in cron.d, so I am confused why one gives problems and the other does not. Obviously, I'd like to get no errors in rc.local. Thanks in advance ... let me know if I can provide more info Paul Version-Release number of selected component (if applicable): 0.98 (I have [Bug 718625] "F14 yum update seems stuck on clamav 0.97 and not 0.97.1" if that matters ... How reproducible: Add a script to do a "setenforce 0; clamscan; setenforce 1 &" that is called by rc.local ... then watch the warnings and logs/messages Steps to Reproduce: 1. Do "How reproducible" 2. Reboot 3. See the warnings Actual results: See above Expected results: See above Additional info: I don't see any errors about mail, so I am pretty certain that even though I am still tweating mails to root, that is not the problem (and the problem existed before I started adding the debug emails)