Bug 706577

selinux-policy-3.9.7-40.fc14.noarch
selinux-policy-targeted-3.9.7-40.fc14.noarch

it wants to search /var/lib/fail2ban, the question is: what business does vsftpd have there (e.g. besides traversing /var/lib/fail2ban, what else does it want there)

you may be able to determine this if you can reproduce this issue after making vsftpd a permissive domain and analyzing/enclosing the AVC denials.

semanage permissive -a ftpd_t (make ftpd_t a permissive domain)
< reproduce event >
ausearch -m avc -tc recent (recent means: get avc denials that occurred in the last 10 minutes")
semanage permissive -d ftpd_t (enforce ftpd_t domain again)

As for:

"avc:  denied  { read write } for  pid=12456
comm="sendmail" path=2F746D702F66666963796E48624F202864656C6574656429 dev=sda2
ino=1455349 scontext=unconfined_u:system_r:system_mail_t:s0
tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file"

I am not sure what is going on. Not many domains are allowed to create files with type tmp_t (sesearch --allow -s domain -t tmp_t -c file -p create)

I actually would have expected that no domain would be allowed to create files with type tmp_t

Yet, something on your system was able to create it and may or may not have leaked file descriptors to sendmail.

This issue would need to be reproducible in order to determine the cause in my view.

Dominick,

Please see https://bugzilla.redhat.com/show_bug.cgi?id=492687#c4

Yes, but that does not answer my questions. (Although it does provide me with clues)

There are (separate) two issues:

1. vsftp wanting to search fail2ban var lib directories:

I suspect it may at least want to read files there. We need to confirm this. To be able to do that we need to do some testing. This is why i suggested you make ftpd_t a permissive domain and reproduce the issue.

That would allow us to determine what ftpd_t wants in /var/lib/fail2ban.

2. sendmail reading and writing to files with the type for generic files in /tmp.

I want to know what created this file.

This could be done by auditing this event of file creation with type tmp_t and reproducing the event:

mkdir ~/mytest; cd ~/mytest;
echo "policy_module(mytest, 1.0.0) gen_require(\` attribute domain; type tmp_t; ') auditallow domain tmp_t:file create;" > mytest.te
make -f /usr/share/selinux/devel/Makefile mytest.pp

sudo semodule -i mytest.pp

Then reproduce the issue and look into the audit.log for any "granted" (grep -i grant /var/log/audit/audit.log) with regard to any domain create files with type tmp_t.

After testing the mytest module can be removed: sudo semodule -r mytest

Once we determined what created the file , we can see how we can deal with that. It may also provide insight about the issue of sendmail wanting to read and write the file without opening it.

I will try the things you told me soon. And let you know the outcome.

Meanwhile, I wonder if the things i added to the /etc/hosts.deny might have something to do with it?

See below:

sendmail : /var/lib/fail2ban/hosts.sendmail.deny \ : spawn (echo "$(date) denied by fail2ban sendmail-tcpwrapper %a" >> /var/log/tcpwrapper.log) & \ : deny

vsftpd : PARANOID : deny
vsftpd : /var/lib/fail2ban/hosts.vsftpd.deny \ : spawn (echo "$(date) denied by fail2ban vsftpd-tcpwrapper %a" >> /var/log/tcpwrapper.log) & \ : deny

Yes, that may well be the reason why vsftp would wants to traverse /var/lib/fail2ban: to read hosts.vsftpd.deny (like sendmail wanted to read hosts.sendmail.deny in your other bug report)

We would need to confirm that, and depending on that conclusion see if we can implement a (more appropriate) solution. But that is speculation now.

That would be the easy part. Basically just test it in permissive mode and see what all vsftp wants there.

The other issue looks a bit more complicated because we first have to determined which created that generic file in /tmp.*, then see if we can implement a type transition and then we need to determine whether sendmail { read write }'ing it is a leak or a required access (some redirection/inheritance issue).

I did what you asked me to do and reproduced the issue:

Here the outcome.


[root@ls2ka mytest]# ausearch -m avc -tc recent
-tc is an unsupported option

[root@ls2ka mytest]# ausearch -m avc -t recent
-t is an unsupported option

[root@ls2ka mytest]# ausearch -m avc -c recent
<no matches>


[root@ls2ka mytest]# grep -i grant /var/log/audit/audit.log
[root@ls2ka mytest]# 


So, as you can see there is no information, sorry.

tail -n 10 /var/log/messages
May 22 20:53:40 ls2ka kernel: [990958.806150] type=1400 audit(1306090420.824:52): avc:  denied  { read write open } for  pid=16410 comm="fail2ban-server" name="ffiCTbD0H" dev=sda2 ino=1455349 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
May 22 20:53:40 ls2ka kernel: [990958.806166] type=1400 audit(1306090420.824:53): avc:  denied  { remove_name } for  pid=16410 comm="fail2ban-server" name="ffiCTbD0H" dev=sda2 ino=1455349 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
May 22 20:53:40 ls2ka kernel: [990958.806175] type=1400 audit(1306090420.824:54): avc:  denied  { unlink } for  pid=16410 comm="fail2ban-server" name="ffiCTbD0H" dev=sda2 ino=1455349 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
May 22 20:53:40 ls2ka kernel: [990958.806204] type=1400 audit(1306090420.824:55): avc:  denied  { execute } for  pid=16410 comm="fail2ban-server" path=2F746D702F666669435462443048202864656C6574656429 dev=sda2 ino=1455349 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
May 22 20:53:40 ls2ka kernel: [990958.817253] type=1400 audit(1306090420.835:56): avc:  denied  { execute } for  pid=16412 comm="sh" name="ldconfig" dev=sda2 ino=1383974 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file
May 22 20:53:40 ls2ka kernel: [990958.817264] type=1400 audit(1306090420.835:57): avc:  denied  { read open } for  pid=16412 comm="sh" name="ldconfig" dev=sda2 ino=1383974 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file
May 22 20:53:40 ls2ka kernel: [990958.817339] type=1400 audit(1306090420.835:58): avc:  denied  { execute_no_trans } for  pid=16412 comm="sh" path="/sbin/ldconfig" dev=sda2 ino=1383974 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file
May 22 20:53:46 ls2ka kernel: [990964.924264] type=1400 audit(1306090426.942:59): avc:  denied  { search } for  pid=16429 comm="vsftpd" name="fail2ban" dev=sda2 ino=1327099 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fail2ban_var_lib_t:s0 tclass=dir

But now it becomes pretty obvious that fail2ban-server probably owns that tmp_t file and that fail2ban needs to shedload of other access in your configuration.

Can you please try the following:

mkdir ~/mytest; cd ~/mytest;
echo "policy_module(myfail2ban, 1.0.0)" > myfail2ban.te;
echo "gen_require(\` type fail2ban_t; ')" >> myfail2ban.te;
echo "type fail2ban_tmp_t;" >> myfail2ban.te;
echo "files_tmp_file(fail2ban_tmp_t)" >> myfail2ban.te;
echo "manage_files_pattern(fail2ban_t, fail2ban_tmp_t, fail2ban_tmp_t)" >> myfail2ban.te;
echo "exec_files_pattern(fail2ban_t, fail2ban_tmp_t, fail2ban_tmp_t)" >> myfail2ban.te;
echo "files_tmp_filetrans(fail2ban_t, fail2ban_tmp_t, file)" >> myfail2ban.te;
echo "optional_policy(\` libs_exec_ldconfig(fail2ban_t) ')" >> myfail2ban.te;

echo "policy_module(myftpd, 1.0.0)" > myftpd.te;
echo "gen_require(\` type ftpd_t; ')" >> myftpd.te;
echo "optional_policy(\` fail2ban_read_lib_files(ftpd_t) ')" >> myftpd.te;

make -f /usr/share/selinux/devel/Makefile myfail2ban.pp myftpd.pp
sudo semodule -i myfail2ban.pp myftpd.pp

Now please try and reproduce the event once again (if possible in permissive mode), and please enclose any new relevant AVC denials.

Yes, now it looks clear. But the question is why fail2ban uses /tmp directory.

[root@ls2ka ~]# cd ~/mytest/

[root@ls2ka mytest]# echo "policy_module(myfail2ban, 1.0.0)" > myfail2ban.te;
[root@ls2ka mytest]# echo "gen_require(\` type fail2ban_t; ')" >> myfail2ban.te;
[root@ls2ka mytest]# echo "type fail2ban_tmp_t;" >> myfail2ban.te;
[root@ls2ka mytest]# echo "files_tmp_file(fail2ban_tmp_t)" >> myfail2ban.te;
[root@ls2ka mytest]# echo "manage_files_pattern(fail2ban_t, fail2ban_tmp_t, fail2ban_tmp_t)" >> myfail2ban.te;
[root@ls2ka mytest]# echo "exec_files_pattern(fail2ban_t, fail2ban_tmp_t, fail2ban_tmp_t)" >> myfail2ban.te;
[root@ls2ka mytest]# echo "files_tmp_filetrans(fail2ban_t, fail2ban_tmp_t, file)" >> myfail2ban.te;
[root@ls2ka mytest]# echo "optional_policy(\` libs_exec_ldconfig(fail2ban_t) ')" >> myfail2ban.te;

[root@ls2ka mytest]# echo "policy_module(myftpd, 1.0.0)" > myftpd.te;
[root@ls2ka mytest]# echo "gen_require(\` type ftpd_t; ')" >> myftpd.te;
[root@ls2ka mytest]# echo "optional_policy(\` fail2ban_read_lib_files(ftpd_t) ')" >> myftpd.te;

[root@ls2ka mytest]# make -f /usr/share/selinux/devel/Makefile myfail2ban.pp myftpd.pp
Compiling targeted myfail2ban module
/usr/bin/checkmodule:  loading policy configuration from tmp/myfail2ban.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 10) to tmp/myfail2ban.mod
Creating targeted myfail2ban.pp policy package
Compiling targeted myftpd module
/usr/bin/checkmodule:  loading policy configuration from tmp/myftpd.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 10) to tmp/myftpd.mod
Creating targeted myftpd.pp policy package
rm tmp/myfail2ban.mod.fc tmp/myftpd.mod tmp/myftpd.mod.fc tmp/myfail2ban.mod

