Bug 799781
Summary: | SELinux having problems during clamscan | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul <pnewell0705> |
Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 16 | CC: | dominick.grift, dwalsh, mgrepl, pnewell0705 |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-06-28 03:25:24 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Paul
2012-03-05 01:59:00 UTC
Created attachment 567444 [details]
copy of /var/log/messages
Created attachment 567445 [details]
cut-and-paste of the 8 SELinux alert detalks
You are scanning /tmp directory. The problem is you can scan whatever you want (I mean a location). But I don't see an init script/systemd unit file by default. Basically I would say this is more a local modification. Miroslav: Thanks for the prompt reply. I apologize for not making myself clear. I am aware that I am requesting that /tmp be scanned, the issue is that SELinux is barking on root material. It doesn't seem to be doing it for user material. Not certain what you mean by init script/systemd unit file. I'm running F16 on Xfce pretty much "as is". The only local modification I am aware of is the setsebool that Dan suggested. Is there something I am missing? (I've seen enough posts about systemd and "things that the user has to do that used to be done for them" (???) that I could believe the default install misses something). Another way to put it is that I don't know enough to even consider anything but trivial changes and only to my user account ... certainly not root / the system. Paul SELinux cares only about SELinux contexts. Ok, how do you start clamscan? Miroslav: Sorry for the delay in getting back. In my rc.local, I first call freshclam and then go to a custom script for doing the virus-scan. It notes that it is being called by rc.local and throws a delay to make sure freshclam has done its thing. If from rc.local, I drop setenforce to 0 for the duration of the scan to make sure SElinux doesn't have do anything if there are any issues. The script also makes sure that no other requests happen until the machine has been up for awhile to prevent collision. There is a post-process to filter out any dupes that have been quarentined which you can ignore as the problems are only during the actual clamscan The script looks ugly but most of it is a combination of debug versions and the ability that all actions send out an email to my home account. I will not be offended if you go "ick" ... I've not been prepared to get rid of debug stuff until I can see that everything is behaving and I've been having issues since F14 when I first tried clamav (most resolved by now, many with clamav and SElinux help on Bugzilla and the user-lists). If it is too confusing, let me know and I prep up a stripped down version. I will attach after I send this post. To help, this is what the email I get says when it runs the virus-scan from rc.local: +++ Starting time: Wed Mar 7 21:32:35 PST 2012 Directories to scan: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin /home /tmp Directories to exclude: --exclude-dir=/tmp/autodesk --exclude-dir=/usr/autodesk --exclude-dir=/home/paul/Desktop/Baretta/BarettaBetaDocs ClamAV 0.97.3/14610/Wed Mar 7 16:18:47 2012 ----------- SCAN SUMMARY ----------- Known viruses: 1155880 Engine version: 0.97.3 Scanned directories: 1998 Scanned files: 33696 Infected files: 0 Data scanned: 834.39 MB Data read: 2032.86 MB (ratio 0.41:1) Time: 330.406 sec (5 m 30 s) ===== running duplicate check /var/quarantine_clamscan / / ===== Ending Time: Wed Mar 7 21:38:06 PST 2012 +++ Let me know if I can provide anything else, Thanks, Paul Created attachment 568501 [details]
script that rc.local calls to do a clamscan (as requested)
Miroslav: You asked me how I start clamscan back on the 7th of March and I replied (giving as much info as I could) on the 8th. I have noticed that I haven't heard back and we've just crossed into April. Can you let me know where this stands? Thanks, Paul I missed this one, I apologize. Will work on this issue again asap. Miroslav: Hate to be a bother, but I am assuming I should hear something from you based on your last entry on this bug (?) Thanks for understanding the ping, Paul The problem is you end up with clamscan_t because of your custom rc.local script. If you run this script directly, it will work. I think we will need to change a way how we confine these scanners. Because they could read random files on a system. Could you just try to change label to bin_t for clamscan binary chcon -t bin_t `which clamscan` Miroslav: Thanks for the reply. Its late in my time zone, so let me try your chcon suggestion tomorrow. That being said, I would appreciate your understanding if, after checking out the man page for chcon, I am not certain what you are looking for (as in this is all Greek to me (smile)) Thanks, Paul Miroslav: My apologies for the delay. I am on the Maya beta program and the license blows up in 5 days, so I am hard-pressed to do any other computer stuff until I get through that. That being said, I re-read the man pages (twice!) and think I understand what you are asking for. As soon as a window shows up, I will do as you suggest. Thanks for understanding, Paul Ok. Miroslav: Thanks for giving me the time to get anything Maya related done before the beta license ended. I'm now back to working with F16 and was able to test your suggestion. I did a "yum update" so I was current as of @4:00pm my time (that would be midnight GMT). I ran "ls -Z" and verified that the type is currently "clamscan_exec_t". I verified that I was still getting the SElinux alerts. I made the "chcon -t bin_t /usr/bin/clamscan" and verified with "ls -Z" that it is now "bin_t". Restarted and the SElinux alerts go away (hooray!). I do not know if this a test so that you can get "clamscan_exec_t" working or a proposed fix. I did some digging to find out that if I want this to be permanent, I need to do "/usr/sbin/semanage fcontext -a -t bin_t /usr/bin/clamscan". I'm not going to do that until I hear back about how you would like to proceed and if there are anymore tests you'd like me to run Once again, thanks for bearing with the delay and I hope my results are what you were hoping that I'd report Paul Great. But I came up with a new solution. I am going to add a new boolean tunable_policy(`clamscan_can_scan_system`) files_read_non_security_files(clamscan_t) ') which I would like to apply for scanners and add $scanner_can_scan_system booleans. Miroslav: Thanks for the reply. If I understand correctly, this means that when your fix in pushed out to the release version(s), there will be a "setsebool -P scanner_can_scan_system 1" command available? If not, can you correct my thinking? For the time being, I can use your "chcon -t bin_t /usr/bin/clamscan" to get rid of the alerts. I'll assume that I'll get notice of when the fix is out via email on this bug. I am hoping this will be for both F17 and F16. Paul Yes. commit f12d1aef1af4282d180eac7acebd77201692c116 Author: Miroslav Grepl <mgrepl> Date: Wed May 2 12:19:49 2012 +0000 Add clamscan_can_scan_system boolean Fixed in selinux-policy-3.10.0-88.fc16 Miroslav: Thanks for confirm. I have one more machine to convert to F16 (now that I don't need it on F14 for Maya). I'll do it middle to end of month once I see selinux-policy-3.10.0-88.fc16 show up on my other F16 boxes so I can verify on a system before I've modified it too much. Paul selinux-policy-3.10.0-89.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-89.fc16 Package selinux-policy-3.10.0-89.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-89.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-9507/selinux-policy-3.10.0-89.fc16 then log in and leave karma (feedback). Thanks for the update and news about it. I have three questions before I can do this. I've never used the testing repository and, though your instructions make it pretty clear and easy about how to install the patch, can you point me to a link telling me how to get rid of it afterwards so I am back on "released only code". The second question regards how to test it. I used Miroslav's suggestion of chcon -t bin_t `which clamscan` to get myself working. To test this, I need to undo that change to bring the system back to default, correct? What did clamscan's label start out as? (I can't find anything about what it was it my notes, just Miroslav's bin_t). My assumption is I need to undo the chcon command, test to verify I am still seeing the error, yum update your test release, test to see if it fixes the error, and then get rid of the test update in anticipation of the real release. Is my thinking correct or am I being to simple or making things too complex? Thanks, Paul selinux-policy-3.10.0-89.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. Thank you for fixing and releasing this. Sorry I was unable to test as I am worse than a newbie when it comes to test patches. If you can tell me what to reset clamscan to (chcon -t ? `which clamscan`) to get back to factory-default setting for F16 (which shows the bug), I'll be glad to test in the release version Paul What does # ls -Z `which clamscan` Miroslav: Thanks for the reply ... here's what I am getting based on the original suggested workaround +++ [paul@yoyo ~]$ ls -Z `which clamscan` -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/bin/clamscan [paul@yoyo ~] +++ yum -list selinuc-policy yields: +++ 3.10.0-89.fc16 +++ Paul Ok. the restorecon tool is used to fix labeling. So just execute # restorecon -R -v /usr/bin/clamscan Miroslav: Thanks for the "how-to-do" Ran the command, got +++ [root@yoyo ~]# restorecon -R -v /usr/bin/clamscan restorecon reset /usr/bin/clamscan context system_u:object_r:bin_t:s0->system_u:object_r:clamscan_exec_t:s0 [root@yoyo ~]# +++ rebooted system, waited awhile to see what happened, pulled up SELinux Alert Browser and found one "problem" (see attachments forthcoming once I submit this comment). This looks to me like I haven't done something right in my testing or (and I hope not) there is still a problem Paul Created attachment 595679 [details]
the top half of the SEliunx Alert
Created attachment 595680 [details]
the bottom half of the SElinux Alert
Miroslav: Looking closer, there are 21 alerts which pretty much matches my prior results before I applied the chcon workaround. Paul Execute # setsebool -P clamscan_can_scan_system 1 Miroslav: I apologize for the delay in getting back to you ... family decided to take priority over computer (smile) So I did the setsebool -P clamscan_can_scan_system 1, did a power-down, waited long enough that I knew I wouldn't get any confusion from one power cycle to another (in regards to date), powered the machine up, and let it do its thing. After about an hour, there were only 4 alerts (better than 21!). I am going to attach snaps showing the warnings. By the way, is there a way I can get selinux to email the alerts to me so I would get a nice "text" version on each on a different machine than the one I am testing on? I don't know if there warnings are to be expected or if I have something wrong in my settings ... and whether there is enough here to reopen this bug (or, if you prefer, open a new bug). Let me know what I can do to help, Paul Created attachment 596535 [details]
summary list of all 4 alerts from 05jul12
Created attachment 596536 [details]
details of alert 1
Created attachment 596537 [details]
details of alert 2
Created attachment 596538 [details]
details of alert 3
Created attachment 596539 [details]
details of alert 4
I added fixes. Miroslav: Thanks. I am presuming I just need to wait until I see a new selinux-policy being pushed into f16 release branch and then I will test again. Paul |