Hide Forgot
Description of problem: pam_shield doesn't seem to be able to write to the gdbm database, for reasons I haven't fathomed. What I see in /var/log/secure: Aug 11 21:42:00 hostx unix_chkpwd[26559]: password check failed for user (root) Aug 11 21:42:00 hostx sshd[26555]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=188-xxx-xxx-xxx.zone13.bethere.co.uk user=root Aug 11 21:42:02 hostx sshd[26555]: Failed password for root from 188.222.237.226 port 53949 ssh2 Aug 11 21:42:04 hostx sshd[26556]: Connection closed by 188.xxx.xxx.xxx Aug 11 21:42:12 hostx PAM-shield[26560]: failed to open gdbm file '/var/lib/pam_shield/db' : File open error My /etc/pamd.d/sshd looks like this: #%PAM-1.0 auth required pam_shield.so auth required pam_sepermit.so auth include password-auth account required pam_nologin.so account include password-auth password include password-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open env_params session optional pam_keyinit.so force revoke session include password-auth Version-Release number of selected component (if applicable): pam_shield-0.9.5-8.el6.x86_64
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.