[root@ls2ka mytest]# semodule -i myfail2ban.pp myftpd.pp

[root@ls2ka mytest]# tail -n 2 -f /var/log/messages
May 23 09:38:39 ls2ka kernel: [1036857.610922] type=1403 audit(1306136319.629:74): policy loaded auid=0 ses=417
May 23 09:38:39 ls2ka dbus: [system] Reloaded configuration
May 23 09:39:42 ls2ka kernel: [1036920.465485] type=1400 audit(1306136382.484:75): avc:  denied  { search } for  pid=26221 comm="vsftpd" name="fail2ban" dev=sda2 ino=1327099 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fail2ban_var_lib_t:s0 tclass=dir
May 23 09:41:17 ls2ka kernel: [1037015.118260] type=1400 audit(1306136477.137:76): avc:  denied  { read write } for  pid=26253 comm="sendmail" path=2F746D702F666669507550634843202864656C6574656429 dev=sda2 ino=1455349 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file

Really strange: the file is still type tmp_t.. Its inode number is also exactly the same as it was a couple of posts ago. I wonder whether it was created or was still there from before.

find /tmp -inum 1455349

and if its not there then maybe:

find /var/tmp -inum 1455349

Could you please remove that file from your temporary directory (or move it somewhere else for the time being) and then see if it still throws the same AVC denial? There should basically be no files with type tmp_t in your temporary directories i believe.

