A couple of questions:

1) is selinux enabled, if so disable and test
2) is gdbm installed

I do have gdbm installed.

If I disable selinux, the error message in /var/log/secure no longer appears. 

Grepping audit.log for db:

# grep db /var/log/audit/audit.log 
type=AVC msg=audit(1313095235.591:24464): avc:  denied  { read write } for  pid=26152 comm="sshd" name="db" dev=md1 ino=3408251 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313095269.020:24477): avc:  denied  { read write } for  pid=26497 comm="sshd" name="db" dev=md1 ino=3408251 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313095320.574:24490): avc:  denied  { read write } for  pid=26555 comm="sshd" name="db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313095332.703:24494): avc:  denied  { read write } for  pid=26560 comm="sshd" name="db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313099559.911:24560): avc:  denied  { read write } for  pid=28305 comm="sshd" name="db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313099632.329:24575): avc:  denied  { read write } for  pid=28365 comm="sshd" name="db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313099632.329:24575): avc:  denied  { open } for  pid=28365 comm="sshd" name="db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313099632.330:24576): avc:  denied  { getattr } for  pid=28365 comm="sshd" path="/var/lib/pam_shield/db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313099632.330:24577): avc:  denied  { lock } for  pid=28365 comm="sshd" path="/var/lib/pam_shield/db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313099673.435:24581): avc:  denied  { read write } for  pid=28365 comm="sshd" name="db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file

If you set the following context on the file you'll be fine:

system_u:object_r:var_auth_t:s0

I will be updating the package with a default context and such shortly.

pam_shield-0.9.5-9.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/pam_shield-0.9.5-9.el6

pam_shield-0.9.5-9.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/pam_shield-0.9.5-9.fc14

pam_shield-0.9.5-9.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/pam_shield-0.9.5-9.fc15

pam_shield-0.9.5-9.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/pam_shield-0.9.5-9.el5

pam_shield-0.9.5-9.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/pam_shield-0.9.5-9.fc16

I think that would also require modification to the SElinux policy so that the label survives a relabel? cc'd Dan Walsh.

Added label to selinux-policy-3.10.0-19.fc16

Miroslav we need this label in RHEL6, F14,F15

+/var/lib/pam_shield(/.*)?      gen_context(system_u:object_r:var_auth_t,s0)

OK, it seems we're not out of the woods SElinux wise yet. Having relabelled the db file, I see pam_secure failing to insert iptables rules and the following denials in audit.log

type=AVC msg=audit(1313160971.166:25482): avc:  denied  { getattr } for  pid=17818 comm="shield-trigger-" path="/sbin/iptables-multi" dev=md1 ino=3932300 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1313160971.166:25482): arch=c000003e syscall=4 success=no exit=-13 a0=f51480 a1=7fff991a22e0 a2=7fff991a22e0 a3=f items=0 ppid=17813 pid=17818 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=197 comm="shield-trigger-" exe="/bin/bash" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1313160971.169:25483): avc:  denied  { getattr } for  pid=17813 comm="shield-trigger-" path="/sbin/iptables-multi" dev=md1 ino=3932300 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1313160971.169:25483): arch=c000003e syscall=4 success=no exit=-13 a0=f57640 a1=7fff991a2670 a2=7fff991a2670 a3=f items=0 ppid=17790 pid=17813 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=197 comm="shield-trigger-" exe="/bin/bash" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1313160971.171:25484): avc:  denied  { getattr } for  pid=17813 comm="shield-trigger-" path="/sbin/iptables-multi" dev=md1 ino=3932300 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1313160971.171:25484): arch=c000003e syscall=4 success=no exit=-13 a0=f57b10 a1=7fff991a2690 a2=7fff991a2690 a3=f items=0 ppid=17790 pid=17813 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=197 comm="shield-trigger-" exe="/bin/bash" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1313160971.173:25485): avc:  denied  { getattr } for  pid=17813 comm="shield-trigger-" path="/sbin/iptables-multi" dev=md1 ino=3932300 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1313160971.173:25485): arch=c000003e syscall=4 success=no exit=-13 a0=f57b30 a1=7fff991a2b80 a2=7fff991a2b80 a3=f items=0 ppid=17790 pid=17813 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=197 comm="shield-trigger-" exe="/bin/bash" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null

This seems to be what's needed for that second lot of denials:

module pamshield 1.0;

require {
	type iptables_exec_t;
	type sshd_t;
	class file getattr;
}

#============= sshd_t ==============
allow sshd_t iptables_exec_t:file getattr;

Will we see issues with other programs using pam for authentication that may use this system such as saslauthd ftp dovecot.

I believe the gen_context(system_u:object_r:var_auth_t,s0) will cover these without issue but shield-trigger and shield-purge both call iptables by default and can be configured to call route instead.

Yes, i am not sure what the correct policy is. The one I gave in Comment #12 is clearly not it - that works ok for sshd, but as you say, it's not general enough for other services. My selinux foo isn't good enough to work this one out, I'm afriad. Dan?


Aside: Carl - where actually is the best place to put pam_shield.so in the pam stack - where I have it presently it ends up entering an iptables rule even if the logins were successful, so I am clearly doing something wrong :).

There are three approaches to usage of the pam_shield.so.

The first is block multiple failing login attempts by placing it as required after pam_unix.so

The second is block suspicious logins by placing it as a requisite at the beginning of the pam file

The last is to monitor all connections, including legit, to reduce login spaming from clients (ie outlook and the 1 minute mail check) by placing it as optional at the beginning.

Maybe a better resolution is a different place for the pam_shield directory and its contents.  /var/lib/pam_shield made sense but with selinux input maybe there is a better place that has a default context that would already work.

I have pulled the release of 0.9.5-9 due to it not correcting the problem and will work on 0.9.5-10 to work with changes in selinux-policy and remove the post scripts that deal with selinux.

Since there are security issues with allowing all the various daemons access to iptables I'm going to work toward another resolution to the invocation of iptables.  It still works without selinux but end goal is to get a mechanism that is not a security risk under selinux.

# cat /etc/fedora-release ; rpm -q pam_shield gdbm selinux-policy ; ls /var/lib/pam_shield/db:

Fedora release 18 (Spherical Cow)
pam_shield-0.9.5-11.fc18.x86_64
gdbm-1.10-3.fc18.x86_64
gdbm-1.10-3.fc18.i686
selinux-policy-3.11.1-73.fc18.noarch
ls: cannot access /var/lib/pam_shield/db: No such file or directory

I reinstalled all packages and still no /var/lib/pam_shield/db

Is there any way to force create pam_shield/db on a local system?

Lance

This may be understood already, but I still see this on a fresh install of Fedora 19.

This is still occurring on Fedora 23 (upgrade from 21, not fresh install).

This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged  change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.

EPEL el6 changed to end-of-life (EOL) status on 2020-11-30. EPEL el6 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
EPEL please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.