Bug 425241

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.

$ 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?

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.

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!

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.

OK, reported upstream with backreference to this bugzilla and waiting for
feedback. Thanks Dan!

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?

Yes I fixed it in rawhide but not in f8.  Sorry.

selinux-policy-3.0.8-74.fc8

(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 

Created attachment 292257 [details]
Saved SELinux alerts after restarting fail2ban

The messages from 2008-01-19 occurred when restarting fail2ban usisng
service fail2ban restart

Adding mta_send_mail(fail2ban_t) 

Which should clean up most of these.

selinux-policy-3.0.8-74.fc8

Fixed in selinux-policy-3.0.8-79.fc8

Can someone from the reporters confirm that this is fixed with the current
selinux-policy in F8 so we can close this one? Thanks!

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

Why is fail2ban looking in /tmp?

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

I believe we have moved that to /var/run/fail2ban.sock in Fedora.

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.

https://bugzilla.redhat.com/show_bug.cgi?id=429281

Ah, ok, I wasn't looking in rawhide for updates.  I'll give that a try.

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.

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. 

Please attach the /var/log/audit/audit.log file with these errors.

Created attachment 296693 [details]
audit log as requested

Here's the audit log you requested.

Did you do some custom setup?

This looks like it is using whois?

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

fail2ban uses whois when someone traps into the ssh-jail.

fixed in selinux-policy-3.0.8-90.fc8.noarch

(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>

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).

(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.

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)

(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? 

(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

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.

Can the reporter or anyone else affected by this bug verify that Dan's fixes do
their job, so we can close as fixed? :)

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.

(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.

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.

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.

Seems a audit2dontaudit would come in handy from time to time. :-)

Might be a handly flag to add.

Created attachment 298889 [details]
selinux alert

Created attachment 298890 [details]
alert text

Created attachment 298891 [details]
selinux alert

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.

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.  :^(

(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.

fail2ban-0.8.2-14.fc8 has been submitted as an update for Fedora 8

fail2ban-0.8.2-14.fc7 has been submitted as an update for Fedora 7

fail2ban-0.8.2-14.fc9 has been submitted as an update for Fedora 9

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.

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.

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.

(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.