Other possibility is an unconfined domain creates this file. So 

# semodule -d unconfined

would help to indicate where the problem is.

All suggestions give zilch results:

[root@ls2ka ~]# find /tmp -inum 1455349
[root@ls2ka ~]# find /var/tmp -inum 1455349
[root@ls2ka ~]# semodule -d unconfined
[root@ls2ka ~]# 
[root@ls2ka ~]# find / -xdev -inum 1455349
[root@ls2ka ~]#

However, if i restart fail2ban and initiate a connect to the ftpd daemon:

May 23 17:01:23 ls2ka kernel: [1063421.460359] type=1400 audit(1306162883.479:97): avc:  denied  { search } for  pid=1245 comm="vsftpd" name="fail2ban" dev=sda2 ino=1327099 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fail2ban_var_lib_t:s0 tclass=dir

And only after 3 invalid login attempts when fail2ban kicks in:

May 23 17:02:46 ls2ka kernel: [1063504.320760] type=1400 audit(1306162966.339:98): avc:  denied  { read write } for  pid=1256 comm="sendmail" path=2F746D702F6666694E5A6367316E202864656C6574656429 dev=sda2 ino=1455349 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file

btw: when fail2ban detects more then 3 invalid login attempts it writes the attacking IP to the /var/lib/fail2ban/hosts.vsftpd.deny file and does an whois on the attacking IP and sends the results as an e-mail to the root user.

I guess that's what causes the avc denial.

For the first issue i found the bug. Which can be applied for testing purposes by appending the following to the existing myftpd.te source policy type enforcement file:

cd ~/mytest;
echo "gen_require(\` type fail2ban_var_lib_t; ') >> myftpd.te;
echo "read_files_pattern(ftpd_t, fail2ban_var_lib_t, fail2ban_var_lib_t)" >> myftpd.te;

make -f /usr/share/selinux/devel/Makefile myftpd.pp
sudo semodule myftpd.pp

The second issue is still a mystery.
The path and inode are again the same as previously.

Please confirm and do the following:

1. confirm that unconfined module is disabled:

sudo semodule -l | grep unconfined | grep -i disabled

2. please paste the output of the following command:

