Bug 475237
| Summary: | Fail2ban can legitimitely want to connect to rwhois/4321 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Göran Uddeborg <goeran> | ||||
| Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 10 | CC: | ahuhtal4, dwalsh, jkubin, mgrepl | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-05-12 10:05:23 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: |
|
||||||
Maybe I should add: My own solution was to mark port 4321 to also have label whois_port_t. It seems to make sense, it IS a kind of whois port. Good solution. I will update the F10 policy Fixed in selinux-policy-3.5.13-33.fc10 Created attachment 327526 [details]
local.te created from /var/log/audit/audit.log
I've also been bitten by this (and lots of other fail2ban-related selinux denials) bug in F9. Perhaps the fix could be extended to F9 as well? The current version in my box is selinux-policy-3.3.1-111.fc9.noarch.
A couple of times I have created a local selinux module according to SELinux FAQ but that seems to break every time a new version of selinux-policy is in the updates.
Whenever I have run System->Administration->Services to switch sshd 'on' or 'off' according to my needs, selinux creates hundreds of error reports in a few tens of seconds. For example, just today I needed to turn sshd on. Selinux created 520 error reports (most of them dealing with few error types) in just 43 seconds that I spent in Services.
I created a local1.te from /var/log/audit/audit.log and built a module from it. I'm attaching the local1.te to illustrate the amount of things selinux is complaining about. My selinux is now in permissive mode.
IMO, if one needs to have sshd on, using fail2ban is necessary. However, it seems to me that fail2ban and selinux are seriously incompatible. Perhaps there is something to be done about it?
At least some of the errors are bugs in fail2ban rather than in the policy. Fail2ban doesn't properly close open filedescriptors when exec:ing a command like sendmail for example. In any case I think you need to report each problem individually if there is any chance to sort things out. The request for porting the rwhois access to F9 too belongs in this bugzilla, but any other issues would need a separate one. It may seem tedious, I understand, but investigating each problem separately really is the only way to figure out the right fix. Just from looking at your te file, it looks like fail2ban is doing an ls of /usr/bin /usr/sbin, and doing a ps of the processes running on the machine. Do you have some kind of custom script that fail2ban is launching? The rpcbind issues should be fixed in the current policy upgrade. Your local policy should survive a policy upgrade if it does not, this is a serious bug. First, sorry for replying late. For some unknown reason, I do not receive copies of comments on this bug although (I think) I am on the CC List. Am I supposed to press the "Commit" button to receive copies? I thought it was reserved for the original bug reporter. Second, sorry for reporting a bunch of things at once. This is the only reported bug found with search words "SELinux" and "fail2ban". I realize that each item should really be reported separately - and, in my case, filed under F9. And no, there are no special scripts launched by fail2ban that I know of. It is used "as is". The version is fail2ban-0.8.3-16.fc9.noarch. As a general comment, I understand that many of fail2ban-generated SELinux errors may well stem from poor adherence to good programming practices or are proper bugs of fail2ban. However, I hope SELinux would behave differently in cases like this. Now it first denies something, then the application tries again, SELinux denies it, etc. Lots of errors are generated in a very short time span. Couldn't SELinux just deny each error type once instead of spiralling into a "thermal runaway" type of behaviour? Last summer I had to pull "the big switch" in the middle of this "dialogue" because I was afraid my hard disk would overheat. HD activity light was on permanently and CPU load was 100% for minutes. I really would like to help iron out the problems with SELinux and fail2ban. If fedora-list is any indication, many old timers disable SELinux as one of their first moves when they install a new Fedora release. I've kept SELinux on since it first appeared but recently turned it off because I really need to use ssh at times and think I need fail2ban then, too. Denyhosts AIUI doesn't actively prevent ssh attacks but reads fail2ban logs to add another IP address into /etc/hosts.deny. I'll try to write better bug reports regarding SELinux and fail2ban in the near future. In the meanwhile, Merry Xmas & HNY 2009. (In reply to comment #6) > I do not receive > copies of comments on this bug although (I think) I am on the CC List. You seem to be, yes. Check your settings (Preferences -> Email Preferences). Maybe you have (by mistake) turned off those mails? > However, I hope SELinux would behave differently in > cases like this. Now it first denies something, then the application tries > again, SELinux denies it, etc. That you have to explain. If an application tries to read a file and is denied, whether by SELinux or traditional file permissions, and the application tries to read the same file again, you don't mean it should be allowed on the second attempt, do you? > If > fedora-list is any indication, many old timers disable SELinux as one of their > first moves when they install a new Fedora release. There are a lot of people doing that. There are a lot of people running there Windows systems as administrators all the time. I just realized, after reading http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow, that I as reporter am the one supposed close the bug in MODIFIED state. Well, better late than never! (That is, the issue about port 4321 I originally reported is fixed. If you Antti still have other problems, I suggest you file separate bugzillas about that.) Thanks for reminding me, Göran. I haven't seen any complaints about fail2ban for weeks in F9 and my SELinux mode is now enforcing in it. Now that I've also got F10 installed, I needed another fairly large customized local.te -based module to prevent fail2ban-related SELinux denials from appearing. After installing the module, no more problems in F10, either. |
Description of problem: When blocking 208.64.68.68 because of attempts to break in via SSH, I got a whois process spinning on 100% of the CPU. No mail came about the blocking until I killed the whois process. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.5.13-26.fc10.noarch Additional info: The action sendmail-whois in fail2ban will do a whois lookup on the IP it will block and mail the result. Whois typically uses the port 43 (whois/nicname) and fail2ban_t is allowed to connect to that. But it could also try to use 4321 (rwhois) which it does for this particular IP. And that port is not allowed for fail2ban_t. mimmi$ env LANG=C whois 208.64.68.68 [Querying whois.arin.net] [Redirected to rwhois.vaultnetworks.com:4321] [Querying rwhois.vaultnetworks.com] [rwhois.vaultnetworks.com] ... Raw AVC messages: host=mimmi type=AVC msg=audit(1228752001.446:779): avc: denied { name_connect } for pid=4286 comm="whois" dest=4321 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket host=mimmi type=SYSCALL msg=audit(1228752001.446:779): arch=c000003e syscall=42 success=yes exit=0 a0=b a1=6d2450 a2=10 a3=7f9f626d8a70 items=0 ppid=4285 pid=4286 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="whois" exe="/usr/bin/jwhois" subj=system_u:system_r:fail2ban_t:s0 key=(null)