Bug 425241 - SELinux is preventing /usr/sbin/sendmail.sendmail (sendmail_t) "read write" to socket (initrc_t).
SELinux is preventing /usr/sbin/sendmail.sendmail (sendmail_t) "read write" t...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: fail2ban (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Axel Thimm
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-14 13:00 EST by Jonathan Underwood
Modified: 2008-06-05 18:40 EDT (History)
4 users (show)

See Also:
Fixed In Version: 0.8.2-14.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 06:55:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Saved SELinux alerts after restarting fail2ban (51.43 KB, text/plain)
2008-01-19 09:16 EST, Ian Shields
no flags Details
audit log as requested (4.44 MB, text/plain)
2008-03-03 19:57 EST, Ian Shields
no flags Details
selinux alert (2.84 KB, text/plain)
2008-03-24 09:43 EDT, Andrew Wheeler
no flags Details
alert text (2.89 KB, text/plain)
2008-03-24 09:44 EDT, Andrew Wheeler
no flags Details
selinux alert (3.34 KB, text/plain)
2008-03-24 09:44 EDT, Andrew Wheeler
no flags Details

  None (edit)
Description Jonathan Underwood 2007-12-14 13:00:59 EST
Description of problem:
I see a lot of occurences of the following avc denial on my F-8 box.

Version-Release number of selected component (if applicable):
libselinux-2.0.43-1.fc8
selinux-policy-devel-3.0.8-64.fc8
libselinux-python-2.0.43-1.fc8
selinux-policy-3.0.8-64.fc8
selinux-policy-targeted-3.0.8-64.fc8
libselinux-2.0.43-1.fc8
sendmail-8.14.2-1.fc8

Detailed Description
    SELinux denied access requested by /usr/sbin/sendmail.sendmail. It is not
    expected that this access is required by /usr/sbin/sendmail.sendmail and
    this access may signal an intrusion attempt. It is also possible that the
    specific version or configuration of the application is causing it to
    require additional access.

Allowing Access
    You can generate a local policy module to allow this access - see
    http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable
    SELinux protection altogether. Disabling SELinux protection is not
    recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi
    against this package.

Additional Information        

Source Context                system_u:system_r:sendmail_t:s0
Target Context                system_u:system_r:initrc_t:s0
Target Objects                socket [ unix_stream_socket ]
Affected RPM Packages         sendmail-8.14.2-1.fc8 [application]
Policy RPM                    selinux-policy-3.0.8-64.fc8
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.catchall
Host Name                     withnail.phys.ucl.ac.uk
Platform                      Linux withnail.phys.ucl.ac.uk 2.6.23.8-63.fc8 #1
                              SMP Wed Nov 21 17:56:40 EST 2007 x86_64 x86_64
Alert Count                   68
First Seen                    Tue 20 Nov 2007 20:47:59 GMT
Last Seen                     Fri 14 Dec 2007 17:55:40 GMT
Local ID                      8542d2b0-43f7-4aa6-b5a2-df3e1677a136
Line Numbers                  

Raw Audit Messages            

avc: denied { read write } for comm=sendmail dev=sockfs egid=51 euid=0
exe=/usr/sbin/sendmail.sendmail exit=0 fsgid=51 fsuid=0 gid=0 items=0
path=socket:[8580] pid=25831 scontext=system_u:system_r:sendmail_t:s0 sgid=51
subj=system_u:system_r:sendmail_t:s0 suid=0 tclass=unix_stream_socket
tcontext=system_u:system_r:initrc_t:s0 tty=(none) uid=0
Comment 1 Daniel Walsh 2007-12-17 11:01:28 EST
Do you know what application is running as initrc_t?

ps -eZ | grep initrc_t

This could be a leaked file descriptor from that application.
Comment 2 Jonathan Underwood 2007-12-17 13:08:27 EST
$ ps -eZ | grep initrc_t
system_u:system_r:initrc_t:s0    2362 ?        00:00:00 nasd
system_u:system_r:initrc_t:s0    2475 ?        00:55:34 fail2ban-server
system_u:system_r:initrc_t:s0    2482 ?        00:00:55 gam_server
system_u:system_r:initrc_t:s0    2573 ?        00:00:05 libvirtd


of those, the only one that I know that uses sendmail is fail2ban-server, and we
already know that leaks file descriptors elsewhere. I guess it's that - sound
reasonable?
Comment 3 Daniel Walsh 2007-12-18 11:22:09 EST
Yes, the file context of fail2ban-server is also labeled incorrectly.


Should be fail2ban_exec_t

I will update policy 
selinux-policy-3.0.8-69.fc8

Reassigning leaked file descriptor to fail2ban.
Comment 4 Axel Thimm 2007-12-18 13:14:32 EST
Hi,

> Reassigning leaked file descriptor to fail2ban.

as I'm not quite firm in selinux: This means more or less to coordinate this
with upstream to find the leaking descriptor, e.g. nothing I can do on a pure
package level (besides patching the sources of course).

Thanks!
Comment 5 Daniel Walsh 2007-12-18 13:47:46 EST
Yes simply stated they should 
fcntl(fd, F_SETFD, F_CLOEXEC)

Every open file descriptor before forking and execing any application, unless
they intend the subprocess to use the file descriptor.
Comment 6 Axel Thimm 2007-12-22 07:23:03 EST
OK, reported upstream with backreference to this bugzilla and waiting for
feedback. Thanks Dan!
Comment 7 Göran Uddeborg 2008-01-07 04:58:18 EST
I understand comment 3 to mean that the file fail2ban-server should have type
fail2ban_exec_t, and that this should have been fixed in
selinux-policy-3.0.8-69.fc8.  I have selinux-policy-3.0.8-72.fc8 but
/usr/bin/fail2ban-server still has type bin_t.  I just did a restorecon on it,
but it stays the same.

Do I misunderstand comment 3, or did something go wrong?
Comment 8 Daniel Walsh 2008-01-08 13:33:16 EST
Yes I fixed it in rawhide but not in f8.  Sorry.

selinux-policy-3.0.8-74.fc8
Comment 9 Ian Shields 2008-01-18 23:21:40 EST
(In reply to comment #8)
> Yes I fixed it in rawhide but not in f8.  Sorry.
> 
> selinux-policy-3.0.8-74.fc8

Apparently not fixed in 3.0.8-74.fc8
Summary
SELinux is preventing /usr/sbin/sendmail.sendmail (sendmail_t) "read write" to
socket (initrc_t).
Detailed Description
SELinux denied access requested by /usr/sbin/sendmail.sendmail. It is not
expected that this access is required by /usr/sbin/sendmail.sendmail and this
access may signal an intrusion attempt. It is also possible that the specific
version or configuration of the application is causing it to require additional
access.
Allowing Access
You can generate a local policy module to allow this access - see FAQ Or you can
disable SELinux protection altogether. Disabling SELinux protection is not
recommended. Please file a bug report against this package.
Additional Information
Source Context:  system_u:system_r:sendmail_t:s0
Target Context:  system_u:system_r:initrc_t:s0
Target Objects:  socket [ unix_stream_socket ]
Affected RPM Packages:  sendmail-8.14.2-1.fc8 [application]
Policy RPM:  selinux-policy-3.0.8-74.fc8
Selinux Enabled:  True
Policy Type:  targeted
MLS Enabled:  True
Enforcing Mode:  Permissive
Plugin Name:  plugins.catchall
Host Name:  attic4Platform:  Linux attic4 2.6.23.9-85.fc8 #1 SMP Fri Dec 7
15:49:36 EST 2007 x86_64 x86_64
Alert Count:  16
First Seen:  Wed 02 Jan 2008 11:49:40 PM EST
Last Seen:  Fri 18 Jan 2008 08:18:40 AM EST
Local ID:  c1432632-d017-45f7-adc4-f983ceb3e9e8
Line Numbers:  
Raw Audit Messages :

avc: denied { read write } for comm=sendmail dev=sockfs egid=51 euid=0
exe=/usr/sbin/sendmail.sendmail exit=0 fsgid=51 fsuid=0 gid=0 items=0
path=socket:[81342] pid=19621 scontext=system_u:system_r:sendmail_t:s0 sgid=51
subj=system_u:system_r:sendmail_t:s0 suid=0 tclass=unix_stream_socket
tcontext=system_u:system_r:initrc_t:s0 tty=(none) uid=0 
Comment 10 Ian Shields 2008-01-19 09:16:30 EST
Created attachment 292257 [details]
Saved SELinux alerts after restarting fail2ban

The messages from 2008-01-19 occurred when restarting fail2ban usisng
service fail2ban restart
Comment 11 Daniel Walsh 2008-01-21 13:51:47 EST
Adding mta_send_mail(fail2ban_t) 

Which should clean up most of these.
Comment 12 Daniel Walsh 2008-01-21 13:52:01 EST
selinux-policy-3.0.8-74.fc8
Comment 13 Daniel Walsh 2008-01-21 13:52:24 EST
Fixed in selinux-policy-3.0.8-79.fc8
Comment 14 Axel Thimm 2008-02-16 16:55:18 EST
Can someone from the reporters confirm that this is fixed with the current
selinux-policy in F8 so we can close this one? Thanks!
Comment 15 Göran Uddeborg 2008-02-17 10:11:44 EST
After upgrading my policy fail2ban doesn't even start any more!  The server
isn't allowed to access /tmp

avc: denied { search } for comm="fail2ban-server" dev=dm-0 egid=0 euid=0
exe="/usr/bin/python" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="tmp" pid=9158
scontext=unconfined_u:system_r:fail2ban_t:s0 sgid=0
subj=unconfined_u:system_r:fail2ban_t:s0 suid=0 tclass=dir
tcontext=system_u:object_r:tmp_t:s0 tty=(none) uid=0

This is with

fail2ban-0.8.1-10.fc8.noarch
selinux-policy-3.0.8-84.fc8.noarch
selinux-policy-targeted-3.0.8-84.fc8.noarch
Comment 16 Daniel Walsh 2008-02-18 15:21:08 EST
Why is fail2ban looking in /tmp?
Comment 17 Göran Uddeborg 2008-02-18 15:38:21 EST
It uses a Unix domain socket to communicate between server and client, and by
default it calls that socket /tmp/fail2ban.sock

http://www.fail2ban.org/wiki/index.php/HOWTO_fail2ban_0.7.x#Client.2FServer
Comment 18 Daniel Walsh 2008-02-18 15:45:39 EST
I believe we have moved that to /var/run/fail2ban.sock in Fedora.
Comment 19 Göran Uddeborg 2008-02-18 15:57:25 EST
Moving it to /var/run would make sense, but it isn't done in my copy.  I have
fail2ban-0.8.1-10.fc8, and it still uses /tmp.
Comment 21 Göran Uddeborg 2008-02-18 16:17:26 EST
Ah, ok, I wasn't looking in rawhide for updates.  I'll give that a try.
Comment 22 Axel Thimm 2008-02-18 16:20:01 EST
We moved it, but the package is in updates-testing, Göran can you please do

su -c 'yum --enablerepo=updates-testing update fail2ban'

If you find that it's working you can raise its karma on
https://admin.fedoraproject.org/updates/F8/FEDORA-2008-1678 as a feedback for me
to push it into the stable repo. Also please report on bug #429281, as this is
the proper bug for the /tmp issue.

I still think we can close this bug.
Comment 23 Ian Shields 2008-03-01 13:26:04 EST
Since yesterday (Feb 29), I have received a bunch more SELinux reports against
fail2ban. Some of the messages follow. My system is:
Linux attic4 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:03:13 EST 2008 x86_64 x86_64
x86_64 GNU/Linux
fail2ban-0.8.1-10.fc8

SELinux is preventing sendmail (system_mail_t) "read write" to socket (fail2ban_t). 
SELinux is preventing gam_server (fail2ban_t) "getattr" to inotify (inotifyfs_t). 
SELinux is preventing gam_server (fail2ban_t) "read" to inotify (inotifyfs_t). 
SELinux is preventing iptables (iptables_t) "read write" to socket (fail2ban_t). 
SELinux is preventing whois (fail2ban_t) "write" to <Unknown> (fail2ban_t). 
SELinux is preventing whois (fail2ban_t) "read" to <Unknown> (fail2ban_t). 
SELinux is preventing whois (fail2ban_t) "bind" to <Unknown> (fail2ban_t). 
SELinux is preventing whois (fail2ban_t) "getattr" to <Unknown> (fail2ban_t). 
SELinux is preventing whois (fail2ban_t) "create" to <Unknown> (fail2ban_t). 
SELinux is preventing whois (fail2ban_t) "read" to ./resolv.conf (net_conf_t). 
SELinux is preventing the fail2ban-server from using potentially mislabeled
files (./tmp). 

Some of these appear related to the /tmp issue, but I'm not sure they all relate
to that. 
Comment 24 Daniel Walsh 2008-03-03 10:19:21 EST
Please attach the /var/log/audit/audit.log file with these errors.
Comment 25 Ian Shields 2008-03-03 19:57:35 EST
Created attachment 296693 [details]
audit log as requested

Here's the audit log you requested.
Comment 26 Daniel Walsh 2008-03-04 15:11:50 EST
Did you do some custom setup?

This looks like it is using whois?

It is also running gam_server over /proc and /var?

Comment 27 JM 2008-03-04 16:08:38 EST
fail2ban uses whois when someone traps into the ssh-jail.
Comment 28 Daniel Walsh 2008-03-04 16:39:47 EST
fixed in selinux-policy-3.0.8-90.fc8.noarch
Comment 29 Ian Shields 2008-03-04 21:31:55 EST
(In reply to comment #27)
> fail2ban uses whois when someone traps into the ssh-jail.

Correct. Fail2ban ahs a number of scripts that execute on certain events. These
are normally in /etc/fail2ban/action.d

In particular, the sendmail-whois.conf file which is heavily used in default
actions contains the following excerpt.

 # Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    <ip>  IP address
#          <failures>  number of failures
#          <time>  unix timestamp of the ban time
# Values:  CMD
#
actionban = echo -en "Subject: [Fail2Ban] <name>: banned <ip>
            From: Fail2Ban <<sender>>
            To: <dest>\n
            Hi,\n
            The IP <ip> has just been banned by Fail2Ban after
            <failures> attempts against <name>.\n\n
            Here are more information about <ip>:\n
            `/usr/bin/whois <ip>`\n
            Regards,\n
            Fail2Ban" | /usr/sbin/sendmail -f <sender> <dest>
Comment 30 Daniel Walsh 2008-03-05 15:41:55 EST
Well if you could test the selinux-policy-3.0.8-91.fc8.noarch package that is
going into Fedora-testing to see if it works with the whois and sendmail.  (It
is supposed to).
Comment 31 Ian Shields 2008-03-05 22:53:38 EST
(In reply to comment #30)
> Well if you could test the selinux-policy-3.0.8-91.fc8.noarch package that is
> going into Fedora-testing to see if it works with the whois and sendmail.  (It
> is supposed to).

I guess *I* could test it, but I sort of assumed that if *you* were generating
the fix, then you'd have at least installed fail2ban and tried to ssh into your
system which is all that I ever have to do to generate these reports since ssh
is the *only* port open on my system. It's not like I do a lot of customization
of standard fail2ban. Here's the difference between my current fail2ban and the
last emacs backup. The current one is dated Jan 2, 2008.

[root@attic4 fail2ban]# diff jail.conf~ jail.conf
19c19
< bantime  = 600
---
> bantime  = 36000

As I said, I don't do a whole lot of customization, as the following output shows:

[root@attic4 ~]# find /etc/fail2ban/ -type f -mtime -180
/etc/fail2ban/jail.conf
[root@attic4 ~]# 

I don't mind helping with stuff that's not obvious, or maybe really unique to my
system, but this is kinda obvious, and not very different to stock-standard.

IMHO, if stock-standard fail2ban or any other package is going to break this
easily with SELinux, then we need to rethink how packages interact with SELinux.
In particular, if a package such as fail2ban is going to support user definable
actions that are dependent on SELinux supporting fail2ban's access to such
actions, then the user needs to (a) know that something needs to be done to
allow the access and (b) have easily available info at the point fo failure
telling him what to do. I may be just stupid, although I've written a series of
very successful LPI certification tutorials
(http://www.ibm.com/developerworks/linux/lpi/101.html), but I find getting
SELinux and my needs together to be an extremely difficult task.

WRT to fail2ban, the RPM doesn't spell out a requirement for the whois package.
Maybe it should, since that's required for part of the default set of actions.
then again, maybe it shouldn't, since a user can customize actions to avoid any
need for whois. Whatever the answer, we need a useful way for SELinux to support
such packages and we clearly aren't there yet.
Comment 32 Daniel Walsh 2008-03-06 12:11:01 EST
Well sad to say a lot of fixed that I put out are never tested here, and I have
to rely on the reporter confirming the fix.  First off I support
RHEL4/RHEL5/Fedora 7-9.  And I do bug fixes on lots of packages that I don't
have setup or even know how to setup.  But you don't want to here me whine.

Thanks for the instructions on how to test it.  I did test it on Rawhide, and I
will backport the fixes to Fedora 8.  I did notice that fail2ban is leaking open
file descriptors to a unix_stream_socket and /var/log/secure.

type=AVC msg=audit(1204821989.521:127): avc:  denied  { read } for  pid=12985
comm="iptables" path="/var/log/secure" dev=dm-0 ino=7275547
scontext=staff_u:system_r:iptables_t:s0 tcontext=system_u:object_r:var_log_t:s0
tclass=file
type=SYSCALL msg=audit(1204821989.521:127): arch=c000003e syscall=59 success=yes
exit=0 a0=28922d0 a1=28927c0 a2=2891520 a3=3c6316b9f0 items=0 ppid=12984
pid=12985 auid=3267 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=1 comm="iptables" exe="/sbin/iptables"
subj=staff_u:system_r:iptables_t:s0 key=(null)
type=AVC msg=audit(1204822762.486:161): avc:  denied  { read write } for 
pid=13750 comm="iptables" path="socket:[106888]" dev=sockfs ino=106888
scontext=staff_u:system_r:iptables_t:s0 tcontext=staff_u:system_r:fail2ban_t:s0
tclass=unix_stream_socket
type=SYSCALL msg=audit(1204822762.486:161): arch=c000003e syscall=59 success=yes
exit=0 a0=10f3560 a1=10f2840 a2=10f24e0 a3=8 items=0 ppid=13749 pid=13750
auid=3267 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
ses=1 comm="iptables" exe="/sbin/iptables" subj=staff_u:system_r:iptables_t:s0
key=(null)

All open file descriptors in fail2ban should be closed on exec

fcntl(fd, F_SETFD, FD_CLOEXEC)
Comment 33 Ian Shields 2008-03-07 06:37:22 EST
(In reply to comment #32)
> Well sad to say a lot of fixed that I put out are never tested here, and I have
> to rely on the reporter confirming the fix.  First off I support
> RHEL4/RHEL5/Fedora 7-9.  And I do bug fixes on lots of packages that I don't
> have setup or even know how to setup.  But you don't want to here me whine.
> 

Sorry if I came across the wrong way. Not enough sleep lately. :-) I do think
the problems we've seen here warrant a broader look at how to avoid them more
generally rather than just whacking each mole as it appears.

> Thanks for the instructions on how to test it.  I did test it on Rawhide, and I
> will backport the fixes to Fedora 8.  I did notice that fail2ban is leaking open
> file descriptors to a unix_stream_socket and /var/log/secure.
> 
Do we need to open another bug report for that? 
Comment 34 Jonathan Underwood 2008-03-07 06:53:08 EST
(In reply to comment #33)
> (In reply to comment #32)
> > Well sad to say a lot of fixed that I put out are never tested here, and I have
> > to rely on the reporter confirming the fix.  First off I support
> > RHEL4/RHEL5/Fedora 7-9.  And I do bug fixes on lots of packages that I don't
> > have setup or even know how to setup.  But you don't want to here me whine.
> > 
> 
> Sorry if I came across the wrong way. Not enough sleep lately. :-) I do think
> the problems we've seen here warrant a broader look at how to avoid them more
> generally rather than just whacking each mole as it appears.
> 

Yes, this is certainly a case where we should be asking upstream about some of
the design decisions of fail2ban, IMO.

> > Thanks for the instructions on how to test it.  I did test it on Rawhide, and I
> > will backport the fixes to Fedora 8.  I did notice that fail2ban is leaking open
> > file descriptors to a unix_stream_socket and /var/log/secure.
> > 
> Do we need to open another bug report for that? 

https://bugzilla.redhat.com/show_bug.cgi?id=230191
Comment 35 Daniel Walsh 2008-03-07 08:49:20 EST
I agree.  I have made some changes in Rawhide and have sent an update out.  I am
backporting the fixes to Fedora 8, with a new policy for gam_server.  So I want
to see how that works in Rawhide before putting it in an Update.

Packages have different levels of coverage, somewhat dependent on whether the
upstream maintainer, packager or independent tester want to test all code paths
with SELinux.  Also the more a package is used the better the policy becomes.

If I had my druthers I would have an a group of QA People who would do this
work, configuring and testing every policy.  But you know how that goes.

selinux-policy-3.0.8-92.fc8 has more fixes for Fail2ban.
Comment 36 Axel Thimm 2008-03-16 05:42:35 EDT
Can the reporter or anyone else affected by this bug verify that Dan's fixes do
their job, so we can close as fixed? :)
Comment 37 Göran Uddeborg 2008-03-16 07:36:08 EDT
I don't see those AVC:s any more with selinux-policy-3.0.8-93.fc8 and
fail2ban-0.8.1-11.fc8.  I see other AVC:s that I've filed separately.  But these
are gone, at least for me.
Comment 38 Ian Shields 2008-03-18 08:55:47 EDT
(In reply to comment #37)
> I don't see those AVC:s any more with selinux-policy-3.0.8-93.fc8 and
> fail2ban-0.8.1-11.fc8.  I see other AVC:s that I've filed separately.  But these
> are gone, at least for me.

I installed selinux-policy-targeted-3.0.8-93.fc8 yesterday afternoon and the
SELinux warnings seem to have vanished.

Thanks.
Comment 39 Ian Shields 2008-03-19 08:54:20 EDT
Maybe I spoke too soon. Since the update, I have had two SELinux notifications
related to fail2ban.
SELinux is preventing sendmail (system_mail_t) "read write" to socket (fail2ban_t). 
and 
SELinux is preventing iptables (iptables_t) "read write" to socket (fail2ban_t). 

Looks like something still needs to be handled.

Ian Shields.
Comment 40 Daniel Walsh 2008-03-19 09:59:34 EDT
So I am reopening as fail2ban needs to cleanup it leaked file descriptors.  You
can safely ignore these for now, and hopefully fail2ban upstream will clean
these up.  

You could use audit2allow to generate a policy module to get rid of the AVC
messages if you want.
Comment 41 Göran Uddeborg 2008-03-19 17:27:20 EDT
Seems a audit2dontaudit would come in handy from time to time. :-)
Comment 42 Daniel Walsh 2008-03-19 17:54:36 EDT
Might be a handly flag to add.
Comment 43 Andrew Wheeler 2008-03-24 09:43:36 EDT
Created attachment 298889 [details]
selinux alert
Comment 44 Andrew Wheeler 2008-03-24 09:44:01 EDT
Created attachment 298890 [details]
alert text
Comment 45 Andrew Wheeler 2008-03-24 09:44:30 EDT
Created attachment 298891 [details]
selinux alert
Comment 46 Andrew Wheeler 2008-03-24 09:45:20 EDT
Comment on attachment 298889 [details]
selinux alert

orry guys but still not working.
When I try to start the service my selinuxtroubleshooter gets lots of messages.
I have attached the three sections as attachments.

I have selinux-policy-targeted.noarch		3.0.8-93.fc8 installed
and have rebooted with relabel but nothing.
Comment 47 Daniel Walsh 2008-03-25 01:55:04 EDT
Well the etc_runtime_t failure is fixed in 94.

The rpm_t seems to be a leaked file descriptor of the app that is running as rpm_t.

Please open new bugzillas if you find new avc's.  This bug is too long.  :^(
Comment 48 Ian Shields 2008-03-25 21:24:13 EDT
(In reply to comment #47)
> Well the etc_runtime_t failure is fixed in 94.
> 
> The rpm_t seems to be a leaked file descriptor of the app that is running as
rpm_t.
> 
> Please open new bugzillas if you find new avc's.  This bug is too long.  :^(

It sure did grow! Thanks for all your efforst on this.

Ian.
Comment 49 Fedora Update System 2008-05-20 12:17:24 EDT
fail2ban-0.8.2-14.fc8 has been submitted as an update for Fedora 8
Comment 50 Fedora Update System 2008-05-20 12:17:27 EDT
fail2ban-0.8.2-14.fc7 has been submitted as an update for Fedora 7
Comment 51 Fedora Update System 2008-05-20 12:17:28 EDT
fail2ban-0.8.2-14.fc9 has been submitted as an update for Fedora 9
Comment 52 Fedora Update System 2008-05-21 06:55:08 EDT
fail2ban-0.8.2-14.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 53 Fedora Update System 2008-05-21 06:59:19 EDT
fail2ban-0.8.2-14.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 54 Fedora Update System 2008-05-21 07:02:40 EDT
fail2ban-0.8.2-14.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 55 Ian Shields 2008-06-05 18:40:13 EDT
(In reply to comment #54)
> fail2ban-0.8.2-14.fc8 has been pushed to the Fedora 8 stable repository.  If
problems still persist, please make note of it in this bug report.

Today I have four different reports:
SELinux denied access requested by <Unknown>. It is not expected that this
access is required by <Unknown> and this access may signal an intrusion attempt.
It is also possible that the specific version or configuration of the
application is causing it to require additional access. 

SELinux denied access requested by whois. It is not expected that this access is
required by whois and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access. 

SELinux denied access requested by iptables. It is not expected that this access
is required by iptables and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access. 

SELinux denied access requested by sendmail. It is not expected that this access
is required by sendmail and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access. 

As noted earlier, my installation of fail2ban is almost totally stock standard.
I'm at fail2ban-0.8.2-14.fc8.noarch with selinux-policy-3.0.8-109.fc8.noarch

Ian Shields.

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