sudo sesearch --allow -t tmp_t -c file -p create

3. please add the following module:

cd ~/mytest;
echo "policy_module(mytest,1.0.0)" > mytest.te;
echo "gen_require(\` type tmp_t; attribute domain; ')" >> mytest.te;
echo "auditallow domain tmp_t:file create;" >> mytest.te;

make -f /usr/share/selinux/devel/Makefile mytest.pp
sudo semodule -i mytest.pp

4. please run:

find / -inum 1455349

and if its found please list its attributes (ls -alZ $PATHTOFILE)

5. please once again see if you can reproduce the issue

6. after testing please enclose output of: grep -i grant /var/log/audit/audit.log

7. please enclose any other AVC denials that occur.

Check your fail2ban configuration and make sure it is not using /tmp for anything.  There have recently been fail2ban issues with using /tmp.  It should use /var/run or /var/lib for this.  

I think we should add the 

read_files_pattern(ftpd_t, fail2ban_var_lib_t, fail2ban_var_lib_t)
to policy 

And any other domains that use fail2ban data.

2F746D702F666669507550634843202864656C6574656429

translates to

/tmp/ffiPuPcHC (deleted)

Yes i already fixed the fail2ban_read_lib_files() to enable callers to get to it:

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=commitdiff;h=dcd8ba25fdb1b16851ef5e7ae46be710e455f0b5

I will also add a call to it for ftpd_t

1.

[root@ls2ka ~]# semodule -l | grep unconfined | grep -i disabled
unconfined      3.2.1   Disabled
[root@ls2ka ~]#


2.

[root@ls2ka ~]# sesearch --allow -t tmp_t -c file -p create
Found 12 semantic av rules:
   allow sysadm_t tmp_t : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename open } ;
   allow rpm_script_t tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow rpm_t tmp_t : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename open } ;
   allow files_unconfined_type file_type : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint open audit_access } ;
   allow kernel_t tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow nfsd_t tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow puppet_t tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow nmbd_t tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow initrc_t tmp_t : file { ioctl read write create getattr setattr lock relabelfrom append unlink link rename open } ;
   allow ftpd_t tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow sftpd_t tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;
   allow smbd_t tmp_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ;

[root@ls2ka ~]#


4.

[root@ls2ka ~]# find / -inum 1455349
[root@ls2ka ~]#


6.
[root@ls2ka mytest]# grep -i grant /var/log/audit/audit.log
[root@ls2ka mytest]#


7.

May 24 10:31:44 ls2ka dbus: avc:  received policyload notice (seqno=11)
May 24 10:31:44 ls2ka kernel: [1126442.968956] type=1403 audit(1306225904.987:223): policy loaded auid=0 ses=455
May 24 10:31:44 ls2ka dbus: avc:  received policyload notice (seqno=11)
May 24 10:31:44 ls2ka dbus: [system] Reloaded configuration
May 24 10:31:59 ls2ka kernel: [1126457.681051] type=1400 audit(1306225919.699:224): avc:  denied  { write } for  pid=6987 comm="fail2ban-client" name="fail2ban.sock" dev=sda2 ino=1310430 scontext=unconfined_u:system_r:initrc_t:s0 tcontext=unconfined_u:object_r:fail2ban_var_run_t:s0 tclass=sock_file
May 24 10:31:59 ls2ka kernel: [1126457.681293] type=1400 audit(1306225919.699:225): avc:  denied  { connectto } for  pid=6987 comm="fail2ban-client" path="/var/run/fail2ban/fail2ban.sock" scontext=unconfined_u:system_r:initrc_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket
May 24 10:32:00 ls2ka kernel: [1126458.913766] type=1400 audit(1306225920.931:226): avc:  denied  { read write } for  pid=6992 comm="sendmail" path=2F746D702F6666694E5A6367316E202864656C6574656429 dev=sda2 ino=1455349 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
May 24 10:32:06 ls2ka kernel: [1126464.490842] type=1400 audit(1306225926.509:227): avc:  denied  { connectto } for  pid=7023 comm="fail2ban-client" path="/var/run/fail2ban/fail2ban.sock" scontext=unconfined_u:system_r:initrc_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket
May 24 10:32:06 ls2ka kernel: [1126464.500169] type=1400 audit(1306225926.518:228): avc:  denied  { write } for  pid=7026 comm="fail2ban-server" name="tmp" dev=sda2 ino=1455329 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
May 24 10:32:06 ls2ka kernel: [1126464.500183] type=1400 audit(1306225926.518:229): avc:  denied  { add_name } for  pid=7026 comm="fail2ban-server" name="ffi0sOKzY" scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
May 24 10:32:06 ls2ka kernel: [1126464.500297] type=1400 audit(1306225926.518:230): avc:  denied  { create } for  pid=7026 comm="fail2ban-server" name="ffi0sOKzY" scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
May 24 10:32:06 ls2ka kernel: [1126464.500361] type=1400 audit(1306225926.518:231): avc:  denied  { read write open } for  pid=7026 comm="fail2ban-server" name="ffi0sOKzY" dev=sda2 ino=1455349 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
May 24 10:32:06 ls2ka kernel: [1126464.500377] type=1400 audit(1306225926.518:232): avc:  denied  { remove_name } for  pid=7026 comm="fail2ban-server" name="ffi0sOKzY" dev=sda2 ino=1455349 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir
May 24 10:32:06 ls2ka kernel: [1126464.500386] type=1400 audit(1306225926.518:233): avc:  denied  { unlink } for  pid=7026 comm="fail2ban-server" name="ffi0sOKzY" dev=sda2 ino=1455349 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
May 24 10:32:06 ls2ka kernel: [1126464.500417] type=1400 audit(1306225926.518:234): avc:  denied  { execute } for  pid=7026 comm="fail2ban-server" path=2F746D702F66666930734F4B7A59202864656C6574656429 dev=sda2 ino=1455349 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file
May 24 10:32:06 ls2ka kernel: [1126464.505342] type=1400 audit(1306225926.523:235): avc:  denied  { execute } for  pid=7028 comm="sh" name="ldconfig" dev=sda2 ino=1383974 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file
May 24 10:32:06 ls2ka kernel: [1126464.505353] type=1400 audit(1306225926.523:236): avc:  denied  { read open } for  pid=7028 comm="sh" name="ldconfig" dev=sda2 ino=1383974 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file
May 24 10:32:23 ls2ka kernel: [1126481.666814] audit_printk_skb: 3 callbacks suppressed
May 24 10:32:23 ls2ka kernel: [1126481.666817] type=1400 audit(1306225943.684:238): avc:  denied  { write } for  pid=1704 comm="ndpmon" name="neighbor_list.xml" dev=sda2 ino=985813 scontext=system_u:system_r:initrc_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file
May 24 10:32:23 ls2ka kernel: [1126481.666831] type=1400 audit(1306225943.684:239): avc:  denied  { open } for  pid=1704 comm="ndpmon" name="neighbor_list.xml" dev=sda2 ino=985813 scontext=system_u:system_r:initrc_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file
May 24 10:32:23 ls2ka kernel: [1126481.668795] type=1400 audit(1306225943.686:240): avc:  denied  { append } for  pid=1704 comm="ndpmon" name="discovery_history.dat" dev=sda2 ino=985816 scontext=system_u:system_r:initrc_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file
May 24 10:33:34 ls2ka kernel: [1126552.865720] type=1400 audit(1306226014.884:241): avc:  denied  { search } for  pid=7065 comm="vsftpd" name="fail2ban" dev=sda2 ino=1327099 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fail2ban_var_lib_t:s0 tclass=dir
May 24 10:34:42 ls2ka kernel: [1126620.173850] type=1400 audit(1306226082.191:242): avc:  denied  { read write } for  pid=7077 comm="sendmail" path=2F746D702F66666930734F4B7A59202864656C6574656429 dev=sda2 ino=1455349 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file

So fail2ban actually does create /tmp/ffi0sOKzY which gets created with the wrong type (tmp_t).

I suggested a policy_module above that should have fixed that issue but seems it did not. Could you verify whether that policy is actually loaded?

sesearch --allow -SC -s failban_t -t tmp_t -T | grep fail2ban_tmp_t

The bigger issue is that fail2ban should not be creating anything in /tmp at all in the first place since fail2ban is a system service and /tmp is meant to be used only by the user space.

Is there anyway that you can configure fail2ban to use /var/lib/fail2ban instead of /tmp for its state full data, or is that hard coded?

Also in comment 15, above i suggested you extend your myftpd module to allow ftpd_t to read fail2ban_var_lib_t files. For some reason this has not been applied either since i still see the same issue.

There are also other issues that need to be resolved. We should deal with fail2ban_client as well.

Is there any way i can get you to stop by #fedora-selinux on the irc://irc.freenode.net irc network?

That would probably be help full since your configuration requires a lot of modification to the fail2ban security policy, and using IRC would speed up this process.

(In reply to comment #19)

> Also in comment 15, above i suggested you extend your myftpd module to allow
> ftpd_t to read fail2ban_var_lib_t files. For some reason this has not been
> applied either since i still see the same issue.

Ahem, that my bad, I removed them afterwards. Thought they were just for testing purpose at that very moment.

You can re-enable your unconfined module since i see that you depend on it and i identified the fail2ban issues now.

sudo semodule -e unconfined

Could you try this please?:

    semodule -r myftpd myfail2ban
    mkdir ~/newtest; cd ~/newtest;
    echo "policy_module(newtest, 1.0.0)" > newtest.te;
    echo "gen_require(` type fail2ban_t, system_mail_t, ftpd_t; ')" >> newtest.te;
    echo "read_files_pattern(ftpd_t, fail2ban_var_lib_t, fail2ban_var_lib_t)" >> newtest.te;
    echo "read_files_pattern(system_mail_t, fail2ban_var_lib_t, fail2ban_var_lib_t)" >> newtest.te;
    echo "libs_exec_ldconfig(fail2ban_t)" >> newtest.te;
    echo "type fail2ban_tmp_t;" >> newtest.te;
    echo "files_tmp_file(fail2ban_tmp_t)" >> newtest.te;
    echo "manage_files_pattern(fail2ban_t, fail2ban_tmp_t, fail2ban_tmp_t)" >> newtest.te;
    echo "exec_files_pattern(fail2ban_t, fail2ban_tmp_t, fail2ban_tmp_t)" >> newtest.te;
    echo "files_tmp_filetrans(fail2ban_t, fail2ban_tmp_t, file)
    echo "allow system_mail_t fail2ban_tmp_t:file rw_inherited_file_perms;" >> newtest.te;
    echo "type fail2ban_client_t;" >> newtest.te;
    echo "type fail2ban_client_exec_t;" >> newtest.te;
    echo "init_daemon_domain(fail2ban_client_t, fail2ban_client_exec_t)" >> newtest.te;
    echo "permissive fail2ban_client_t;" >> newtest.te;
    echo "files_search_pids(fail2ban_client_t)" >> newtest.te
    echo "fail2ban_stream_connect(fail2ban_client_t)" >> newtest.te
    echo "/usr/bin/fail2ban-client -- gen_context(system_u:object_r:fail2ban_client_exec_t, s0)" > newtest.fc;
    make -f /usr/share/selinux/devel/Makefile newtest.pp
    sudo semodule -i newtest.pp
    restorecon -v /usr/bin/fail2ban-client

I mean this ( the above has at least one syntax error that i found )

semodule -r myftpd myfail2ban
mkdir ~/newtest; cd ~/newtest;
echo "policy_module(newtest, 1.0.0)" > newtest.te;
echo "gen_require(\` type fail2ban_t, system_mail_t, ftpd_t; ')" >> newtest.te;
echo "read_files_pattern(ftpd_t, fail2ban_var_lib_t, fail2ban_var_lib_t)" >> newtest.te;
echo "read_files_pattern(system_mail_t, fail2ban_var_lib_t, fail2ban_var_lib_t)" >> newtest.te;
echo "libs_exec_ldconfig(fail2ban_t)" >> newtest.te;
echo "type fail2ban_tmp_t;" >> newtest.te;
echo "files_tmp_file(fail2ban_tmp_t)" >> newtest.te;
echo "manage_files_pattern(fail2ban_t, fail2ban_tmp_t, fail2ban_tmp_t)" >> newtest.te;
echo "exec_files_pattern(fail2ban_t, fail2ban_tmp_t, fail2ban_tmp_t)" >> newtest.te;
echo "files_tmp_filetrans(fail2ban_t, fail2ban_tmp_t, file)
echo "allow system_mail_t fail2ban_tmp_t:file rw_inherited_file_perms;" >> newtest.te;
echo "type fail2ban_client_t;" >> newtest.te;
echo "type fail2ban_client_exec_t;" >> newtest.te;
echo "init_daemon_domain(fail2ban_client_t, fail2ban_client_exec_t)" >> newtest.te;
echo "permissive fail2ban_client_t;" >> newtest.te;
echo "files_search_pids(fail2ban_client_t)" >> newtest.te
echo "fail2ban_stream_connect(fail2ban_client_t)" >> newtest.te
echo "/usr/bin/fail2ban-client -- gen_context(system_u:object_r:fail2ban_client_exec_t, s0)" > newtest.fc;
make -f /usr/share/selinux/devel/Makefile newtest.pp
sudo semodule -i newtest.pp
restorecon -v /usr/bin/fail2ban-client

I dealt with issue reported above as much as possible here:

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=commitdiff;h=4bf73b7eb5cd681b2da2e7e9faf74555bfbbc42c

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=commitdiff;h=7767b3ea7c922431c3baec599b33b5f700406cb6

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=commitdiff;h=3d1650bfec3dafa086db76166d5f09da6f8a5d78

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=commitdiff;h=dcd8ba25fdb1b16851ef5e7ae46be710e455f0b5

But since i had to create a new domain (the alternative was to allow initrc_t to connect to fail2ban with a stream socket) fail2ban_client_t, that is untested, i had to make it a permissive domain.

So i guess this can only be tested in rawhide.

(In reply to comment #19)

> I suggested a policy_module above that should have fixed that issue but seems
> it did not. Could you verify whether that policy is actually loaded?
> sesearch --allow -SC -s failban_t -t tmp_t -T | grep fail2ban_tmp_t

[root@ls2ka mytest]# sesearch --allow -SC -s failban_t -t tmp_t -T | grep
fail2ban_tmp_t
ERROR: could not find datum for type failban_t
ERROR: could not find datum for type failban_t
[root@ls2ka mytest]#

> The bigger issue is that fail2ban should not be creating anything in /tmp at
> all in the first place since fail2ban is a system service and /tmp is meant to
> be used only by the user space.
> Is there anyway that you can configure fail2ban to use /var/lib/fail2ban
> instead of /tmp for its state full data, or is that hard coded?

I don't see any configurable /tmp in any of the files that i have in use in my
fail2ban configuration.

> Is there any way i can get you to stop by #fedora-selinux on the
> irc://irc.freenode.net irc network?
> That would probably be help full since your configuration requires a lot of
> modification to the fail2ban security policy, and using IRC would speed up this
> process.

I will

fail2ban should not use /tmp.

Axel,
I thought it was fixed in the latest fail2ban release?

This issue is fixed as far as i am concerned (except that fail2ban uses /tmp , but i guess we will just have to deal with it at least for now)

http://git.fedorahosted.org/git/?p=selinux-policy.git;a=commitdiff;h=db7344e8b7fae800c0eb11d0b6ea8a3e33522faa

Since I putted SELinux back in Enforcing mode, I have a bunch of errors in maillog like:

May 27 08:28:14 ls2ka sendmail[14395]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 08:30:00 ls2ka sendmail[14406]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 08:39:17 ls2ka sendmail[14471]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 08:39:53 ls2ka sendmail[14511]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 08:40:15 ls2ka sendmail[14523]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 08:46:43 ls2ka sendmail[14559]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 08:47:57 ls2ka sendmail[14569]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 08:49:31 ls2ka sendmail[14583]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 08:49:38 ls2ka sendmail[14591]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 08:52:24 ls2ka sendmail[14619]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 08:54:21 ls2ka sendmail[14664]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 08:55:16 ls2ka sendmail[14678]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 08:56:09 ls2ka sendmail[14701]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:05:40 ls2ka sendmail[14773]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:05:45 ls2ka sendmail[14784]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:06:10 ls2ka sendmail[14793]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:10:49 ls2ka sendmail[14805]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:12:10 ls2ka sendmail[14815]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:17:38 ls2ka sendmail[14879]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:22:54 ls2ka sendmail[14929]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:26:33 ls2ka sendmail[14956]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:26:37 ls2ka sendmail[14963]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:28:19 ls2ka sendmail[14977]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:28:31 ls2ka sendmail[14988]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:28:34 ls2ka sendmail[14995]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:29:18 ls2ka sendmail[15014]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:29:18 ls2ka sendmail[15018]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:31:20 ls2ka sendmail[15055]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:32:26 ls2ka sendmail[15089]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:33:30 ls2ka sendmail[15122]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:33:54 ls2ka sendmail[15138]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:34:10 ls2ka sendmail[15147]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied
May 27 09:34:56 ls2ka sendmail[15160]: warning: /etc/hosts.deny, line 20: open /var/lib/fail2ban/hosts.sendmail.deny: Permission denied

If I check the permissions in the /var/lib/fail2ban directory, I see the following:

[root@ls2ka ~]# ls -lisa --lcontext /var/lib/fail2ban/
total 20
1327099 4 drwxr-xr-x.  2 system_u:object_r:fail2ban_var_lib_t:s0 root root 4096 May 24 15:07 .
1267282 4 drwxr-xr-x. 62 system_u:object_r:var_lib_t:s0   root root 4096 Apr 19  2010 ..
1326268 4 -rw-r--r--.  1 system_u:object_r:fail2ban_var_lib_t:s0 root root   14 May 25 14:45 hosts.sendmail.deny
1326342 4 -rw-r--r--.  1 system_u:object_r:fail2ban_var_lib_t:s0 root root   15 Nov  8  2010 hosts.sendmail.deny.old
1325395 0 -rw-r--r--.  1 unconfined_u:object_r:fail2ban_var_lib_t:s0 root root    0 May 24 15:07 hosts.vsftpd.deny
1325629 4 -rw-r--r--.  1 system_u:object_r:fail2ban_var_lib_t:s0 root root   13 May 24 14:37 hosts.vsftpd.deny.old

I see the differences.
A "restorecon -v -r /var/lib/fail2ban" however doesn't change anything.

[root@ls2ka ~]# restorecon -r -v /var/lib/fail2ban
[root@ls2ka ~]# ls -lisa --lcontext /var/lib/fail2ban/
total 20
1327099 4 drwxr-xr-x.  2 system_u:object_r:fail2ban_var_lib_t:s0 root root 4096 May 24 15:07 .
1267282 4 drwxr-xr-x. 62 system_u:object_r:var_lib_t:s0   root root 4096 Apr 19  2010 ..
1326268 4 -rw-r--r--.  1 system_u:object_r:fail2ban_var_lib_t:s0 root root   14 May 25 14:45 hosts.sendmail.deny
1326342 4 -rw-r--r--.  1 system_u:object_r:fail2ban_var_lib_t:s0 root root   15 Nov  8  2010 hosts.sendmail.deny.old
1325395 0 -rw-r--r--.  1 unconfined_u:object_r:fail2ban_var_lib_t:s0 root root    0 May 24 15:07 hosts.vsftpd.deny
1325629 4 -rw-r--r--.  1 system_u:object_r:fail2ban_var_lib_t:s0 root root   13 May 24 14:37 hosts.vsftpd.deny.old

I suppose that the changes made by dominick for the ftpd and fail2ban are not sufficient?

As soon as I put back selinux to permissive, the "permission denied" is gone.

I don't see any avc denials in syslog however.

Look in audit.log for avc denials: ausearch -m avc -ts today

This is fixed in rawhide. We just forgot to add it to your local policy module.

(In reply to comment #26)
> fail2ban should not use /tmp.
> 
> Axel,
> I thought it was fixed in the latest fail2ban release?

As you say the /tmp access has been fixed a while ago in fail2ban, there is no direct reference to /tmp in the sources anymore.

(In reply to comment #30)
> This is fixed in rawhide. We just forgot to add it to your local policy module.

Is this now selinux or a fail2ban issue? Or are there two report in one here?
Sorry, I'm not a selinux user, so I cannot reproduce it.

Eddie can you please run the following and enclose the output:

rpm -qa | grep fail2ban

Axel whatever package Eddie is using (i suspect the latest available in Fedora 14) still uses /tmp (atleast in Eddies´ set up)

SElinux now supports this setup, however it is preferred that fail2ban fixes the issue of using /tmp or push the fixed version of fail2ban to the repositories.

This is no longer an SELinux issue. It is a fail2ban issue.

There is no /tmp access in fail2ban, we had this issue, fixed it and the reporters' issues went away.
Can this /tmp access be one from an external binary called by fail2ban?

As far as i can tell fail2ban-server command does it:

avc:  denied  { create } for  pid=7026
comm="fail2ban-server" name="ffi0sOKzY"
scontext=unconfined_u:system_r:fail2ban_t:s0
tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file


Note the comm="fail2ban-server"

[root@ls2ka ~]# rpm -qa |grep fail2ban
fail2ban-0.8.4-27.fc14.noarch

Just a side note, i am using the sendmail-whois in both jails.
Can it be that it's the sendmail-whois option that causes the /tmp issue?

Could you please try without sendmail-whois?

But aside from that, if it was the sendmail-whois command creating the tmp file then i would have expected comm="sendmail-whois" instead of comm="fail2ban-server"

AFAIK, the sendmail-whois is not a program, it's a configurable option in fail2ban. If the fail2ban-server does a call to the "whois" program or if it has its own built-in whois is unknown to me.

So, that the avc denial mentions comm="fail2ban-server" while doing the whois thing still looks like a very feasible thing to me.

But perhaps Axel can give some more information about this?

(In reply to comment #37)

BTW, how to test this after i remove the sedmail-whois option?

cd ~/mytest

1. setenforce 0

2. semodule -r newtest.pp

3. semodule -DB

4. restest issue

5. report logs, denials, etc.

6. semodule -B

7. semodule -i newtest.pp

8. setenforce 1

Is this correct?

Yes that sounds about right

Actually i think it does run whois, we allowed it to run generic binaries and to connect to whois tcp ports.

However if it was the whois command that created the file in tmp i would have expected comm="whois" and not comm="fail2ban-server"

Looks like 697223 has the reason for this.

*** This bug has been marked as a duplicate of bug 697223 ***